<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 7, 2015 at 2:05 AM, Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">I had a quick skim and had a few questions<br></div></blockquote><div>Thanks!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">- Is the ministry okay that the source and source:date tags could be
    deleted in the future?<br></div></blockquote><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    - Why indicate the source on the objects when you are indicating it
    on the changeset?<br></div></blockquote><div>I haven't seen tags on changesets being propagated with data anywhere, nor can they be easily searched.<br></div><div>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:</div><div><a href="https://taginfo.openstreetmap.org/keys/raba%3Aid#combinations" target="_blank">https://taginfo.openstreetmap.org/keys/raba%3Aid#combinations</a><br></div><div><br></div><div>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.</div><div><br></div><div>To move the source tag from data to changeset completely we'd need</div><div>- some assurance that changeset tags are used and propagated with data somehow, not just left in the main database, burried deep in the history</div><div>- automatic way to specify a changeset source tag during import (just registered an issue with JOSM: <a href="https://josm.openstreetmap.de/ticket/11310" target="_blank">https://josm.openstreetmap.de/ticket/11310</a> ) <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    - I suggest adding source:date to the changeset<br></div></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">- 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<br></div></blockquote><div>If we ever decide to change some tag mappings it allows us to find proper areas</div><div>It allows us to distinguish between some areas that have different RABA_ID in source, but we map them to same OSM tags</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    - raba:id makes it sound like it's an ID for the polygon, not an ID
    for the type of landuse it is<br></div></blockquote><div>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.</div><div>raba:raba_id would be excessively long</div><div>raba:kind (or similar) would loose the intuitive connection with source attribute</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">- 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 <b>positive</b> that it is the
    appropriate tag? What is the translation of the description for id
    1300?<br></div></blockquote><div><div>"Travnik" would translate to <a href="http://www.termania.net/iskanje?Query=travnik&sl=126" target="_blank">http://www.termania.net/iskanje?Query=travnik&sl=126</a></div></div><div>"Trajni" == permanent</div><div>"Trajni travnik (1000 m2)</div><div>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."</div><div>would be google translated to:</div><div>"Permanent pasture (1000 m2)<br></div><div>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."</div><div>in short in simple english: grass used for feeding livestock, regularly cut or eaten. Some rare individual trees are allowed.</div><div>I suspect the osm tag originates from british use, <a href="http://en.wikipedia.org/wiki/Meadow#Agricultural_meadow" target="_blank">http://en.wikipedia.org/wiki/Meadow#Agricultural_meadow</a><br></div><div>What other appropriate tag did you have in mind?</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">- Is any simplification being applied?</div></blockquote><div>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.</div><div>The source was drawn by hand over aerial imagery, so there aren't many extra collinear nodes in the way.</div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><blockquote type="cite"><div dir="ltr"><div>Some blank (or landuse-tag-free at least) areas were used
          for test import of limited scale a few days ago:</div>
        <div>Karst: <a href="https://www.openstreetmap.org/#map=15/45.4787/13.7335" target="_blank">https://www.openstreetmap.org/#map=15/45.4787/13.7335</a><br>
        </div>
        <div>Alps: <a href="https://www.openstreetmap.org/#map=15/46.4279/13.6791" target="_blank">https://www.openstreetmap.org/#map=15/46.4279/13.6791</a><br>
        </div>
        <div>Farmland: <a href="https://www.openstreetmap.org/#map=16/46.1345/15.5874" target="_blank">https://www.openstreetmap.org/#map=16/46.1345/15.5874</a></div>
      </div>
    </blockquote></span>
    I see multiple disjoint polygons being represented as a single
    polygon, e.g. <a href="https://www.openstreetmap.org/relation/4761048" target="_blank">https://www.openstreetmap.org/relation/4761048</a></div></blockquote><div>Yes, we're aware of those, tried to get rid of them</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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.<br></div></blockquote><div>Oh, yeah, -explodecollections fixes the problem and will gladly run the whole process again! Thanks for the tip!<br></div><div><div>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)? </div></div><div><br></div><div>best regards,</div><div>Štefan</div><div><br></div><div><br></div></div><br></div></div>