[Imports] Slovenia landcover import RABA-KGZ review

Thu Apr 23 08:17:49 UTC 2015

Hi!

What are the next steps? Who gives the final / formal approval? Is there a
grace period? Not rushing things, just don't want this to be forgotten :)

We're still considering OSM tasking manager. If anyone has answer to my
previous questions (see below) or can even offer hosting we'd like to hear
from you!

all best,
Štefan

On Sun, Apr 12, 2015 at 11:55 AM, Stefan Baebler <stefan.baebler at gmail.com>
wrote:

> Hi again!
>
> We've updated the source with the latest from the ministry (released
> 2015-03-31)
> Our import site http://raba.openstreetmap.si/ was sufficient for checking
> the source against existing OSM data, and was upgraded to allow import of
> shapefiles into JOSM (not public yet).
> However, our current site lacks many features that OSM task manager
> (development version at least) already provides:
> - task locking for coordination between importers
> - tracking progress of completed tasks (splits)
> - finding the last uncompleted tasks in the sea of thousands completed
> (sweet problem :)
> It seems perfect for the job, but i am missing:
> - required: linking a shapefile for each task (we have task id in the
> shapefile zip filename) for JOSM import
> - optionally: extra tile layer overlay within web browser, on a task
> manager map (we have the tile server on german fosgiss server)
> - optionally: limiting editors to JOSM only (no other one handles
> shapefiles as good as josm's OpenData plugin afaik)
>
> Did any of other import projects use OSM tasking manager in such capacity?
> I saw Baltimore building import project and am not sure how did the tasks
> get the links to individual .osm files into their description. We'd need
> somethig similar.
> Any other tips?
>
> We're cleaning up the previous test imports in the mean time.
>
> best regards,
> Štefan
>
>
>
> On Tue, Apr 7, 2015 at 11:23 AM, Stefan Baebler <stefan.baebler at gmail.com>
> wrote:
>
>> 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/20150423/13d0309e/attachment.html>