|
What are the current rules for showing a preview map on relations "browse" pages? Preview map for this relation does not show at all. How do I make it appear and make it show the contents of child relations with a blue line as usual for relations containing ways only? PS. I know relations are deprecated by power-users here, but since there is no reasonable service for plotting tag searches into a map, I think relatins still have their meaning at least untill such service is created. Also, relations save resources since no tag search needs to be done for showing content. |
|
The browse page simply uses the API call /api/0.6/relation/(id)/full. As you'll see from the API documentation, this does not recurse down all levels of nested relations. It merely returns the 'top level' of relation members, and that's it. This is clearly necessary to prevent overuse of the call boggling our servers. It's already been the case that people overusing the /full call has almost brought the API to its knees at times (notably when people started creating massive relations to contain the bounding boxes for Bing imagery in each country). |
|
"Relations deprecated by power users" ??? Huh... I had the exact inverse feeling that relations was the way to go, in order to better structure the data as soon as it becomes very rich and very difficult to find the related items (for example adminsitrative areas, that can be hierarchically structured, or not, and that have various levels of scalings, and impossible to edit reliably at low zoom levels. Without relations, you end up creating many data duplicates, that become even harder to unify. Relations are a very powerful tool that certainly helps finding items in the database. With the "roles" that they support, you can associate items with different types, according to a convenient schema which becomes possible to create. with those relations, you can infer various selective layers of data, to show or hide local details. Without relations, the OSM data will become a tricky bags full of knots that rapidly become impossible to structure in something that an be rendered correctly on a map (depending on the zoom level or what users want to see on a map, according to their preferences or what they are looking for). Relations also allow checking the integrity of the map data, to avoid contradictions. It simplifies the corrections needed (in case of errors, or because the actual world has effectively changed due to humane work, accidents, or natural events, or must change in a near future, where planning of works for the changes we want to add as metadata requires some organization and searches of various items on the map, or because we need to add other metadata for mapping in progress or requiring more investigation due to missing data). Who voted negatively to my comment above ? Plese add arguments instead of just this unexplained "thumb down". Because I gave arguments which outweight largely the small inconvenient (only superficially evoked above) about the performance of recursive queries on relations (which I think is a false problem: you don't need to recurse a relation, most of the time to use, i.e. search or render, what is defined by a relation).
(10 Sep '11, 04:12)
Verdy_p
Relations have clear advantages, notably for structuring the dataset and allowing powerful searches, as well as for maintaining a consistency, and hopefully completeness (at least down to some level, even if some detailed levels are missing) of the database. Relations allow faster convergence of the dataset to a stable state, where only the smallest edits at the thinnest zoom level will be needed, without breaking the upper levels that remain unchanged (even if the number of their members may locally change).
(10 Sep '11, 04:12)
Verdy_p
And anyway the "power users" evoked above are only those that are imported data coming from other databases, which are already structured with relations and layers. If we don't have relations, those bots importing data will have lots of difficulties to find how to update a zone that has been updated in the source: they will frequently generate duplicates, because there's no reliable key to make the link between what is in the OSM dataset (which may have been modified by others or by concurrent bots importing their own datasets) and what is now in the updated data source.
(10 Sep '11, 04:15)
Verdy_p
1
If you were required to say what was wrong, you would be prompted with an input field to do so. There is absolutely no compulsion to give an explanation for a thumbs-down. Also, there's a limit on this comment field for a reason. Circumventing it by making three posts defeats the point of the help system. If you want to have a debate, mailing lists are the right place, not help.osm.org.
(10 Sep '11, 07:55)
Richard ♦
Three comments was only due to limitations of length for the reply. All of them are a single reply. They use distinct, clearly separated arguments. I clearly have different opinions than you, but you don't need to expose your "opinion" as a "fact".
(10 Sep '11, 20:03)
Verdy_p
|
