Re: [OSM-talk] relations within relations - walking trails
On 24/05/2011 08:41, Frederik Ramm wrote: Hi, On 05/24/11 03:18, Robin Paulson wrote: it is made up at parts of the way of other walking tracks, such as the 'coast to coast' walking track in the auckland region. problem is, i can't get my head round how to relate the two in a relation Example: Trans-European hiking route E1 http://www.openstreetmap.org/browse/relation/371743 consists, among other relations, of the "E1 German Part" http://www.openstreetmap.org/browse/relation/36367 which in turn consists of smaller relations like "E1 Hamburg", "E1 Schleswig-Holstein", etc. http://www.openstreetmap.org/browse/relation/69471 http://www.openstreetmap.org/browse/relation/71770 I have a similar issue with the nesting of international > national > regional > local bike routes where relations on the lower levels already exists. The problem (at least mine) is not to relate the existing relation objects conceptually, but to do this practically, in Potlatch. Hermann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] relations within relations - walking trails
Le 24/05/2011 03:18, Robin Paulson a écrit : i am mapping walking tracks in new zealand, and have recently added 'te araroa' - the walking track from the top of the north island to the bottom of the south. it is made up at parts of the way of other walking tracks, such as the 'coast to coast' walking track in the auckland region. problem is, i can't get my head round how to relate the two in a relation any suggestions? i'm using potlatch to do my editing, so examples using that would be good cheers I don't know if it is possible with Potlatch to put relations as members of a relation. It is quite easy on JOSM. The schema of a relation type=route including relations type=route is widely used on this program : http://wiki.openstreetmap.org/wiki/WikiProject_Europe/Long-distance_paths It is a way to split a very long route into several parts as for http://www.openstreetmap.org/browse/relation/138227 If only parts of other routes must be included, the ways can be members of several relations. Some use a type=superroute for the main relations, but it is not an existing type and it is not necessary for the route is simply a route even if members are relations. There is a good map showing the routes and rendering the osmc:symbol : http://osm.lonvia.de/hiking.html?lat=44.33868&lon=2.14782&zoom=8&layers=FFBT0 -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] relations within relations - walking trails
Hi, On 05/24/11 09:24, Hermann Peifer wrote: The problem (at least mine) is not to relate the existing relation objects conceptually, but to do this practically, in Potlatch. Someone has recently claimed that Potlatch was a full-featured editor so I'm sure it must be possible ;) Say you see a way in Potlatch which is a member of relation X (in Robin's example, the Auckland coast to coast trail), and you want to add this relation X to another relation, Y, which already exists (in Robin's example, the 'te araroa' trail). * Select the way * use "Advanced" mode to see relation X of wich way is a member * double click relation X to open relation editor * use "Advanced" mode to see relations of which X is member (currently empty) * click "Add to" to add X to another relation * since Y is unlikely to be already loaded, and thus will not appear in the list, click "Load Relation" and enter Y's relation ID * Y is loaded, and X is made a child of Y. In cases where Y doesn't already exist, use the "New Relation" button instead of "New Relation". If you don't know the relation ID of Y, and don't even know an area that you could load to find it, then it is possible that you can use Google for that, searching for something like site:www.openstreetmap.org relation type=route route=hiking e6 Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Default policy on automated edits
* Serge Wroclawski [2011-05-21 11:49 +0100]: > I was recently having a discussion about the role of automated imports > and other automated edits to our dataset. > > I think we need a simple, concise position statement on the issue. > > This video concisely summarizes my view on the issue and I suggest we > adopt it as our official default policy: > > http://www.youtube.com/watch?v=tb2Pzl1U0sY You posted this at about the same time I found and was considering an import of landuse data for Baltimore City. Unfortunately for me, the quality of the city's shapefile data was not at all up to the quality standard of OpenStreetMap, which only adds support to your position. I wrote a little about this on my diary: http://www.openstreetmap.org/user/asciiphil/diary/13891 -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- By policy, LISP has never really catered to mere mortals. And, of course, mere mortals have never really forgiven LISP for not catering to them. -- Larry Wall --- -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] low resource osm xapi instance
* Robin Paulson [2011-05-24 11:31 +1200]: > this is my query: > http://open.mapquestapi.com/xapi/api/0.6/relation[route=bus][ref=010][bbox=-174.327,-37.236,175.324,-36.519] Everything I've read about XAPI and JXAPI has said that only one predicate is supported, aside from the bbox predicate. It's possible that you're getting all the bus routes within that bbox. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- One of the great skills in using any language is knowing what not to use, what not to say. ... There's that simplicity thing again. -- Ron Jeffries --- -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] low resource osm xapi instance
On Tuesday, May 24, 2011 7:38:25 AM UTC-5, Phil! Gold wrote: > > * Robin Paulson [2011-05-24 11:31 +1200]: > > this is my query: > > > http://open.mapquestapi.com/xapi/api/0.6/relation[route=bus][ref=010][bbox=-174.327,-37.236,175.324,-36.519] > > Everything I've read about XAPI and JXAPI has said that only one predicate > is supported, aside from the bbox predicate. It's possible that you're > getting all the bus routes within that bbox. > JXAPI allows multiple predicates, but they are currently OR'd rather than AND'd like I meant them to be. The above query is akin to saying "give me all relations with route=bus OR ref=010 OR in bbox=...". And yes, bbox'd relation queries aren't quite working. In this particular case I would suggest that you query for relation[ref=010] (since it is likely to return the fewest results) and use JOSM or similar to filter out what you're looking for. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Frederik, Where you map, maybe a track is public. Not where I map. A track, like a pencil or a car, is just a phisical thing. Now I'm not requesting it should be made private by default, or public by default. I'm saying that where it 'IS' just a phisical thing, it 'can coexist' with other highway tags. The whole problem is differences between the defination of track in different countries, so talking about it just in Talk-GB somewhat misses the point. Now in any ideal system both 'tracks' as you have them, and 'tracks' as we have them can be mapped/rendered. In OSM, and on Mapnik (possibly osmarender?), both track and ROW's are under the same key, and the designation= doesn't render, although is a hacky way of tackling the problem. So yes, the exposing of the problem is specific to the UK. The problem is not specific to the UK. All we need is a phisical list, and an access list. byway/bridleway/footway are access. track/path are physical. Therefore where you map x=track can be by itself, and you get what you want. Where I map x=track can go with y=footway and the UK can also be mapped correctly. It's so incredibly simple! Hi, On 05/21/2011 01:41 PM, Ben Robbins wrote: > If it is a) (just a track), show just a track. If it is b) (a footway > (public access)) show a footway. If it is both, we need to be able to > show both. A track which does not have access=private or access=no or something is always accessible and usable for pedestrians, so why would anyone want to tag it as footway too? A footway, on the other hand, is never a track because then it would have been tagged as one. I don't understand what you're going on about, it must be something specific to the UK, and I second Richard Fairhurst's suggestion that you take this to talk-gb. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Frederik, Where you map, maybe a track is public. Not where I map. A track, like a pencil or a car, is just a phisical thing. Now I'm not requesting it should be made private by default, or public by default. I'm saying that where it 'IS' just a phisical thing, it 'can coexist' with other highway tags. The whole problem is differences between the defination of track in different countries, so talking about it just in Talk-GB somewhat misses the point. Now in any ideal system both 'tracks' as you have them, and 'tracks' as we have them can be mapped/rendered. In OSM, and on Mapnik (possibly osmarender?), both track and ROW's are under the same key, and the designation= doesn't render, although is a hacky way of tackling the problem. So yes, the exposing of the problem is specific to the UK. The problem is not specific to the UK. All we need is a phisical list, and an access list. byway/bridleway/footway are access. track/path are physical. Therefore where you map x=track can be by itself, and you get what you want. Where I map x=track can go with y=footway and the UK can also be mapped correctly. It's so incredibly simple! Hi, On 05/21/2011 01:41 PM, Ben Robbins wrote: > If it is a) (just a track), show just a track. If it is b) (a footway > (public access)) show a footway. If it is both, we need to be able to > show both. A track which does not have access=private or access=no or something is always accessible and usable for pedestrians, so why would anyone want to tag it as footway too? A footway, on the other hand, is never a track because then it would have been tagged as one. I don't understand what you're going on about, it must be something specific to the UK, and I second Richard Fairhurst's suggestion that you take this to talk-gb. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tracks and there place in society
Ben Robbins wrote: > All we need is a phisical list, and an access list. Um, we have that already. For physical tags, we have: highway=footway, or highway=cycleway, or highway=bridleway, or highway=track See http://wiki.openstreetmap.org/wiki/Duck_tagging. "If it quacks like a duck, looks like a duck, and walks like a duck, call it a duck." If you want to refine this further, there are other physical tags you can use, such as surface=. For access, we have, and always have had, "access tags" for particular users. Such as: foot=yes horse=no bicycle=permissive One of the keenest principles in OSM (and one which tag proponents would do well to remember now and then) is that "we optimise for ease of mapping". Mappers are scarce resources. So tagging systems should not impose an extra burden on the mapper, which means that there are long-established shortcuts that mappers can take. One of those is that if it both quacks like a footway (physical) and has access rights consistent with footways (access), you can infer one from the other. So a rural public footpath in the UK would typically be tagged: highway=footway (physical, implies foot access) But if it had additional permissions you could add highway=footway (physical, implies foot access) bicycle=permissive (access) If it was only available because of the generosity of some owner or other, you could add highway=footway (physical, implies foot access) foot=permissive (overrides the above) If it was a bit bigger physically, you might want to change it to: highway=track foot=yes bicycle=no horse=no There are other tags you can add to "ice the cake". surface= is the obvious physical one. In the UK, we like the 'designation' tag, which adds the legal icing to this particular cake, and which you can infer access values from. And so on. I know you've been away for a while, Ben, but it would help if you actually read some of what's happened since then. In the UK we are all happily mapping as per above and we really don't need someone who hasn't kept up (that's fine, we all have busy lives) to blunder in without checking and say "YOU'RE DOING IT WRONG". One other thing that has changed is that we now have a tagging list, and even if you won't take this to talk-gb (which you should), you should take it to tagging. Richard -- View this message in context: http://gis.638310.n2.nabble.com/Tracks-and-there-place-in-society-tp6399867p6399930.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Nelson >I agree with Richard and Frederik's suggestion that this is an issue >only in the UK, and that you take it to a forum where everybody >understands what the heck you're talking about. See previous reply. >But may I make a suggestion? That the best way to resolve differences >is to write them down in a Wiki page (easy to do in your own >namespace), link to places where your wisdom differs from the common >wisdom, insert a link from there back to your page, and say "This is >how I map." If people share your wisdom, they will follow you. This has been done. Both in and not in my own namespace. There is no wisdom in this. It's just the flaming obvious! >And a further suggestion: that if what you are doing does not conflict >with what other people are doing, then the problem isn't a mapping >problem, it's a rendering problem. Rendering problems are solvable >without requiring coordination between people. This does conflict. One person may tag highway=track to what is a footway (UK access right). It is highway=footway with a track there also. Or (according to designation=) it's highway=track designation=public_footway, but this is not recognised by mapnik, and therefore is half way to being a solution. >The easiest way to create order in OSM is to DOCUMENT HOW YOU MAP, and >DON'T MAP IN OPPOSITION TO HOW OTHER PEOPLE MAP. We don't all need to >map the same way, but the people who use the data need to understand it. Here I completely disagree. Not that it's not the commonly stated philosophy, but that it works. Standardisation is everything to data of any value. If I decide to change motorways to natural-wood then that is just wrong, it's not 'my own style'. It is important to be able to make up tags and tag as you wish where tags currently don't exist, but where something does exist unity is vital to good data. And that is why I'm posting here. I can easily get rid of the whole problem by just having a render rule sheet which has tracktype= render a track, rather than highway=track+tracktype= render a track. And yes this is a 'render' issue. But mapnik and osmarender are on OSM's main page, so it's more than just a render. There 'keys' which state what things mean contradict map features, and they influence how people map, so they are more than just a render. Now asuming progress is made on a wiki discussion page, which has happened many times, and people with similar mapping issues have come to agree with what i'm saying. The issue then is that the rulesheets for the main renders then have to follow, and then ironically lead that change, and that doesn't happen. I love the work that people have done, and mapnik is stunning, but it is vital that it and the wiki match up for the fundermental features. Now what happens is that I state the issue and a solution, and people say why it's not an issue for them, and that's that. It make's no progress. People then have issues later on, don't corralate it as being the same issue, and in dribs and drabs (rather than in it's entirety) have map feature changes made to patch there specific issue. If there was no issue, which boy I'd really like to be the real answer, then someone would say, ok tag xyz and it will render abc. Never has this happened; therefore there is a problem, becuase an alarmingly commonly appearing feature can't be mapped/rendered. And I can't stress the word 'commonly' enough. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tracks and there place in society
On 05/24/2011 01:49 PM, Richard Fairhurst wrote: > Um, we have that already. > > For physical tags, we have: > highway=footway, or > highway=cycleway, or > highway=bridleway, or > highway=track > > See http://wiki.openstreetmap.org/wiki/Duck_tagging. "If it quacks like a > duck, looks like a duck, and walks like a duck, call it a duck." It’s unfortunate then that footways, cycleways, and bridleways, and even some tracks, all fall within the same range of appearance. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
>> That said, highway= implies that the object is a public or private way >> (US terms, but usable by the public), except for highway=service and >> highway=track. >actually a highway=* is any kind of way, and access by the public >might only be implied if no other access is tagged explicitly. >Cheers, >Martin This is the problem in a nutshell. Implications, and bundling of values in a key. Let's say there is no such tag as highway=motorway. Is a 'motorway' just - highway=primary[1]; access:private[2]; car=yes[3]; motorway=yes; lorry;yes; max_speed;x; lanes:3; hardsholder:yes? i.e. do you take an implied access[1], then void that applied access[2], then state specific means of transport to build up a motorway like description through multiple specific tags?[3] now see the 'track issue' as this. highway=track; access:private; foot=yes; horse;yes; (a hundred other regulations;yes) now just like the motorway being more than just tarmack for cars motorbikes. it is 'a motorway' - a bundle of rules and regulations. A package. And this needs to render as such. The motorway example isn't a sort of primary road. It is a 'motorway'. The bridlway on a track isn't a sort of track. It is a bridlway. It can go on a track. So the aforementioned track tag combo is a 'bridleway'. highway=track; highway=bridleway not possible. highway=track; designation=public bridleway not rendering, and contradicted by what does render. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
>Ben Robbins schrieb: >> does seem like an incredably hacky way of solving this issue. >Practically everything in OSM is done in a hacky way. And actually, >that's probably the only way that works in a mostly unorganized, >freedom-promoting community. If you want strictly logical organization, >you're probably in the wrong project. ;-) >Robert KaiserThe freedom is a farse, becuase people tag to render! Sad but >true. I'm awair this sounds blunt and near on angry, but I'm not at all >bothered by this, so long as that contributors are free to map. It's not a >screech of annoyance, I'm just stating what I have realised to be true. A >realist can agree with a pessimist, but just by chance; not all the time. In >almost all other aspects of the project there is nothing to stop anyone >mapping what they want, where they want. This is freedom. In a metaphor, a person may be free to write a story, but don't hand them a pen that doesn't work, becuase that means they can't then exploit there freedom. I don't agree at all that it can only work in an unorganised way, and my previous emails propose organisation in one specific example. However, I also elaborated before to say that the answer I'm after in this thread is for 'any' way of solving the problem, even if it's drastically irrational and hacky!. I just want to map. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] relations within relations - walking trails
On 24/05/2011 10:10, Frederik Ramm wrote: Hi, On 05/24/11 09:24, Hermann Peifer wrote: The problem (at least mine) is not to relate the existing relation objects conceptually, but to do this practically, in Potlatch. * Select the way * use "Advanced" mode to see relation X of wich way is a member * double click relation X to open relation editor * use "Advanced" mode to see relations of which X is member (currently empty) * click "Add to" to add X to another relation * since Y is unlikely to be already loaded, and thus will not appear in the list, click "Load Relation" and enter Y's relation ID * Y is loaded, and X is made a child of Y. Thanks for the hints. I managed to redefine our regional bike route 51 as a relation of 2 relations (local bike routes) and 5 Ways which are needed for filling the gaps in between the local routes: http://www.openstreetmap.org/browse/relation/1588406 It looks to me that some of the web tools for checking relations are only able to present the relation's way members. They do not resolve the "sub-relations" into their way members, e.g. http://www.openstreetmap.org/?relation=1588406 and http://ra.osmsurround.org/analyze.jsp?relationId=1588406 Am I perhaps doing something wrong? In any case, the same relation looks OK here: http://osmrm.openstreetmap.de/relation.jsp?id=1588406#lon=12.52484215;lat=55.69023765;zoom=13;layer=Mpnk Hermann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Richard, I am appreciative of the lengthy reply, but I really feal like you haven't read what i have asked. Firstly let me say that I havn't been away for a long time. I simply haven't been editing much recently (I'm assuming you say this based on my edit log or something). I have read much, often, and gathered data intensively in this period. I do stand corrected however on the designation=public footway, and apologies for not finding this; however it doesn't render and is a sub-page listing, so it doesn't actually devalidate the original point. If you point was valid, then I would expect to have a clear answer returned at me, and to find myself quite stumped. Yes I have barged in, but I am welcoming a barge back out the door with an answer. Hell, I wan't nothing more than to have it thrown back at me. (question repeated at the bottom) foot=yes, horse=yes i explained the problem about in previeous emails. a motorway is more than car=yes. It's a bundle. This is more than just a word issue. It doesn't get render results, and would be hard to. "we optimise for ease of mapping" - I agree that this is where to go, but I don't see it in this case.You then go onto explain highway=footway bicycle=permissive etc. I understand this, this isn't new, hell it's been around years. What you are doing is taking 'tweak' tags, to modify a 'bundle' tag (yes made up terminology, but hopefully it makes it clear). Rendering a set of 'tweaks' would be a lot of work, and wouldn't correctly define something. It would also require modifcation on any change in the 'real world' which wouldn't be required with a 'bundle'. However...again, if it renders and is correctly mapped, does it matter, i don't know. Again to the 'ice the cake' I know all of this. I don't want to seem big headed, but this isn't isn't a 'new development' that I haven't considered, and it seems somewhat like what I have said is, ironically, has been walked in on and your telling me I've approached it all wrong. I'm sure many people are happily mapping, but if you look at the renders, it doesn't represent quite what is there, and i can't really explain this in any more detail. Also, I have no idea how to take this to talk-gb, except by simply replying there not here, and breaking up a string of responses. I did however justify why it's here, which your welcome to read. I'm still struggling some what with getting these replies in the right place, so sorry about that. So to get back on track, and I think the answer is clear. There is no way to get a byway on a track to render as a byway on a track on either mapnik or osmarender. Is that correct? And if so, does the current tagging scehem simply require a render change to allow this, and if so I shall move on to a render request/proposal where needed and forget about all the other points I initially stated and that have been missed. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tracks and there place in society
Ben Robbins wrote: > Also, I have no idea how to take this to talk-gb, except by simply > replying there not here, and breaking up a string of responses. I did > however justify why it's here, which your welcome to read. I'm still > struggling some what with getting these replies in the right place, so > sorry about that. I find nabble.com is really good for being able to follow threaded discussions on the OSM lists without having ten tons of messages dumped in your inbox every day. :) I've crossposted this to talk-gb so you can reply there. > So to get back on track, and I think the answer is clear. There is no way > to get a byway on a track to render as a byway on a track on either mapnik > or osmarender. Is that correct? And if so, does the current tagging > scehem simply require a render change to allow this Yep. The tag "highway=byway" has fallen out of use. It doesn't really make sense to anyone outside the UK. Instead, in the UK, those of us who like tagging byways tend to add "designation=restricted_byway" or "designation=byway_open_to_all_traffic" (which are the two legal categories, and imply access) to a more physical tag - usually "highway=bridleway" or "highway=track". So if you wanted a map that highlights byways, you'd just need to make sure that the stylesheet noticed those tags and chose the rendering occasionally. I _think_ Nick W's Freemap does this already. Personally I think it's fairly unlikely for either Mapnik or Osmarender, because they're worldwide stylesheets. But you can always ask! cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tracks and there place in society
On Tuesday 24 May 2011 21:47:36 Ben Robbins wrote: > Also, I have no idea how to take this to talk-gb, except by simply replying > there not here, and breaking up a string of responses. The only one breaking it up are you, by starting a new tread with every mail. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] relations within relations - walking trails
On 24 May 2011 20:10, Frederik Ramm wrote: > Say you see a way in Potlatch which is a member of relation X (in Robin's > example, the Auckland coast to coast trail), and you want to add this > relation X to another relation, Y, which already exists (in Robin's example, > the 'te araroa' trail). > > * Select the way > * use "Advanced" mode to see relation X of wich way is a member > * double click relation X to open relation editor > * use "Advanced" mode to see relations of which X is member (currently > empty) > * click "Add to" to add X to another relation > * since Y is unlikely to be already loaded, and thus will not appear in the > list, click "Load Relation" and enter Y's relation ID > * Y is loaded, and X is made a child of Y. excellent, thanks. exactly what i was after > In cases where Y doesn't already exist, use the "New Relation" button > instead of "New Relation". > > If you don't know the relation ID of Y, and don't even know an area that you > could load to find it, then it is possible that you can use Google for that, > searching for something like > > site:www.openstreetmap.org relation type=route route=hiking e6 ah, that's a good idea. i wonder - is there a way in osm to search for relations, other than using google/some other external search engine? if i know the number it's easy enough, but as you say, that's not always the case. also, if i have accidentally created a relation by mistake, how do i delete it? cheers for the help -- robin http://bumblepuppy.org/blog/?p=237 - government bill to remove basic human rights in NZ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
