Document --is-positive

[citizenfish]

This one caused me a lot of headaches only cured by a dive into the code

Please can you document the command line parameter --is-positive and the fact that --idfile and --saveid count DOWN by default. This will cause issues when you are trying to merge OSM data after conversion as I needed the id to count up.

[citizenfish]

I've created a pull request

[roelderickx]

Hi @citizenfish, thanks for your feedback.

The --positive-id parameter is undocumented on purpose, to avoid bogous uploads to OpenStreetMap using JOSM. I still consider that a valid reason to keep the parameter undocumented.

Using positive id's JOSM will upload a file that will try to overwrite the first nodes added to OpenStreetMap around 2004-2005. If the id's are negative, JOSM considers them new to the database.

The code contains a vague warning, which was there since @pnorman added this feature: https://github.com/roelderickx/ogr2osm/blob/07440b547bd81226f30a639eda930a890507c754/ogr2osm/ogr2osm.py#L107-L108

That being said, it's not the first time someone struggles with this and their use cases are probably legit. There may have been alternative solutions to protect people from using positive id's, an interactive question for example, but I'm afraid that will break many scripts at this point.

[pnorman]

The goal of ogr2osm is to prepare files for import. This requires the IDs are negative in order for it to be added to OSM, and in general IDs need to be negative to be merged with OSM data.

[roelderickx]

Agreed.

For most other uses of ogr2osm it doesn't matter if the id's are positive or negative, they may even be strings. If you really need positive id's the undocumented option is available. I'm sure it's documented anyway using the right Google search terms.

Closing the issue and the pull request.

[pnorman]

If I were writing it these days I probably wouldn't hide the help, but it remains a dangerous option that only exists for data that will never be used with OSM data and is just using the OSM file format. idfile and saveid exist to create files that can be merged when the source data is in multiple files.

[citizenfish]

I use ogr2osm to create files for mkgmap map rendering. This means merging OSM and non-OSM data into a file sorted by id and hence my need for an id that increments beyond the highest id of the OSM data.

I believe this is a valid use case.

[roelderickx]

If I were writing it these days I probably wouldn't hide the help, but it remains a dangerous option that only exists for data that will never be used with OSM data and is just using the OSM file format. idfile and saveid exist to create files that can be merged when the source data is in multiple files.

Thanks for the clarification, that's how I already assumed the parameters should be used.

I use ogr2osm to create files for mkgmap map rendering. This means merging OSM and non-OSM data into a file sorted by id and hence my need for an id that increments beyond the highest id of the OSM data.

I believe this is a valid use case.

Every creative use of ogr2osm is welcomed, so yes, that's a valid use case.

Given the many questions I receive about this I may reconsider documenting the parameter. Please modify the pull request to meet these requirements:

• [x] There should be a clear warning the option is potentially harmful
• [x] The parameters --add-version and --add-timestamp are documented as well with the same warning
• [x] The help text is modified in ogr2osm and the output of ogr2osm is copied to the README file
• [x] The documentation of the 3 parameters is also added in the section 'as a library' in the README file
• [x] The test cases are updated to reflect the new output. I think only basic_usage.t must be adapted

If anything is unclear please ask.

[citizenfish]

Thanks I'll resubmit once done (work permitting!)

[roelderickx]

PR merged