Modify

Opened 3 years ago

Closed 6 months ago

Last modified 6 months ago

#11166 closed defect (fixed)

Long ways should be split into shorter segments during shapefile import

Reported by: StefanB Owned by: Don-vip
Priority: normal Milestone:
Component: Plugin opendata Version:
Keywords: shp shapefile import Cc:

Description

During an import it happens that a way is longer than 2000 nodes (API limit). In such cases, import should split the way into multiple segments and (in case od an area) join them into a multipolygon relation.

They should be kept somewhat below the API limit to keep them editable, eg max 1800 nodes.

I can provide some examples if needed.

Attachments (1)

raba760dissJosm.zip (270.6 KB) - added by StefanB 3 years ago.
Example shapefile with 3891-node way forest

Download all attachments as: .zip

Change History (8)

comment:1 in reply to:  description Changed 3 years ago by Don-vip

Replying to StefanB:

I can provide some examples if needed.

Yes please, easier and faster for me to test.

Changed 3 years ago by StefanB

Attachment: raba760dissJosm.zip added

Example shapefile with 3891-node way forest

comment:2 Changed 3 years ago by skyper

Would prefer half the limit e.g. 1000 nodes.

comment:3 Changed 3 years ago by StefanB

OsmInspector reports a warning if ways exceed 1900 nodes.
http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Geometry#Layers
Long ways with more than 1900 nodes are shown in blue. These should probably be split up into smaller parts.

So this should be the absolute maximum. Of course some safety gap is needed so that adding a few nodes won't raise warnings, so 1800 or less is the way to go.

1000 might be a bit extreme, as it means that many more simple polygons would have to be mapped as multipolygons just for this reason, raising the data complexity.

How about varying, depending on total number of nodes in the combined way,so that the safety gap is distributed evenly, and to avoid extremely short ways.

1801 = 900+901, rather than 1800+1 or 1000+801
2000 = 2*1000, rather than 1800+200 or 1500+500
4500 = 3*1500, rather than 2*1800+900 or 4*1000+500
5250 = 3*1750, rather than 2*1800+1650 or 5*1000+250 or 3*1500+750
...

Last edited 3 years ago by StefanB (previous) (diff)

comment:4 Changed 6 months ago by Don-vip

In 12287/josm:

see #11166 - make SimplifyWayAction.simplifyWay static + fix javadoc

comment:5 Changed 6 months ago by Don-vip

Resolution: fixed
Status: newclosed

Fixed in [o33358:33359].

comment:6 Changed 6 months ago by StefanB

Thank you!
In the svn diff I noticed that you have also added some way simplification. Can you describe that briefly? Does it compare with some existing josm functionality?

comment:7 Changed 6 months ago by Don-vip

It was already there, I just fixed a bug and performed some modification required to add unit tests. In your example the simplification removes only a few nodes, you shouldn't probably notice it. It's the same action than "simplify way" except it is done with a fixed parameter value, not the one configured in JOSM, as it is not always what is expected.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.