I liked the Tag Central presentation. I have searched for more information but I can't find much. Has there been any more development on the Tag Central idea?
Dave On Mon, Sep 24, 2012 at 6:54 AM, Jais Pedersen <j...@pedersens.net> wrote: > The problem with lengthy blog posts is that they result in lengthy replies > and > probably a long thread :-) > > I think most users never look at the edit history and most of us that > occasionally do look at it, do it mainly to get some idea about the validity > of > the data. To use our data to make historical maps, we have to finish making > the > current "snapshot" of the world first, then it might be possible to start > looking at a way of making different more or less linked snapshots in time. > I > agree it might not be easy, but I think that just because it is difficult to > build a space shuttle, that should not stop us from trying to build the car > that > most of us actually need first. > > The rendering performance problem for lower zoom levels, is probably better > handled during import/update. If apmon keeps improving the performance of > osm2pgsql, then it might be realistic to have a "normal" high zoom database > and > a separate low zoom database where only the tags need for low zoom levels > are > imported and the geometries are simplified (it might be as simple as using > ST_simplify, but I have no experience with that and currently no access to > capable hardware for testing). From Frederics SOTM slides it looks like the > sweet spot is around zoom level 8. > > JOSM already handles different layers quite well including copy/cut/paste > and > basically just needs to keep track of the different data sources and have an > option to "paste with reference". Other editors that don't want to bother > the > user with the complications of layers can have a combined view of the layers > and > silently add and/or change objects in the appropriate layers depending on > the > type. This of course requires that we split the main database into layers by > tags. > > If we split the layers by tags, the layer repository can be used to keep > track > of what layer a tag belongs to. That will take away a little of our freedom > to > tag anyway you like, by requiring that you register your new tag with the > repository first. We could use something like the Tag Central [1][2] idea > for > that and I don't think it would be such bad thing, if you were required to > document the tags you invent. It would also make it easier for other bird > watchers to discover that there is a bird migration layer and how to use the > special tags for it. > > The layer repository could also have an optional link to a tile server, that > you > can use as background, ex. you can work on the admin area layer without > having > to load the entire dataset for a country - I didn't try, but I expect JOSM > would > not handle loading the France or Germany extracts very well, if at all. > > I do share Martins concerns about how to handle updates to linked data, but > maybe > that can be solved by having both hard and soft links, so the user that > creates > the link makes the decision. That will also force you to think about if > these > two areas are actually linked or did you just reuse the nodes that were > conveniently already there? > > If you have both layers open, you could have a "also update soft links" mode > for > those that know what they are doing and in the historic layer we could keep > the > soft links in an "un-linked, but not yet completely destroyed" state, where > somebody can manually check if the link should be restored or removed. > > That will not completely solve the problem with historic maps, but if that > is > the only issue, I don't think that should stop us. > > @Lester: Did you try the merge layer feature in JOSM or did I misunderstand > your > problem? > > [1] Video: http://vimeo.com/14776099 > [2] Slides: http://www.frankieandshadow.com/sotm10/tagcentral.pdf > > /Jais > > > On Mon, Sep 24, 2012 at 4:35 PM, Martin Koppenhoefer > <dieterdre...@gmail.com> wrote: >> >> 2012/9/24 Jochen Topf <joc...@remote.org>: >> > http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html >> > If anybody wants to comment, I think this mailing list is the right >> > place. >> >> >> IMHO there are different requirements for these layers according to >> what is on them and how it is related to the data on other layers. >> >> E.g. the birds routes would not create much problems because they are >> only roughly linked to current OSM-data, while for the historic data >> layer I think it would be desirable to have that directly linked (or >> at least a possibility to link it) to the current data. This is >> important when there are remains of the historic objects that are >> still (also partly) present in the current world. These could be >> either physical but also "conceptual" (e.g. parcels of a roman castrum >> which are still valid for todays town, leading the streets (=voids) to >> be where they used to be). >> Other examples for this might be city walls, ruins and other remains >> of historic buildings, historic walls, ...). The problem here is not >> with static data but arises from the fact that our current OSM data is >> in continuous motion: as soon as someone moves the current city wall >> (or refines it) in order to improve it, the historic-layer city-walls >> should also be refined (or they will get out of sync). We could maybe >> have something like hardlinks on filesystems for OSM-objects >> (nodes/way/relations) to solve this? In other cases it might not be >> desirable that historic objects change when the current objects get >> modified (i.e. this will also raise complexity a lot for the mapper, >> as he will have to decide for his edits whether they should also be >> applied to linked data, which is likely "specialist data"). >> >> Another similar concern I have with layers is that of fragmentation of >> the data which currently is all in the one main layer. In the past >> there were some people asking for separate thematic layers like >> landuse (e.g. in order to not show them in their editor), and >> introducing a layer-system might likely lead to fullfilling this >> desire. I see this as a problem because landuse is strongly tied to >> other objects like streets, building lots, and other polygons (e.g. >> amenity, leisure, place-polygons) and moving or editing only part of >> this data will also lead to out-of-sync-geometry between layers (won't >> fit one over the other). To avoid this people would have to look at >> all layers, which in the end eliminates the benefits of separate >> layers. >> >> cheers, >> Martin >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk > > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
