<br><div class="gmail_quote">On Tue, Oct 13, 2009 at 1:06 AM, Emilie Laffray <span dir="ltr"><<a href="mailto:emilie.laffray@gmail.com">emilie.laffray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hello,<br>
<br>
we are now in the process of importing polygons from Corine manually<br>
through the page <a href="http://osmose.openstreetmap.fr/clc" target="_blank">http://osmose.openstreetmap.fr/clc</a> (you need the JOSM<br>
remote control plugin to open an osm file in JOSM), but we have stumbled<br>
accross a problem with nearly all editors.<br>
We have several extremely massive polygons barely opening in JOSM (some<br>
people reported 3 mn to open one of those files), while Merkaator is<br>
performing better. However, in both cases, the editors are too slow to<br>
work with. My question is more in the realm of should we let them be and<br>
remove automatically the overlap areas from those polygons (SQL query<br>
already written) or should we cut them (program almost ready, but we<br>
lose the integrity of the polygon should a newer version of that polygon<br>
is coming)?<br>
<br>
Thank you in advance,<br>
<font color="#888888">Emilie Laffray<br>
<br></font></blockquote><div> </div>Hi,<br>Ya, I guess we have the same problem with importing large lakes... as they are polygons with inner/outer relations.<br><br>oh, and BTW, to speed up JOSM on the front-end it's<br>

java -Xmx512M -jar c:\josm-latest.jar<br><br>Cant <a href="http://bulk_import.pl">bulk_import.pl</a> load files that are larger like this?<br><br>I would think it would be more appropriate to 'cut' the lake, and have it line up.<br>

<a href="http://www.openstreetmap.org/browse/relation/190147">http://www.openstreetmap.org/browse/relation/190147</a> <br>is the relation for the whole lake... <br>and <a href="http://www.openstreetmap.org/browse/way/38160117">http://www.openstreetmap.org/browse/way/38160117</a><br>

is the water area the the 'west arm' which is the name of that portion.<br>Perhaps i have an extra set of ways for this lake?<br>... so one idea is to be splitting up a large polygon, but only in the most logical places. <br>

<br>You asked "but we<br>
lose the integrity of the polygon should a newer version of that polygon<br>
is coming)?"<br><br>I think thats the same philosophy of 'dont tag for the render'..  .. and the idea that im working with is that we treat this imported data, as just 'helper data'.... were as the data that exists in OSM should be held with more integrity, than expecting better data to become available.<br>

<br>So for example, in Ontario.   Sure, we could have waited a year for the road names to appear, and be available in the dataset,  and we could wait for Quebec to have road names also.   However, (although in our case we have StatsCan data as the streetnames), where there is a manual process to get them 'attached' to the data. ... Maybe that's  not a good example...<br>

<br>ok, Lets try 'park names'.   so in the CanVec data we have just the simple park polygons.<br>... where as with the national set, we have 'some' of the national protected areas, so that helps, and with Ontario Data, we have more features available. ... so do we sit back and not tag any parks because better polygons 'might' be available?   ... i say, no,   we go ahead and map the parks as we see fit, and if a new version of the park polygon should be available for the future, then i think it should be upto that mapper who drew in the park, if they want to replace it or not.  (and i dont think that decision should be made by anyone else).   Which is why i think that the files are available on a server (which you have done), is good enough.<br>

<br>So what happened here in Canada at least, is that we have a massive slow-down of map growth.  So basically, when people found out that an import is coming, they stopped mapping, and began only mapping trails, and some features that wouldn't be imported.   But we cant stop everyone for mapping.    ... that is where 'Data Integrity' comes into play.<br>

<br>Do we just sit back and wait for the data to 'appear'? .. or do we get out there and map it?<br> <br>So basically, (i think) by us not going out there and mapping, because we know that the data is available to be imported, i think that takes away from the 'spirit of OSM'.    Which is the freedom to map whatever you like.<br>

<br>... so i think my best answer, (before i drag on any longer), is that we 'retain the integrety of the map, by simply uploading whatever data does not interfer with the existing map data.  And where there are conflicts, we contact that person who put the features there.  (if it was a previous  Corine Import) then it's fine to swap with a newer version.  IF that new version is better.<br>

<br>So i think it really comes down to our objective.   Do we want to create a carbon-copy of the Corine dataset?  Or to we want to make a 'community made' dataset, which is the best of both. (in some cases perhaps loosing some large polygons, in favor of smaller ones, but having more map features than the Corine dataset could possibly have) <br>

<br>Does that make any sense?<br>(as you can tell, i'm despiratly trying to understand it fully at my end too) :-)  As were building from others experiences here.<br><br>Cheers,<br>Sam<br></div>