[Imports] Slovenia landcover import RABA-KGZ review

Stefan Baebler stefan.baebler at gmail.com
Tue Apr 7 09:23:00 UTC 2015


On Tue, Apr 7, 2015 at 2:05 AM, Paul Norman <penorman at mac.com> wrote:

> I had a quick skim and had a few questions
>
Thanks!


> - Is the ministry okay that the source and source:date tags could be
> deleted in the future?
>
Well, i think they are aware that this might happen during later edits
after initial import due to the nature of OSM. But majority will probably
stay intact forever.


> - Why indicate the source on the objects when you are indicating it on the
> changeset?
>
I haven't seen tags on changesets being propagated with data anywhere, nor
can they be easily searched.
We tried just tagging changesets and not data in some previous attempts,
but it just makes searching harder, see the "missing" (on changeset instead
of data) source tag here:
https://taginfo.openstreetmap.org/keys/raba%3Aid#combinations

So, tags on data seem to be required, but we also add source tag on the
changesets just because we can, to clarify the source to the casual
observers of changesets.

To move the source tag from data to changeset completely we'd need
- some assurance that changeset tags are used and propagated with data
somehow, not just left in the main database, burried deep in the history
- automatic way to specify a changeset source tag during import (just
registered an issue with JOSM: https://josm.openstreetmap.de/ticket/11310 )

- I suggest adding source:date to the changeset
>
Adding or replacing? I have the same concerns as with the source tag - we
can add it, but replacing it (removing from data) is not trivial decision
for the same reasons as with source tag.


> - What are your plans for the raba:id tag you are proposing? Experience
> has shown that these types of tags fall out of sync as features are edited
> and don't tell you anything that couldn't be derived from other information
>
If we ever decide to change some tag mappings it allows us to find proper
areas
It allows us to distinguish between some areas that have different RABA_ID
in source, but we map them to same OSM tags

- raba:id makes it sound like it's an ID for the polygon, not an ID for the
> type of landuse it is
>
It is kept from the source, where it is named RABA_ID. Polygon IDs in the
source are named RABA_PID. We are not preserving these.
raba:raba_id would be excessively long
raba:kind (or similar) would loose the intuitive connection with source
attribute

- Most government farm data sources do not have a category that corresponds
> directly to landuse=meadow. This is born out by large not-meadows having
> been imported as landuse=meadow and having to be fixed in past imports. Are
> you *positive* that it is the appropriate tag? What is the translation of
> the description for id 1300?
>
"Travnik" would translate to
http://www.termania.net/iskanje?Query=travnik&sl=126
"Trajni" == permanent
"Trajni travnik (1000 m2)
Površina porasla s travo, deteljami in drugimi krmnimi rastlinami, ki se jo
redno kosi oziroma pase. Takšna površina ni v kolobarju in se ne orje. Kot
trajni travnik se šteje tudi površina, porasla s posameznimi drevesi, kjer
gostota dreves ne presega 50 dreves/hektar."
would be google translated to:
"Permanent pasture (1000 m2)
The area overgrown by grass, alfalfa and other forage crops, which is
regularly cuts and grazes. Such a surface is not rotating and are not
plowed. As permanent pasture is considered a surface covered with the
individual trees where tree density does not exceed 50 trees / ha."
in short in simple english: grass used for feeding livestock, regularly cut
or eaten. Some rare individual trees are allowed.
I suspect the osm tag originates from british use,
http://en.wikipedia.org/wiki/Meadow#Agricultural_meadow
What other appropriate tag did you have in mind?


- Is any simplification being applied?
>
No, not at the moment. We tried it earlier, but weren't satisfied with
results on shapefiles due to their structure: shared borders between two
polygons (eg neighboring forest and meadow) were simplified differently,
resulting in gaps and overlaps.
The source was drawn by hand over aerial imagery, so there aren't many
extra collinear nodes in the way.
In our test runs savings in term of saved megabytes was negligible (<10%)
while artefacts (in form of gaps and overlaps of eighboring polygons)
started to be very visible.


Some blank (or landuse-tag-free at least) areas were used for test import
> of limited scale a few days ago:
> Karst: https://www.openstreetmap.org/#map=15/45.4787/13.7335
>  Alps: https://www.openstreetmap.org/#map=15/46.4279/13.6791
>  Farmland: https://www.openstreetmap.org/#map=16/46.1345/15.5874
>
> I see multiple disjoint polygons being represented as a single polygon,
> e.g. https://www.openstreetmap.org/relation/4761048
>
Yes, we're aware of those, tried to get rid of them


> These should all be simply tagged closed ways with no relations to avoid
> maintenance problems, unnecessary multipolygons, and other problems. The
> explodecollections option of ogr2ogr may be useful here. This will also
> need cleaning up in the area you've already imported.
>
Oh, yeah, -explodecollections fixes the problem and will gladly run the
whole process again! Thanks for the tip!
Sure, we'll clean up those areas asap. Is there some trick to it in JOSM or
is the easiest to just delete or possibly revert changesets (i know this is
not trivial, but had some success a while ago)?

best regards,
Štefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20150407/fb37ab27/attachment.html>


More information about the Imports mailing list