On Tue, Apr 7, 2015 at 2:05 AM, Paul Norman <penor...@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
_______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
