On Mon, Sep 24, 2012 at 08:54:08PM +0700, Jais Pedersen wrote: > The problem with lengthy blog posts is that they result in lengthy replies > and > probably a long thread :-)
Thats not a problem. Thats good! :-) > 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 problem is that there are people out there that want to make historical maps today. You can't tell them to go away and come back in ten years when we come around to help them. What I want to give them is some minimal tool so that they *can* work on their stuff without disturbing the OSM "mainstream". > 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. This is much more difficult than simplifying some geometries. We already have some "low zoom" data in an extra table in osm2pgsql und many people have already done line simplification in their data. I wrote software myself that can extract simplified motorways etc. from OSM data for use in small scale maps. But that is really hard to do properly and it doesn't always work. Having humans in the loop makes nicer maps more feasible. All I am talking about an "option" here. If you don't want to use this for your map, thats fine. But I certainly would have needed that option many times already. > 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. Frankly I don't think we can ever solve the "linked data" problem. Linking structured data to other structured data in a meaningful way is hard to do. Of course we can have some kind of "link" between the data and I think we should. But the link will only link between generic objects and that doesn't really help us much. Most of the semantic information in OSM is inside the tags and they are not really accessible for linking. What I mean is this: Say you have a node today with an address tag. You then create a building outline and move the address tag to that building. Conventional wisdom is to at least re-use the node inside your new building outline way, to create some kind of connection. But that might not be possible in all cases and, anyway, not everybody does it that way. So there is some connection lost here. But this is a very specialized case anway. How would we design generic tools that allow us to find corresponding data in the same database over time or in different databases? I think a possible approach in this case is similar to what we have been doing for a long time with our semi-automated quality management tools: We use the data itself and especially redundancies in our data to find corresponding data. We tell the mapper about those cases and let them work out the details and fix the data. So if we have several databases and extra tables that link objects ids from one database to the other we can write tools that tell us: "Object x changed in this database in some possibly important way but object y in the other database did not change in a correspoding way. Please look into that." The important thing is that those tools can be implemented outside the databases themselves, which makes development much easier. And they can be implemented specially for many different use cases by the interested parties themselves. This approach is by no means perfect, but I fear thats all we can get. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
