[Tagging] Restrictions based on the weight of a trailer
Hi! I'm looking for a possibility to tag the following traffic sign: http://vonwald.info/osm/images/dscn5532.jpg It forbids from 05:00 to 22:00 overtaking for HGV with a weight of more than 7.5t and also for vehicles with a trailer, when the trailer weights more than 750kg. So far I have: overtaking:hgv:conditional=no @ (05:00-22:00 AND weight7.5 ) overtaking:trailer:conditional=no @ My problem is I don't know how to tag the weight of the trailer. Do we have a tag for this? regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
Hi! After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) relations are present, create a new relation only for this part, remove those ways from the other relations and instead add the newly created relation as part of the public transport relation. This of course makes everything more complicated for the relations and I'm not sure if the creator of those wouldn't object. And then? Happy edit fighting? To cut a long story short: I think we need a solution for this situation and we need it before the public transport relations spread more. The relations from my example are over 100km each. This effectively creates ways with several 100km length. How are the odds that more than one person is editing such a long way at the same time? Right now if I'm not really lucky I get usually 22 (twenty two) conflicts when trying to edit this specific motorway. Needless to say that the conflict resolution fails every time - to be more precise: the conflict resolution creates duplicate ways each time tried (and failed). Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
On Tue, Dec 4, 2012 at 10:09 AM, Martin Vonwald imagic@gmail.com wrote: Hi! After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) Or remove all routes from the main database, it might even be easier to edit bus routes if you try not to use OSM relations for those things. But then maybe the no-right-turn relation is too complicated as well. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Henning Scholland o...@aighes.de: After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) relations are present, create a new relation only for this part, remove those ways from the other relations and instead add the newly created relation as part of the public transport relation. What's the benefit? In josm there are less relation displayed, if you select the way. If you edit the way, you'll have to do the same things as there were 5 single relations and you additional have to analyse master relation before. In Potlatch and josm relation overview you'll get even more relations. Editing theses relations is even more complicated. So I think this solution wont make it better. You forgot one detail: if there is only one relation that only covers part of all those bus routes then only one of those artifical relation-ways is created which is also much shorter and therefore the probability of conflicts is much smaller. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Erik Johansson erjo...@gmail.com: On Tue, Dec 4, 2012 at 10:09 AM, Martin Vonwald imagic@gmail.com wrote: Hi! After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) Or remove all routes from the main database, it might even be easier to edit bus routes if you try not to use OSM relations for those things. If you are brave enough to do that: go ahead. ;-) But then maybe the no-right-turn relation is too complicated as well. The problem is not really the complexity of those relations, but the fact that they create some kind of extreme long relation-way. The probability of two (or more) people working at the same time on a 200km relation-way is much higher than on a 200m ordinary way and therefore the conflict probability is much higher with those relation-ways. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
On Mon, Dec 3, 2012 at 8:27 PM, Ole Nielsen on-...@xs4all.nl wrote: I intentionally chose not to deprecate maxspeed:wet as I had the feeling that doing so might upset some people and I didn't want such minor issues to affect the voting process. Of course I will recommend to use the conditional scheme and hope we can make a recommendation to deprecate the maxspeed:wet tag if there is no strong opposition to do so. Of course It's not the first time I see such process : propose a new tag, do not say it would deprecate anything until vote is accepted (or - if you don't like vote : consensus is reached, or no more complains), wait few months, change the wiki from do not deprecate to recommend to deprecate, wait few months, remove recommend from the wiki to just deprecated. This remembers me the bus_stop and platform discussions. Or the second user account for imports. These are unfair and sneaky methods to change things in OSM. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
Am 04.12.2012 10:50, schrieb Martin Vonwald: 2012/12/4 Henning Scholland o...@aighes.de: After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) relations are present, create a new relation only for this part, remove those ways from the other relations and instead add the newly created relation as part of the public transport relation. What's the benefit? In josm there are less relation displayed, if you select the way. If you edit the way, you'll have to do the same things as there were 5 single relations and you additional have to analyse master relation before. In Potlatch and josm relation overview you'll get even more relations. Editing theses relations is even more complicated. So I think this solution wont make it better. You forgot one detail: if there is only one relation that only covers part of all those bus routes then only one of those artifical relation-ways is created which is also much shorter and therefore the probability of conflicts is much smaller. What do you mean with artifical relation-ways? The Membership in a relation is a property of a way. Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
Am 04.12.2012 10:53, schrieb Martin Vonwald: The problem is not really the complexity of those relations, but the fact that they create some kind of extreme long relation-way. The probability of two (or more) people working at the same time on a 200km relation-way is much higher than on a 200m ordinary way and therefore the conflict probability is much higher with those relation-ways. In Germany we created super-relations and split longer relations into several parts. Mainly used by bicycle-relations. Would this solve you problem? But it's normally split not 200m-parts ;) Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Henning Scholland o...@aighes.de: What do you mean with artifical relation-ways? The Membership in a relation is a property of a way. All ways in the relations create some kind of this artificial relation-way. Because if you split any way contained in this relation - which might be longer than a few hundred kilometres - you change the relation. If anyone else is doing the same - anywhere within those few hundred kilometres - you create a conflict. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Henning Scholland o...@aighes.de: Am 04.12.2012 10:53, schrieb Martin Vonwald: The problem is not really the complexity of those relations, but the fact that they create some kind of extreme long relation-way. The probability of two (or more) people working at the same time on a 200km relation-way is much higher than on a 200m ordinary way and therefore the conflict probability is much higher with those relation-ways. In Germany we created super-relations and split longer relations into several parts. Mainly used by bicycle-relations. Would this solve you problem? But it's normally split not 200m-parts ;) That is exactly what I wrote: create a new relation only for this part, remove those ways from the other relations and instead add the newly created relation as part of the public transport relation. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On Tue, Dec 4, 2012 at 5:49 AM, Friedrich Volkmann b...@volki.at wrote: The only use of separate address nodes by now is that they make Mapnik display a house number. But speaking of Mapnik... if there are 5 POIs in a house, and Mapnik has no signature for those POIs, it displays the house number for each POI instead, resulting in 5x the same number. That makes addresses on nodes problematic for Mapnik too. One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. The node does not have to be be floating but can be attached on the building way, either on the building entrance or where post boxes are physically (or vitually). Then it is to the software consumers to find the nearest node address when they search information about a specific POI. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
On Tue, 4 Dec 2012, Martin Vonwald wrote: 2012/12/4 Erik Johansson erjo...@gmail.com: But then maybe the no-right-turn relation is too complicated as well. The problem is not really the complexity of those relations, but the fact that they create some kind of extreme long relation-way. The probability of two (or more) people working at the same time on a 200km relation-way is much higher than on a 200m ordinary way and therefore the conflict probability is much higher with those relation-ways. If so, it must be mainly problem with the tools handling the relation conflicts. If two people edit a route relation in clearly different places, merging the results should be automatic (similar to what e.g., git does while merging code in a single file that gets edited from two different, non-conflicting places). -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Martin Vonwald imagic@gmail.com Hi! After reading all the responses I have to conclude that we don't really have a perfect solution right now. I guess the best would be a cleanup of the relations: on ways where more than one (or two) relations are present, create a new relation only for this part, remove those ways from the other relations and instead add the newly created relation as part of the public transport relation. This of course makes everything more complicated for the relations and I'm not sure if the creator of those wouldn't object. And then? Happy edit fighting? To cut a long story short: I think we need a solution for this situation and we need it before the public transport relations spread more. That's exactly what I said before the discussion went off on a tangent of 'route hinting'. A proposal for this already exists: http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments which I tried to apply to this relation: http://www.openstreetmap.org/browse/relation/2336780 Unfortunately it's not rendered, otherwise I'd applied it to all bus routes I maintain. It's true it does add a little bit of complexity when working with those route relations and it's not immediately apparent anymore whether a route is continuous. It has a lot of other advantages though, like maintainability. Instead of changing 60 relations when something changes, now only 2 need to be changed (One in each direction). For some very busy stretches of asphalt I'd create a relation from stop_position to stop_position. http://www.openstreetmap.org/?lat=50.87998lon=4.7045zoom=17layers=T For others the 'segment' could span several stops for common parts between routes. http://www.openstreetmap.org/?lat=50.86633lon=4.73224zoom=16layers=T Polyglot ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Ilpo Järvinen ilpo.jarvi...@helsinki.fi: On Tue, 4 Dec 2012, Martin Vonwald wrote: 2012/12/4 Erik Johansson erjo...@gmail.com: But then maybe the no-right-turn relation is too complicated as well. The problem is not really the complexity of those relations, but the fact that they create some kind of extreme long relation-way. The probability of two (or more) people working at the same time on a 200km relation-way is much higher than on a 200m ordinary way and therefore the conflict probability is much higher with those relation-ways. If so, it must be mainly problem with the tools handling the relation conflicts. If two people edit a route relation in clearly different places, merging the results should be automatic (similar to what e.g., git does while merging code in a single file that gets edited from two different, non-conflicting places). I fully agree with you. But that means changing the API (to be more precise: the backend of it) and that's nothing that will happen until next week ;-) Some kind of automatic conflict resolution within the editors can only improve this situation slightly, because the editor can't handle the resolution as an atomic action (as the API can) and therefore while the editor is resolving the conflict and uploading again, another change to the relation might already have happened and the conflict-resolution-conflict-cycle begins again. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Jo winfi...@gmail.com: That's exactly what I said before the discussion went off on a tangent of 'route hinting'. A proposal for this already exists: http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments Open the vote and you got at least two approvals (yours and mine). But one problem stays: if those routes are not rendered, no-one will care. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Pieren pier...@gmail.com: On Tue, Dec 4, 2012 at 5:49 AM, Friedrich Volkmann b...@volki.at wrote: The only use of separate address nodes by now is that they make Mapnik display a house number. But speaking of Mapnik... if there are 5 POIs in a house, and Mapnik has no signature for those POIs, it displays the house number for each POI instead, resulting in 5x the same number. That makes addresses on nodes problematic for Mapnik too. One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. The node does not have to be be floating but can be attached on the building way, either on the building entrance or where post boxes are physically (or vitually). Then it is to the software consumers to find the nearest node address when they search information about a specific POI. I agree with you. If a building has more than one address I usually put it on the relevant entrance. If there is no relevant entrance I put it on a node on the building way, where the plate is. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
On Tue, Dec 4, 2012 at 11:28 AM, Martin Vonwald imagic@gmail.com wrote: A proposal for this already exists: http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments Open the vote and you got at least two approvals (yours and mine). We have the same issue with all big relations like national admin boundaries or any big multipolygons (e.g. lakes, forests, motorways). It would be nice to define a more generic concept about parent-child super-relations instead of focusing on routes... Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
Martin's problem would be solved if the extra-long relation is broken up into segments. Which you are just as free to do as splitting a way in two. Keep the relation tags on each segment, just like you'd do if you split a way. (This is rather different to Jo's proposal, which involves shifting tags onto a parent relation) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Richard Mann richard.mann.westoxf...@gmail.com Martin's problem would be solved if the extra-long relation is broken up into segments. Which you are just as free to do as splitting a way in two. Keep the relation tags on each segment, just like you'd do if you split a way. (This is rather different to Jo's proposal, which involves shifting tags onto a parent relation) A bus line goes from a starting point to a terminus. It would seem strange to me to split such relation at arbitary places in the middle in order to avoid conflicts when editing. So it's not comparable to splitting a street because the properties or relation membership changes. It would still render correctly, but you lose the semantics of what the relation stood for. The proposal for the route segments was made 1,5 years ago, but never went to a vote. I agree that it should not simply apply to route relations. There are some relations where it is already in use. If I'm not mistaken long foot/hiking routes. Rather than 'winning' a vote we should try to get support from öpnv-karte, transportmap and OSMtransport. Once those big players render it, the rest will most likely follow. Jo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Pieren pier...@gmail.com wrote: One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element An address is not a feature. An address is an attribute of a feature. An address never exists on its own in the real world. There cannot be an address somewhere in no man's land. It always refers to some property. A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. This is not how mappers usually handle this case. They set the address on each POI, because otherwise applications cannot find out which POI has which address. The node does not have to be be floating but can be attached on the building way, either on the building entrance or where post boxes are physically (or vitually). There are many possibilities where to put the node, but each of them has some cases where it won't work, and there are always arguments and edit wars about this. This is because each of the position is only part of the truth. The whole truth is that an address is actually an attribute of a 2- oder 3-dimensional object. Then it is to the software consumers to find the nearest node address when they search information about a specific POI. The nearest node may not be the right one. E.g. the nearest node may be the address node of the next house. Or it may even be a node on the other side of the street! And not to mention that this won't do it for multiple addresses. -- Friedrich K. Volkmann Davidgasse 76-80/40/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Am 04/dic/2012 um 11:16 schrieb Pieren pier...@gmail.com: On Tue, Dec 4, 2012 at 5:49 AM, Friedrich Volkmann b...@volki.at wrote: The only use of separate address nodes by now is that they make Mapnik display a house number. But speaking of Mapnik... if there are 5 POIs in a house, and Mapnik has no signature for those POIs, it displays the house number for each POI instead, resulting in 5x the same number. That makes addresses on nodes problematic for Mapnik too. One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. if you see the address as feature it should be an area and not a node, but if you add it to a POI I'd see it as an attribute and there is no problem in adding it multiple times. Putting an address-node on a building-outline to mark an entrance seems odd, why not tag the entrance with entrance and put the address on the whole building outline (or even on the whole site it applies to if you have this information)? If there are multiple addresses for the same area one can simply create multiple address-objects. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Of course
It's not the first time I see such process : propose a new tag, do not
say it would deprecate anything until vote is accepted (or - if you
don't like vote : consensus is reached, or no more complains), wait
few months, change the wiki from do not deprecate to recommend to
deprecate, wait few months, remove recommend from the wiki to just
deprecated. This remembers me the bus_stop and platform
discussions. Or the second user account for imports.
These are unfair and sneaky methods to change things in OSM.
Are you against changing things in general or do you like to always
cut off old schemes completely without legacy support?
Because the described way is about the best solution I could come up
with that both allows change and gives the crowd enough time to adapt.
The only thing that is missing is that the wiki changes should be
backed up by taginfo data to support the claim.
It even allows hardliners to keep tagging the old way indefinably.
('Deprecated' doesn't mean 'forbidden'.)
So: how would you change things in OSM?
Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Friedrich Volkmann b...@volki.at: Pieren pier...@gmail.com wrote: One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element An address is not a feature. An address is an attribute of a feature. An address never exists on its own in the real world. There cannot be an address somewhere in no man's land. It always refers to some property. generally agree with you, but you might also see it as a feature (in which case a node is a poor representation) A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. This is not how mappers usually handle this case. They set the address on each POI, because otherwise applications cannot find out which POI has which address. applications could find out which POIs are inside which address-polygon, but it requires some processing, it is not impossible, but it might take too long if you want up to date data (incremental updates) depending on your calculation capacities. There are many possibilities where to put the node, but each of them has some cases where it won't work, and there are always arguments and edit wars about this. This is because each of the position is only part of the truth. The whole truth is that an address is actually an attribute of a 2- oder 3-dimensional object. +1 cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
I think Martin is complaining about long-distance coach services. Splitting them into within-urban and extra-urban segments would seem fairly sensible to me. On Tue, Dec 4, 2012 at 11:08 AM, Jo winfi...@gmail.com wrote: 2012/12/4 Richard Mann richard.mann.westoxf...@gmail.com Martin's problem would be solved if the extra-long relation is broken up into segments. Which you are just as free to do as splitting a way in two. Keep the relation tags on each segment, just like you'd do if you split a way. (This is rather different to Jo's proposal, which involves shifting tags onto a parent relation) A bus line goes from a starting point to a terminus. It would seem strange to me to split such relation at arbitary places in the middle in order to avoid conflicts when editing. So it's not comparable to splitting a street because the properties or relation membership changes. It would still render correctly, but you lose the semantics of what the relation stood for. The proposal for the route segments was made 1,5 years ago, but never went to a vote. I agree that it should not simply apply to route relations. There are some relations where it is already in use. If I'm not mistaken long foot/hiking routes. Rather than 'winning' a vote we should try to get support from öpnv-karte, transportmap and OSMtransport. Once those big players render it, the rest will most likely follow. Jo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Jo winfi...@gmail.com: That's exactly what I said before the discussion went off on a tangent of 'route hinting'. A proposal for this already exists: http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments This is already done, e.g. http://www.openstreetmap.org/browse/relation/1471006 http://www.openstreetmap.org/browse/relation/955907 though there is not segment-tag (not sure if it should be there, as in this example the relation XY part of Latium is not a segment of the latium part but is the whole route for latium. It is a segment of the part of Italy which is a segment of the whole relation, but this is already in the data without any explicit tag). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to solve the problem with relation overload?
2012/12/4 Jo winfi...@gmail.com: 2012/12/4 Richard Mann richard.mann.westoxf...@gmail.com Martin's problem would be solved if the extra-long relation is broken up into segments. Which you are just as free to do as splitting a way in two. Keep the relation tags on each segment, just like you'd do if you split a way. (This is rather different to Jo's proposal, which involves shifting tags onto a parent relation) A bus line goes from a starting point to a terminus. It would seem strange to me to split such relation at arbitary places in the middle in order to avoid conflicts when editing. it won't be arbitrary locations but you would have segments of routes which are part several route relations. Think of a simple bus route, usually you will have 3 relations (one forward, one backward, one to combine the two), now you would have relations of short pieces as members of the forward and backward relations where they represent segments of roads that are used by several route relations. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
2012/12/4 Ronnie Soak chaoschaos0...@googlemail.com:
Are you against changing things in general or do you like to always
cut off old schemes completely without legacy support?
Because the described way is about the best solution I could come up
with that both allows change and gives the crowd enough time to adapt.
The only thing that is missing is that the wiki changes should be
backed up by taginfo data to support the claim.
It even allows hardliners to keep tagging the old way indefinably.
('Deprecated' doesn't mean 'forbidden'.)
I somehow agree with both of you, it really depends on the case (how
intensively a tag is already used). It doesn't make any sense IMHO to
deprecate something like highway=bus_stop if 90% of all bus stops are
tagged like this (and btw. the public_transport platform version has
mostly disadvantages, needs more tags to end up with the same
meaning).
cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Martin Koppenhoefer dieterdre...@gmail.com: if you see the address as feature it should be an area and not a node, but if you add it to a POI I'd see it as an attribute and there is no problem in adding it multiple times. Putting an address-node on a building-outline to mark an entrance seems odd, why not tag the entrance with entrance and put the address on the whole building outline (or even on the whole site it applies to if you have this information)? We are running in circles here. Putting it on the building outline or the site outline/relation seems right, but doesn't work for multiple addresses on the same building/site. If there are multiple addresses for the same area one can simply create multiple address-objects. You just said above that addresses are not features, but attributes. So what is an 'address object' and how can I create multiple of them? If you mean to create multiple building outlines to tag an address on each, we are clearly in the realm of 'one feature, one OSM element'. May I also add that, at least in theory, we are talking about a spacial database which should have no problem in determine which element lies within which other element. So an amenity node inside a building has an implicit relation to that building and could 'inherit' its address. So there is, again: in theory, no need for repeating the address on each POI. In the real world, we should of course just add that little but of redundancy because most data consumers and even our database are not that 'spacial aware'. I tried to find out what an address really points to here in Germany. I wasn't successful. You get a house number for a parcel of land, even without a house on it, but only if it is already connected to a street. When you build a house you definitely get one. Or the house inherits the number from the parcel. But you can get more than one number if you build multiple houses. (Or you can build additional houses without a number.) You can also get more numbers if you have multiple entrances to a building. But it is no problem for several flats in the same building to share the same number too. I couldn't find out on who's discretion this happens. And then there is the postal service, which some times even defines its own scheme when it for instance give a whole postal code range to a company, sets the address of a building to some street/city it isn't located at/in or delivers to mailboxes that are not in the same street then the buildings they belong to. my 2 cents, Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On 4 December 2012 12:22, Martin Koppenhoefer dieterdre...@gmail.comwrote: Am 04/dic/2012 um 11:16 schrieb Pieren pier...@gmail.com: On Tue, Dec 4, 2012 at 5:49 AM, Friedrich Volkmann b...@volki.at wrote: The only use of separate address nodes by now is that they make Mapnik display a house number. But speaking of Mapnik... if there are 5 POIs in a house, and Mapnik has no signature for those POIs, it displays the house number for each POI instead, resulting in 5x the same number. That makes addresses on nodes problematic for Mapnik too. One principle I like in OSM is one feature, one OSM element: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element A single address should be tagged only once. If you have several POI's with the same address, tag the address on its own node. if you see the address as feature it should be an area and not a node, but if you add it to a POI I'd see it as an attribute and there is no problem in adding it multiple times. Putting an address-node on a building-outline to mark an entrance seems odd, why not tag the entrance with entrance and put the address on the whole building outline (or even on the whole site it applies to if you have this information)? If there are multiple addresses for the same area one can simply create multiple address-objects. This seems just weird. In my book addresses are features in their own right and should not be mixed in the same element as amenities or shops. The first problem would be that it would make it impossible to render addresses and POIs at the same time. The second problem would be that there would be multiple instances of the same address. If there really is a need to bind address and POI together then create a relation for that. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Ronnie Soak chaoschaos0...@googlemail.com: 2012/12/4 Martin Koppenhoefer dieterdre...@gmail.com: if you see the address as feature it should be an area and not a node, but if you add it to a POI I'd see it as an attribute and there is no problem in adding it multiple times. Putting an address-node on a building-outline to mark an entrance seems odd, why not tag the entrance with entrance and put the address on the whole building outline (or even on the whole site it applies to if you have this information)? We are running in circles here. Putting it on the building outline or the site outline/relation seems right, but doesn't work for multiple addresses on the same building/site. it does (if like in the examples given above the same appartment has multiple addresses you will add several addresses for the same polygon (e.g. by using multipolygons or overlapping ways)), and in the other case (multiple addresses inside the same building, but every spot has only one address) you won't attach the address to the whole building outline, but to the part it applies to. You just said above that addresses are not features, but attributes. So what is an 'address object' and how can I create multiple of them? no, I said you can see it either as attribute or as feature. If you mean to create multiple building outlines to tag an address on each, we are clearly in the realm of 'one feature, one OSM element'. delete the word building and we are there ;-), several polygons. So an amenity node inside a building has an implicit relation to that building and could 'inherit' its address. So there is, again: in theory, no need for repeating the address on each POI. ...as long as you don't map the address on a node, yes. In the real world, we should of course just add that little but of redundancy because most data consumers and even our database are not that 'spacial aware'. +1, spatial calculations on the fly are often too expensive, so preprocessing would be needed I tried to find out what an address really points to here in Germany. I wasn't successful. You get a house number for a parcel of land, even without a house on it, but only if it is already connected to a street. wrong question (in Germany) because this is not regulated on a national level. Anyway, from the building law it seems clear that the site must be connected to a street because otherwise you won't be able to build something there. When you build a house you definitely get one. Or the house inherits the number from the parcel. But you can get more than one number if you build multiple houses. (Or you can build additional houses without a number.) You can also get more numbers if you have multiple entrances to a building. But it is no problem for several flats in the same building to share the same number too. I couldn't find out on who's discretion this happens. on the discretion of you local authorities (you will get the numbers necessary...). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Markus Lindholm markus.lindh...@gmail.com: In my book addresses are features in their own right and should not be mixed in the same element as amenities or shops. The first problem would be that it would make it impossible to render addresses and POIs at the same time. this depends entirely on your rendering rules. The second problem would be that there would be multiple instances of the same address. why is this a problem? The address would be the sum of all these occurencies. If there really is a need to bind address and POI together then create a relation for that. -1, this would be breaking a fly on the wheel (or shooting with cannons on sparrows as we say in Germany). Really no need for relations here. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
On Tue, Dec 4, 2012 at 12:24 PM, Ronnie Soak chaoschaos0...@googlemail.com wrote: Are you against changing things in general ... ? Not if the intent is clearly to deprecate an existing tag. I'm against liars writing in the wiki that they won't change any existing tags until their proposal is accepted. I agree that changing or deprecating existing tags is very hard in OSM, especially when the new tag is not a real improvement or reasoning behind. For instance, the highway=gate replaced by barrier=* or the highway=ford replaced by highway=* + ford=yes have been well accepted where highway=bus_stop by public_transport=platform is not. Trying to deprecate a tag is not a minor issue. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On 4 December 2012 13:23, Martin Koppenhoefer dieterdre...@gmail.comwrote: 2012/12/4 Markus Lindholm markus.lindh...@gmail.com: In my book addresses are features in their own right and should not be mixed in the same element as amenities or shops. The first problem would be that it would make it impossible to render addresses and POIs at the same time. this depends entirely on your rendering rules. How would you devise a rendering rule that makes an intelligible map with two icons mapped on top of each other on the same spot? The second problem would be that there would be multiple instances of the same address. why is this a problem? The address would be the sum of all these occurencies. If you want to calculate a route to or from an address it is preferable that there's just one instance. If there really is a need to bind address and POI together then create a relation for that. -1, this would be breaking a fly on the wheel (or shooting with cannons on sparrows as we say in Germany). Really no need for relations here. I'm not saying it has to be done at all instances, just if you really adding some information to the map. Also you need a relation to tell what kind of relationship there is between the address and the POI. E.g. a restaurant might have one address at which it receives customers, an other where it accepts deliveries and a third for staff entrance and a forth to receive snail mail. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Before we use some strong words lets take a look at the issue: according to taginfo maxspeed:wet is used 602 times. You may subtract one or two hundred as I added them. So we are talking about a tag that's currently used less than 500 times and without a known (at least I dont know one) application. As such a speed limit is quite common people either didn't care enough to tag it or maxspeed:wet was just a try. Also please don't forget that maxspeed:wet is up to this second completely undocumented. You (Pieren) are right if you say, that all things should be put on the table before voting. Put I also understand Ole, because if he would have written that maxspeed:wet should be deprecated I bet that a few people would have objected - people who have never used maxspeed:wet before or even heard about it ;-) As I already wrote: a significant number of maxspeed:wet are from me. So if this tag will be deprecated I have some additional work to do and retag them. But that's life: things change. Sometimes even facts change. regards, Martin 2012/12/4 Pieren pier...@gmail.com: On Tue, Dec 4, 2012 at 12:24 PM, Ronnie Soak chaoschaos0...@googlemail.com wrote: Are you against changing things in general ... ? Not if the intent is clearly to deprecate an existing tag. I'm against liars writing in the wiki that they won't change any existing tags until their proposal is accepted. I agree that changing or deprecating existing tags is very hard in OSM, especially when the new tag is not a real improvement or reasoning behind. For instance, the highway=gate replaced by barrier=* or the highway=ford replaced by highway=* + ford=yes have been well accepted where highway=bus_stop by public_transport=platform is not. Trying to deprecate a tag is not a minor issue. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
2012/12/4 Martin Vonwald imagic@gmail.com: Before we use some strong words lets take a look at the issue: according to taginfo maxspeed:wet is used 602 times. You may subtract one or two hundred as I added them. So we are talking about a tag that's currently used less than 500 times and without a known (at least I dont know one) application. As such a speed limit is quite common people either didn't care enough to tag it or maxspeed:wet was just a try. I am not sure if this is really a common maxspeed condition, but I think that 602 of this particular feature is not very few. But neither too much to ever change it ;-) Also please don't forget that maxspeed:wet is up to this second completely undocumented. it is documented, you get lots of hits in the wiki when searching for it, e.g. here: http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags http://wiki.openstreetmap.org/wiki/Proposed_features/Modifiers_for_access_tags You (Pieren) are right if you say, that all things should be put on the table before voting. I don't think that a vote in a certain direction does imply that you can never have a different opinion on the same topic in the future. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
On 04.12.2012 13:31, Pieren wrote: On Tue, Dec 4, 2012 at 12:24 PM, Ronnie Soak chaoschaos0...@googlemail.com wrote: Are you against changing things in general ... ? Not if the intent is clearly to deprecate an existing tag. I'm against liars writing in the wiki that they won't change any existing tags until their proposal is accepted. The intention of mentioning that a tag is not directly deprecated by a proposal is to avoid that people's votes will be used as the reason for deprecation. So we cannot say people have approved conditional restrictions, so it's already decided that maxspeed:wet is deprecated. But it is not a guarantee that the tag will never be deprecated. It just means that this is a _separate_ decision, i.e. we might decide to approve the proposal, but keep using the other tag nevertheless. However, in this case I think deprecation would be a sensible choice. Even as the author of Conditions for access tags, which iirc was the first proposal to document maxspeed:wet along with other such tags in 2009, deprecation would be fine with me. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
2012/12/4 Martin Koppenhoefer dieterdre...@gmail.com: Also please don't forget that maxspeed:wet is up to this second completely undocumented. it is documented, you get lots of hits in the wiki when searching for it, e.g. here: http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags http://wiki.openstreetmap.org/wiki/Proposed_features/Modifiers_for_access_tags It is mentioned in a few proposals, but it is in no way properly documented ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
2012/12/4 Markus Lindholm markus.lindh...@gmail.com: it would make it impossible to render addresses and POIs at the same time. this depends entirely on your rendering rules. How would you devise a rendering rule that makes an intelligible map with two icons mapped on top of each other on the same spot? why should the address be an icon? The second problem would be that there would be multiple instances of the same address. why is this a problem? The address would be the sum of all these occurencies. If you want to calculate a route to or from an address it is preferable that there's just one instance. you could calculate the centre of all equal address-points, or just take the first, it wouldn't make any practical difference. Anyway: it is preferable not to use this approach, I agree that tagging a polygon is the better way if you know the extension of an address. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Quiet often if such a change is made (does not deprecate - recommend to stop using) it is by someone other than the original proposal author. Irrespective of this the proposal procedure is a RFC - Request For Change - process. What it does is to say hey guys, I think we should change this, if you agree vote for it and update any systems you have that may be effected. In this regard, I was pleased to see a proposal specifically for changing tag recommendations: http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Restrictions based on the weight of a trailer
Hi Martin, Am Dienstag, 4. Dezember 2012, 09:53:03 schrieb Martin Vonwald: I'm looking for a possibility to tag the following traffic sign: http://vonwald.info/osm/images/dscn5532.jpg It forbids from 05:00 to 22:00 overtaking for HGV with a weight of more than 7.5t and also for vehicles with a trailer, when the trailer weights more than 750kg. So far I have: overtaking:hgv:conditional=no @ (05:00-22:00 AND weight7.5 ) overtaking:trailer:conditional=no @ My problem is I don't know how to tag the weight of the trailer. Do we have a tag for this? not that I'm aware of. Maybe add something like trailerweight / trailergrossweight to conditional restrictions? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Restrictions based on the weight of a trailer
How about: overtaking:trailer:conditional=no @ (05:00-22:00 AND weight0.75 ) The access wiki page lists trailer=* (needs to be towed by another vehicle which has its own restrictions), which suggests that trailer should be seen as a separate identity, thus weight applies to the trailer only. Had the weight been the combination of vehicle plus trailer then we may have needed to come up with something to describe this. One possibility would be to borrow from [1], however this is a weight rating (set by the manufacturer), rather than an actual weight. Rob http://en.wikipedia.org/wiki/Gross_combined_weight_rating ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On 4 December 2012 17:44, Martin Koppenhoefer dieterdre...@gmail.comwrote: 2012/12/4 Markus Lindholm markus.lindh...@gmail.com: it would make it impossible to render addresses and POIs at the same time. this depends entirely on your rendering rules. How would you devise a rendering rule that makes an intelligible map with two icons mapped on top of each other on the same spot? why should the address be an icon? I include numerical digits in the concept of an icon. So to reiterate, your scheme makes it impossible to render addresses and POIs at the same time. The second problem would be that there would be multiple instances of the same address. why is this a problem? The address would be the sum of all these occurencies. If you want to calculate a route to or from an address it is preferable that there's just one instance. you could calculate the centre of all equal address-points, or just take the first, it wouldn't make any practical difference. If in the real world there's one 10 Main Street, then in the OSM database there also should be just one instance, IMHO. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On 04.12.2012 13:23, Martin Koppenhoefer wrote: 2012/12/4 Markus Lindholm markus.lindh...@gmail.com: If there really is a need to bind address and POI together then create a relation for that. -1, this would be breaking a fly on the wheel (or shooting with cannons on sparrows as we say in Germany). Really no need for relations here. It may not be strictly necessary, but it is still an option to consider. Representing addresses as a relation lets you express: * ... multiple objects that have the same address * ... objects that have multiple addresses * ... a mixture of both. This is not easily achieved with other representations. addr tags on individual objects do not allow multiple addresses. Overlapping polygons may work until you start thinking about features on different levels, but are pretty awkward as they require multiple overlapping polygons - or a multipolygon relation for each address, but then you are still using relations, you've just changed the type. I'm not sure which solution I personally prefer yet, but I wouldn't dismiss relations entirely. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
On 12/03/2012 04:32 PM, Christopher Baines wrote: I can see the food issue is becoming a recurring theme, and this is detracting from the main reason I put forward this proposal. I have now removed the food references from the proposal, such that now, the subjects of the relation would be schools and medical facilities, whose catchment areas are better defined, and of more use to more people. I can see how this would work for government-run schools, since the students living within a certain area are assigned to go to that school. I don't really see how it would work with medical facilities, since (at least in the USA) people aren't told because you live in this district, you must go to this particular hospital. Plus, a lot of larger hospitals specialize in certain types of medical care, so which hospital you go to depends on what medical condition is being treated. In the case of certain rare medical conditions, this may mean that they have patients coming from hundreds of miles away, and it would not seem practical to include a catchment area that large. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Am 04.12.2012 22:27, schrieb Markus Lindholm: On 4 December 2012 17:44, Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com wrote: 2012/12/4 Markus Lindholm markus.lindh...@gmail.com mailto:markus.lindh...@gmail.com: it would make it impossible to render addresses and POIs at the same time. this depends entirely on your rendering rules. How would you devise a rendering rule that makes an intelligible map with two icons mapped on top of each other on the same spot? why should the address be an icon? I include numerical digits in the concept of an icon. So to reiterate, your scheme makes it impossible to render addresses and POIs at the same time. Why? Yes, there are two conflicting information packets on the same spot, one is the address and one is the POI that could be rendered e.g. as a shop. But it's up to the rendering rules how to deal with that. Using a distinct address node currently leads to arbitrary random decisions which element to draw on the map due to space collision detection. Having both in one icon could (but is not currently) be used to define rules about how to draw a shop that has an address - e.g. by slightly moving the house number to the bottom of the icon, or by rendering the housenumber on top of the icon willingly (might depend on the icon). I don't see why that's more a problem in one node than in different ones - except that the current rendering rules don't fit here. In that your argumentation sounds much like a tagging-for-the-renderer-argumentation. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
On 5 December 2012 05:56, Peter Wendorff wendo...@uni-paderborn.de wrote: I don't see why that's more a problem in one node than in different ones - except that the current rendering rules don't fit here. In that your argumentation sounds much like a tagging-for-the-renderer-argumentation. I just pointed out two practical problems with overloading addresses upon POIs. My main argument is that I see addresses as a separate map feature in their own right. An further more as there can be a M-N relationship between addresses and POIs I think it's a bad idea to overload them on a single element. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
