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