[Imports] GDOŚ data import

Kevin Kenny kevin.b.kenny at gmail.com
Sat Jul 2 16:08:40 UTC 2016

Let me share some of my experience from working with a similar project
(New York State Department of Environmental Conservation protected

Most of the current renderers do not recognize
'boundary=protected_area protect_class=*', but I believe that the
protected_area tagging scheme will become more important in the
future. For that reason, with the reimport of New York State DEC Lands
now in progress, I'm tagging both 'leisure=nature_reserve' and
'boundary=protected_area'. (For 'leisure=nature_reserve,' substitute
more appropriate land use, such as 'park' or 'recreation_ground' for
the "intensive use" regions.)

I add 'landuse=forest' if and only if the area is in part managed for
reforestation or timber production - wilderness areas do NOT get this

The reimport is requiring considerable care and manual patchwork to
deal with ways that have shared tagging with material that's already
there. I had, for instance, to do a lot of manual rework for islands
in the lakes in http://www.openstreetmap.org/relation/6362702 because
the physical and cadastral lines had been conflated. (Ignore the
rendering on that relation. The tile server no longer rerenders zoom
level 12 and below on demand because those levels are so expensive to
produce, and doesn't reliably decache higher zooms. We'll have to wait
a few weeks to see what I tagged.)

Let me underscore the point that tagging regions alike does not make a
multipolygon out of them. Once again, in the New York State DEC
reimport, I'm being careful to create proper multipolygon relations
for the facilities, and break up the linestrings for the larger ones.
The relation I linked to is perhaps the "worst case", since it had
ways shared among cadastral, political, landcover and physical
features, an enormous number of outer and inner rings, and on top of
that the original import was badly broken, with ring intersections
(including self-intersections), unclosed ways, and even reversed
topology (outer rings misidentified as inner, and vice versa).

It's quite a challenge to get this right, and I was working on the
project for quite a long time before beginning the reimport. I don't
expect to continue moving data at the same pace I have done for the
last week or so, so I expect the remaining thousand or so parcels
(I've done fewer than four hundred) will be a low-level effort
throughout the summer.

I can also offer advice about including 'foreign keys' in an import.
Don't. Since mappers can make arbitrary changes to imported data, the
foreign keys are worthless the moment that they are imported. When
updating an import, you have to find the feature by geography, not by
name or number.

On Sat, Jul 2, 2016 at 5:30 AM, Øystein Bjørndal <obtitus at gmail.com> wrote:
> Hi, just some comments.
>>> There's quite a few strange
>>> things about your import - tags that seem superfluous, and strange
>>> multipolygons like this
>>> http://www.openstreetmap.org/relation/6298112#map=15/51.3748/22.5863
>>> - do these four stripes really form one unit, legally?
>> All the polygons if they are part same relation share same INSPIRE code
>> tagged as "kodinspire" which determines if it was meant to be together
>> or not therefore yes they form one unit.
> The fact that they share tags do not (necessarily!) imply a multipolygons in OSM.
> But I do not know what a INSPIRE code implies, so I will leave that to others.
>> I could not find any
>> information as of how that tag should be translated into other used in
>> OSM so I just left it in the original form just like provided by the
>> government.
> The number of tags in use in OSM is huge, if you could not find any relevant OSM
> tags to translate into, imply that the tag should not be imported. Simply
> because the data exist does not imply that it is a good fit for import into OSM.
>>> And, worst of all, is there *anything* on the ground about these areas,
>>> anything that makes them verifiable?
>>> Data that is not verifiable on the ground is generally unsuitable for
>>> OSM; exceptions can be made but there must be a very good reason for
>>> them. I really have difficulties seeing what the use of a 200 by 5 metre
>>> strip of "protect_class=19" somewhere in a Polish forest might be -
>>> someone who needs this data surely could simply open the government's
>>> shape file?
>>> The strength of OSM is that others can build on the data; go there, add
>>> information they see on the ground, improve data... your import doesn't
>>> seem to be amenable to that very much. Why did you import it - what is
>>> your use case?
>>> Bye
>>> Frederik
>> But the way during the import I have not added the main tag
>> leisure=nature_reserve which I believe should be in there as well.
> I would much rather have leisure=nature_reserve than protect_class=19, if someone needs to
> know the ‘protect_class’ they should be able to find that elsewhere. A crucial step in preparing
> and discussing a import is to ‘normalize’ the tags to fit OSM.
> --
> Øystein Bjørndal
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports

More information about the Imports mailing list