Re: [OSM-talk] Crossroad names
On 25.03.2013 22:24, Vladimir Vyskocil wrote: And there are more than 7000 nodes with highway=traffic_signals and name=* in Tokyo and its suburbs ! Another country, another solution for the same tagging "problem". And how is this unexpected? Without renderer support every community will develop its own solution. The only reason we don't see this all the time is that most of this is handled by the worldwide English speaking community. cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Software goes on, brain goes off...
On 02.06.2010 14:19, John Smith wrote: > You could extend it a little and explain more specifically: > > unsafe:foot=narrow/fast_traffic/muggers/etc routing:hints:foot:avoid=yes routing:hints:foot:comment="fast traffic" routing:hints:motorcar:avoid=yes routing:hints:motorcar:comment="street layout hard to follow for non-locals" routing:hints:motorcar:prefer=yes routing:hints:motorcar:comment="faster traffic than the parallel primary" routing:hints:bike:delay:1=40s routing:hints:bike:delay:1:times=mo-sa:0700-1300,mo-fr:1700-1900 routing:hints:bike:delay:2=20s routing:hints:bike:delay:2:times=su:1400-22:00 routing:hints:bike:comment="foot traffic avoidance costs time" Just the seed of an idea... Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] API v7
Hi, first, the following are some half-baked ideas I just want to get out of my head because I need the space they are taking up ;) Over the last weeks I have seen many discussions about how to tag some stuff. Sometimes the solution was easy, but many times there just was no solution at all. And more often than not, someone would pull some giganto relation out of the hat, that would mean that we would have more relations than ways at the end. I wanted to add to those discussions, but I also often did not find a good solution. Then it struck me. We are clinging to our current data model really hard. Too hard. Maybe we need to start exploring how to extend it to make mapping easier, instead of trying to put everything ways and nodes cannot do into relations? (I said "start exploring", emphasis on that!) Reoccurring problem 1: Way splitting. At the moment we need split ways at every point there is some change to them. While this is much better than segments were, recombining them with relations just demotes ways to segments and makes relations our new ways. Nothing gained. Going the opposite way, by not splitting the ways and giving parts of them different properties with relations is not much better---there is no support for including parts of a way in a relation, so the relations will contain one way and (hopefully) two nodes an some obscure meaning how to cut the way. (Note: "obscure" meaning "not in the data model".) Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have two sides, often they are the same, but also often they are not. Different maximum speeds, or different access rules, sometimes even different highway types (highway=residential, oneway=yes on one side, highway=cycleway the other). No clean way to model this, too. There are some tags for common cases, like cycleway=opposite, but that's all. So far for the problems. Please discuss my view on the problems (above) independently from my ideas on solving them (below). Mixing discussions on problem and solution usually lead to nothing. At the moment a way can only be tagged as a whole. There is no way to say that a tag only applies to the left side of the street, or to the second half. There are some proposals for the former, like "right:maxspeed=30" or "maxspeed.left.hgv.atnight=25". One of them may be the correct way to go, but my idea includes another solution "for free". With API.5, a way looks like this: Let's see how it changes with some additions: ... Not much yet, I only added a free-text field to th nd-element, "p" for "position". It would be optional and only constrained that it must be unique within the way. Now add 2 more attributes to the tag-element: ... Whow, we just added a bridge without cutting the way into 3 parts. Neat, but not quite where I'm headed. One more: ... Now, there is one little bit of information hidden here. Try to find out: Is this street in the UK or on mainland Europe? Ok, there's no way to find out, as there are more countries driving on the left side than just the UK. But this street would be in one of them. Why? Easy, the tags now have a direction (from, to), together with the side (that is relative to the way's direction), we can say that e.g. the maxspeed=30 part is on the left side of the way going in the direction of the way. (Some notes: (1) "both" would be the default for "side" when no value was given. (2) "side/from/to" may of course be abrv., e.g. to s/f/t. Maybe even "both/left/right" (b/l/r?)) So, this would allow us to (a) tag parts of a way diffeently, (b) tag the two directions of a way differently, and (c) tag the two sides of a way differently. (Yes, there is a difference between b and c, and it is important.) But there is still more: (d) we can now also tag nodes on a way with a direction: ... ... However, to fully use this feature, we would have to abandon the generic "name" tag. Or else there would be just no way to know what the name is for---the way or something tagged to a part of the way? However, there should not be that many features that can be tagged additionally onto a way in a useful and meaningful manner. Things that have their own way or node at the moment should keep it. Only some node features, like bus stops or traffic lights or gates, are really part of the way they belong to and would better be expressed that way instead of as extra nodes. Others, like lamp posts or subway entrances,---even though they re on the sidewalk (that is part of the road)---are better mapped as independent nodes. But I think, we can leave the details of this for the future. Let's have a quick look at some of the possible problems with this approach: Q: What happens if a new node is inserted? A: Nothing. The node will just be there, no disturbance, as the parts of the way are still addressed by the "named" nodes. Add as many node
Re: [OSM-talk] last person to edit?
graham wrote: > and correcting them this evening, but nothing in between. Is there any > kind of edit it doesn't show? Maybe someone moved the nodes? That wouldn't show up in the way's history... cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Split into "map" and "data" projects, was: Re: Actually using OpenStreetMap and the usability of thecurrent maps
Someone wrote: > let's keep > the focus on filling up the database > I'll give 100% support to the 20%, the 80% should wait some more or > better still try to do some mapping, somewhere, anywhere! That sums it up rather nicely. OSM is only about collecting data, people that are interested in using the data are not really welcome very much. So I propose to start a new project, that is about using OSM data only. Transfer the current renderers and maps to the new project, and maybe it would be possible there to et up a server farm, so people interested in different rendering styles can concentrate on the rendering styles and not on the problem of serving them. Anyone interested? That new project would first need people that have time to organize it (I really don't have), and people to raise or provide funding. cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Names, split streets and relations
Gervase Markham wrote: > Indeed. My question is: can they? :-) > (The opposite problem is the very long road which is a single way. The > name should regularly repeat, but I don't think it does on either Mapnik > or Osmarender.) I have proof-of-concept code for Osmarender (or to be more correct: for any renderer that reads osm files) that does exactly those two things. The concept I implemented splits each way into 3 parts: (1) The original ways without name or ref. (2) A way with only the name, split into same-sized parts of a configurable maximum length. (3) A number of nodes with only the ref-tag, distributed evenly with a configurable maximum distance along the way. Example, rendered with Kosmos: http://j-e-b.no-ip.com:8080/p/map.jpg Code, Perl: http://j-e-b.no-ip.com:8080/p/cwc.pl Note: The code will output a new osm file containing the original data and new ways tagged with "nameway=(any highway type)" and "name=*", and new nodes tagged with "refway=(any highway type)" and "ref=*". So you need to adapt your rendering rules to (a) not render names for highway=*, (b) render names for nameway=*, (c) render little boxes for refway=*. Also: DO NOT UPLOAD THE RESULT FILE TO THE SERVER!!! cu Henry PS: The list of supported highway types has not been updated since early May. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] General tagging strategy
Hi talk, following the discussions on the mailing lists (mainly the German one ) it seems we aren't all on the same page about tagging. While OSM is set up as as open-for-everything in regard to tagging, i think we should find a common line about which tagging strategies are to be encouraged or discouraged. Or, which ones should be prioritized because they will provide the biggest gain for all usages of OSM data. Strategy 1: Legal status. (e.g. there's sign saying it's a cycleway) Strategy 2: Common usage. (e.g. people are riding their bikes there, even if it may be forbidden -or- even though it's allowed to ride a bike here, it is a really bad (suicidal) idea to do so) Strategy 3: Physical properties (e.g. gravel with a average corn size of 1/8th inch and an average of 3 bump holes between 2 and 4 inches in diameter and 1 to 2 inches deep per meter) Strategy 4: Interpreted usability (e.g. usability for bikes is 2 on a scale from 1 to 5) BTW: I did NOT make up these examples. Not even number 3. So what do you think? No follows my opinion: First of all we absolutely need #1, that is what people want to see on a all-purpose map, and this is what every routing applications must take into account. As the next step, #4 is the most useful. It is easy for both map painting applications and routing applications to take into account to deliver the "little extra". While #3 could be used to generate the #4 data, that is not an easy task at all, neither is the tagging of that much details in the first place. While #2 looks interesting at first glance, most of that information can be extracted from #4 tags. Although I see the need for "routing hints" in the future, but that's another discussion to come. There may be applications for #3 data, but I don't see anything that could be in the Top10 of a OSM data consumer list. It is just to detailed to be useful for most applications. Just remember, humans are much better in interpreting complex data sets. cu Henry signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
