search

pnorman / ogr2osm

pnorman's version of UVM's Rewrite of ogr2osm
Other
78 stars 46 forks source link

Long ways sould be split into no more than 2000-node ways #30

Closed stefanb closed 3 years ago

stefanb commented 9 years ago

Some wasy are too long in the source shapefile and Ogr2osm preserves that as it is. During the transformation they sould be split into no more than 2000 node part so that it would be acceptable by the OSM API.

Pushing the limit and splitting it at exactly 2000 nodes mark might represent a problem for users when adding a new node in the way (eg a new crossing etc). This is why OSM Inspector is raising warnings for all ways that are more than 1900 nodes long:

Long ways with more than 1900 nodes are shown in blue. These should probably be split up into smaller parts. The OSM API allows a way to have up to 2000 nodes.

Ogr2osm should thus split at 1900 or slightly lower limit, eg 1800.

pnorman commented 9 years ago

If uploading a file, the importer can split at better locations than the script.

I've also generally found it better to run simplification post-conversion, which makes any way splitting at conversion useless.

stefanb commented 9 years ago

This wouls be handy for making the imports easier on the importers. What do you consider better location of a split within the long way? Making sure splits are roughly equally long, no ridiculously short part at the end? Both such cases can be handled programatically. Something else?

Simplification post conversion where? By some other app or by the user manually (via plugin) In JOSM? Having this a automated would make it easier on the importers.

Because of #28 simplification algorithms give strange results with duplicated shared borders of neighbouring polygons, as each polygon gets .simplified seperately. Sample can be seen below: image

roelderickx commented 3 years ago

Fixed in pull request #34