<div dir="ltr">If there will be no objections in the following days we'll assume it is ok to start with the import.<div><br></div><div>best regards,</div><div>Stefan<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 10:17 AM, Stefan Baebler <span dir="ltr"><<a href="mailto:stefan.baebler@gmail.com" target="_blank">stefan.baebler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<div><br></div><div>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 :)</div><div><br></div><div>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!</div><div><br></div><div>all best,</div><div>Štefan</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 11:55 AM, Stefan Baebler <span dir="ltr"><<a href="mailto:stefan.baebler@gmail.com" target="_blank">stefan.baebler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi again!</div><div><br></div><div>We've updated the source with the latest from the ministry (released 2015-03-31)</div><div>Our import site <a href="http://raba.openstreetmap.si/" target="_blank">http://raba.openstreetmap.si/</a> was sufficient for checking the source against existing OSM data, and was upgraded to allow import of shapefiles into JOSM (not public yet).</div><div>However, our current site lacks many features that OSM task manager (development version at least) already provides:<br></div><div>- task locking for coordination between importers</div><div>- tracking progress of completed tasks (splits)</div><div>- finding the last uncompleted tasks in the sea of thousands completed (sweet problem :)</div><div>It seems perfect for the job, but i am missing:</div><div>- required: linking a shapefile for each task (we have task id in the shapefile zip filename) for JOSM import</div><div>- optionally: extra tile layer overlay within web browser, on a task manager map (we have the tile server on german fosgiss server)</div><div>- optionally: limiting editors to JOSM only (no other one handles shapefiles as good as josm's OpenData plugin afaik)</div><div><br></div><div>Did any of other import projects use OSM tasking manager in such capacity? <br></div><div>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.</div><div>Any other tips?</div><div><br></div><div>We're cleaning up the previous test imports in the mean time.<br></div><div><br></div><div>best regards,</div><div>Štefan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Apr 7, 2015 at 11:23 AM, Stefan Baebler <span dir="ltr"><<a href="mailto:stefan.baebler@gmail.com" target="_blank">stefan.baebler@gmail.com</a>></span> wrote:<br></span><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>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></span><div>Thanks!<br></div><span><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></span><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><span><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></span><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><span><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></span><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><span><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></span><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><span><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></span><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><span><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></span><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><span><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></span><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><span><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></span><div>Yes, we're aware of those, tried to get rid of them</div><span><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></span><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>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>