[Imports] Massive polygons

Sam Vekemans acrosscanadatrails at gmail.com
Tue Oct 13 09:56:27 BST 2009


On Tue, Oct 13, 2009 at 1:06 AM, Emilie Laffray <emilie.laffray at gmail.com>wrote:

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

oh, and BTW, to speed up JOSM on the front-end it's
java -Xmx512M -jar c:\josm-latest.jar

Cant bulk_import.pl load files that are larger like this?

I would think it would be more appropriate to 'cut' the lake, and have it
line up.
http://www.openstreetmap.org/browse/relation/190147
is the relation for the whole lake...
and http://www.openstreetmap.org/browse/way/38160117
is the water area the the 'west arm' which is the name of that portion.
Perhaps i have an extra set of ways for this lake?
... so one idea is to be splitting up a large polygon, but only in the most
logical places.

You asked "but we
lose the integrity of the polygon should a newer version of that polygon
is coming)?"

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.

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...

ok, Lets try 'park names'.   so in the CanVec data we have just the simple
park polygons.
... 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.

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.

Do we just sit back and wait for the data to 'appear'? .. or do we get out
there and map it?

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.

... 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.

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)

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

Cheers,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20091013/24807362/attachment.html>


More information about the Imports mailing list