If there will be no objections in the following days we'll assume it is ok to start with the import.
best regards, Stefan On Thu, Apr 23, 2015 at 10:17 AM, Stefan Baebler <[email protected]> wrote: > 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 <[email protected] > > 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 <[email protected] >> > wrote: >> >>> On Tue, Apr 7, 2015 at 2:05 AM, Paul Norman <[email protected]> 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 >>> >>> >>> >>> >> >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
