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 <[email protected] > wrote: > 2012/9/24 Jochen Topf <[email protected]>: > > 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
