<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div><span>Rather than "blowing it away", perhaps there should be a tool to automatically cut and replace large polygons with multiple smaller polygons? Perhaps someone could write a routine using GPC: <a target="_blank" href="http://www.cs.man.ac.uk/%7Etoby/alan/software/">http://www.cs.man.ac.uk/~toby/alan/software/</a> . Years ago, when I worked at Etak, the internal format (mapengine) had a limit of 255 points per polygon; all software interfacing with it had to maintain this limit. The limit doesn't have to be that low, but perhaps it should be low enough for Potlatch to handle anything.</span><br><br>Of course, the downside is that you can't assume that a polygon's border will the border of the administrative unit or physical feature represented. (How is this handled for
Oceans?) The boundary polylines and polygons have to be distinct.<br><br>-Alan<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Chris Lawrence <lordsutch@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> OpenStreetMap U.S. <talk-us@openstreetmap.org><br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, April 28, 2009 12:17:58 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Talk-us] city polygons too large for potlatch to handle?<br></font><br>On Tue, Apr 28, 2009 at 2:02 AM, Alan Brown <<a ymailto="mailto:adbrown1967@yahoo.com" href="mailto:adbrown1967@yahoo.com">adbrown1967@yahoo.com</a>> wrote:<br>> This might not be the right group to direct this technical question - but<br>>
I'll put it out there anyhow.<br>><br>> I noticed a little while ago that city polygons where added to the OSM<br>> database (at least in the SF Bay Area) - and that's a good thing. There is<br>> a city boundary that runs along a major road between San Jose and Campbell<br>> that I meant to clean up, by getting it to run along the median of the<br>> street. I was also going to redigitize this road as the dual carriageway<br>> that it is. Here's a junction between Bascom Ave, California Highway 85,<br>> and some of the city polygon boundaries:<br>><br>> <a href="http://www.openstreetmap.com/?lat=37.254578&lon=-121.951574&zoom=18&layers=B000FTF" target="_blank">http://www.openstreetmap.com/?lat=37.254578&lon=-121.951574&zoom=18&layers=B000FTF</a><br>><br>> Every time I try to edit (or even select) the city polygon - to delete<br>> unnecesary points, or to get
it to run nicely up the middle of the road -<br>> potlatch gets stuck in a loop. It eventually shows me a warning: "A script<br>> in this movie is causing Adobe Flash Player 10 to run slowly. If it<br>> continues to run, your computer may become unresponsive. Do you wish to<br>> abort the script?" After which, it's impossible to complete the edit.<br>><br>> This problem is making it difficult to clean up this street. Are the<br>> developers aware of this problem? Is there anything that can be done? I<br>> was hoping that the new version of Potlatch would correct the problem, but<br>> it's not the case.<br><br>Ick. It's possible the OSM API 0.6 upgrade brought in polygons & ways<br>that are now too big to edit because they're over the 0.6 limit of<br>2000 nodes per way--it is not at all clear what the migration for<br>existing polygons/ways was. You may need to use
JOSM to do at least a<br>basic edit on these polygons then upload and continue work in<br>Potlatch.<br><br>(Alternative theory: Potlatch has also just been generally flaky for<br>me post-upgrade, so it could just be Potlatch-flakiness.)<br><br>Worst comes to worst I can try to blow away the California upload and<br>upload a 0.6-friendly version. I have a very nice, mostly-way-based<br>conversion setup respecting the 0.6 API limits and using complex<br>multipolygon relations that I implemented starting with the Idaho<br>(complete) and Illinois (uploading now) boundaries; ideally I'd like<br>to go back and redo the boundaries in the A-H states if I can think of<br>a sensible way to do it. (Texas I will have to blow away and redo<br>anyway, which I'm not looking forward to.)<br><br><br>Chris<br><br>_______________________________________________<br>Talk-us mailing list<br><a ymailto="mailto:Talk-us@openstreetmap.org"
href="mailto:Talk-us@openstreetmap.org">Talk-us@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/listinfo/talk-us" target="_blank">http://lists.openstreetmap.org/listinfo/talk-us</a><br></div></div></div></body></html>