Re: [Tagging] public_transport=platform rendering on osm-carto
On Fri, 2018-06-22 at 08:05 +, marc marc wrote: > Le 22. 06. 18 à 01:26, Yves a écrit : > > Why adding 'platform' where there's no physical platform? > > public_transport=platform describe where passagers wait > for a public transport. > if there is no dedicated area, use a node outside the road/rail > near the bus stop or near the railroad stop I believe this is one of the flaws of PTv2 - The disconnect between tagging and reality. Probably the majority of the bus stops out there are without a platform of any kind. There is a pole, a shelter or a semaphore of some kind, but you couldn't find anything that anyone would point at and say 'That's the platform' /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] public_transport=platform rendering on osm-carto
On Tue, 2018-06-19 at 15:13 +, marc marc wrote: > Le 19. 06. 18 à 16:30, Daniel Koć a écrit : > > I realized that highway=platform is not only marked on wiki as much > > less > > popular, but is also really 10 times less popular in the database. > > and for 93 906 highway=platform, 84 031 already have > public_transport=platform > https://taginfo.openstreetmap.org/tags/highway=platform#combinations > > this is a subject where it is very difficult to progress, > so I advise to do this in 2 steps: > check and add missing public_transport=plateform on highway=platform What's the point of adding an additional tag that basically conveys the same information that's already tagged? "To conform with PTv2" is not a valid answer in my opinion. It should be clear by now that there's a considerable part of the community that don't consider PTv2 to be a solution to public transport tagging /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] housenumber on node and area
On 27 May 2015 at 09:48, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier j...@liotier.org: Also, the address must be unique why? Otherwise they make bad routing targets /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] housenumber on node and area
On 27 May 2015 at 10:48, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-05-27 10:38 GMT+02:00 Markus Lindholm markus.lindh...@gmail.com: On 27 May 2015 at 09:48, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier j...@liotier.org: Also, the address must be unique why? Otherwise they make bad routing targets Maybe for ideal routing, an address is sometimes not sufficient? What if your satnav asked you after you entered the address: do you want to a) get to the main entrance b) get to the petrol station at this address? c) choose another target from a selection at this address? or something like this. Ideally the routing application shouldn't need to ask for clarification once a human asked for a route to a specific address. Now that might not be possible for a number of reasons, e.g. - Ground truth is such that an address actually isn't unique - Incomplete data in the database, exact match was not found - Ambiguous data in the database, same address is distributed over multiple objects in the database Personally I consider the last case to be bad mapping practice. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)
On 18 March 2015 at 08:21, Frederik Ramm frede...@remote.org wrote: So please, don't go over board here by trying to force-involve every mapper in tag votes; they're simply not important enough, and they *should not be*. Don't try to make them important, lasting, or binding. +1 A thought, how difficult would it be to include in the wiki-page how many different mappers have actually used a specific tag. Perhaps via TagInfo. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On 15 March 2015 at 10:17, Andreas Goss andi...@t-online.de wrote: in this case the reception will refer to the company and not to the building. How? Have a look at the provides_feature relation http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature if it might work for you to create an explicit connection between the company and reception desk. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11 March 2015 at 23:52, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 11.03.2015 um 19:43 schrieb Markus Lindholm markus.lindh...@gmail.com: reference to the definition found in Wikipedia and that's also how I've used the tag. and if someone changes the Wikipedia page, the definition for our tag will change as well? How likely is that? Not that somebody edits the page but that the definition would change in a material way? For me a city block is a city block is a city block, but I'm probably biased because I live in a city where street signs have the name of the city block on them and some old city blocks even have Wikipedia pages. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11 March 2015 at 18:04, althio althio.fo...@gmail.com wrote: The trouble is there is no definition yet of city_block Not so. When I added it to osm wiki I also put there a reference to the definition found in Wikipedia and that's also how I've used the tag. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
On 11 March 2015 at 20:14, althio althio.fo...@gmail.com wrote: On Mar 11, 2015 7:44 PM, Markus Lindholm markus.lindh...@gmail.com wrote: On 11 March 2015 at 18:04, althio althio.fo...@gmail.com wrote: The trouble is there is no definition yet of city_block Not so. When I added it to osm wiki I also put there a reference to the definition found in Wikipedia and that's also how I've used the tag. I am sorry that I missed your page. I am referring to http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block Where is your page? I bit of confusion, I added it here http://wiki.openstreetmap.org/wiki/Map_Features#Populated_settlements.2C_urban and there I also added a link to the Wikipedia definition. Some other people added the the actual page http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block I assumed there was a link to Wikipedia from that page also, but now I realize that it is missing. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
On 9 February 2015 at 12:58, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-09 8:29 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: The road isn't between the tracks. you could understand this by looking at the width of the road. Doesn't seem to be an ideal solution to draw the objects in a way that differs from ground truth and trying to use tags to convey that they actually on top of each other. Having highway and railway tags on the same object might also lead to other problems: you won't always know which tag / attribute belongs to which entity, or in other words it will only work if all properties of the railway and the highway are the same, e.g. oneway, width, surface. Not really a problem as you could always qualify the tag if there's a risk of ambiguity. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
On 8 February 2015 at 19:57, Jo winfi...@gmail.com wrote: I don't like to reuse the same ways for both railway and highway. The shape of the railways follow smooth curves for obvious reasons, whereas cars can make 90 degree turns. I don't understand why that is a problem. If the road is such that the vehicles drive on top of the tracks, then the obvious solution is to have just one way with both highway and railway tags. At corners and otherwise where the track for the tram diverges from the road create a separate way for the tracks. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
On 8 February 2015 at 22:32, Jo winfi...@gmail.com wrote: is it one asphalt way with one track? Then I agree. Or is it one asphalt way with two tracks, one for each direction of the tram lines? Then I'd draw 3 ways, 2 for the tracks, and 1 for the highway. Fair enough, but that doesn't quite correspond to the truth on the ground. The road isn't between the tracks. In my opinion it's better to have two ways, one in each direction with highway and railway tags on both. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 18 January 2015 at 22:11, Dan S danstowell+...@gmail.com wrote: 2015-01-18 20:52 GMT+00:00 Markus Lindholm markus.lindh...@gmail.com: On 17 January 2015 at 22:16, Friedrich Volkmann b...@volki.at wrote: With the addrN schema, we need one object (a node tagged shop=* and addrN:*=*) for a shop. With the provides_feature relation we need one node for the shop, one node for each address, and one relation. And if there are two shops that both have the same address? Then your scheme breaks down as you would end up with a database with two distinct nodes but same address. Clearly a bad thing and against the principle of 'One feature - one element' http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element This criticism is mistaken. (The wiki page even gives a counterexample of More than one of something on the same site which is rather similar to two shops with the same address.) We have lots of examples in OSM of two distinct objects with the same address - it's quite common in real life, and if it is a problem then it's nothing to do with addrN, it would be a problem with a large portion of our addr data! I think that comes down to how addresses are viewed, either as a proper feature in their one right or as an attribute to some other feature. I think addresses are proper features, so a distinct address should be found only once in the database. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 16 January 2015 at 01:04, Friedrich Volkmann b...@volki.at wrote: We can discuss its pros and cons, but I think the main message is that multiple addresses are mapped differently all over the world. Every country has its local OSM community which concoct their own tagging rules. The result is database full of tags that are understood by the local mappers, maybe by local applications too, but not by mappers or applications from other countries. We really need some unifying tagging scheme suitable for all kinds of addresses worldwide. What we don't need is yet another special case mapping scheme like addrN Have you had the time to look at the existing relation of type=provides_feature http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature and how you can use it to associate multiple addresses to a building. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 15 January 2015 at 12:43, Janko Mihelić jan...@gmail.com wrote: 2015-01-15 12:23 GMT+01:00 Andrew Shadura and...@shadura.me: On 15 January 2015 at 03:02, johnw jo...@mac.com wrote: The proposal seems to be a good solution to this problem. This particular proposal seems to be a terrible solution to this problem. It requires changes to the software, and the tagging scheme is ugly as hell. At the same time, there's much simpler and better solution: placing address nodes inside the building polygon. This is already used, supported by any sort of software which can process regular OSM address tags, and it's not as ugly as addrN:. With addrN:*=* it's clear that the same place has two addresses. If there are two nodes, it seems like there are two places (Two entrances, two apartments, two rooms), each with it's own address. AddrN* is clearly superior in this aspect. For an absolute majority of cases it should be enough with address nodes that resides inside a building polygon. If their really is a need to explicitly associate multiple addresses to a single building then use the provides_feature relation. http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
On 5 December 2014 at 06:19, Hans De Kryger hans.dekryge...@gmail.com wrote: One reason we cant completely combine the gas station and convenience store tag is some gas stations have the convenience store run by separate companies. As is the case with a circle k down the street from me. The convenience store is a circle k but the gas station is a shell. It would be nice to have a separate tag that combined the gas and convenience store shop together. I just want to make clear i don't want to get rid of the existing tags i just want to add one. Hi Hans In OSM we have this principle of one feature - one element http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element In my world a gas station and a convenience store are two distinct features, so they should indeed exist as two elements also in the osm database. Also an address should be considered a feature in its own right so it should also be a distinct element. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
On 5 December 2014 at 10:57, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2014-12-05 10:50 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: Also an address should be considered a feature in its own right so it should also be a distinct element. an address can be seen as a feature on its own, but it can also be an attribute of another feature. If you do it that way, that is place the address tags on an other feature you will end up with a database that has the same feature multiple times, which is clearly not a good thing. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
On 5 December 2014 at 10:49, Martin Vonwald imagic@gmail.com wrote: No need to provide the address more than once: the address belongs to everything within the area tagged with amenity=fuel In general it is not sustainable to place address tags on area/building elements as there can be many addresses within such an element. You're not going to comma separate the different address values I hope. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
On 5 December 2014 at 14:15, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2014-12-05 12:40 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: In general it is not sustainable to place address tags on area/building elements as there can be many addresses within such an element. this is country dependent, But OSM is a global database, so at least in the part of the world that has the familiar street name plus house number scheme I don't see any reason for divergence. Even in countries with a strict rule of one building - one address, I wonder what they do with a single building that occupies a whole city block, facing four streets. Would it still only be allowed one address? Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
On 5 December 2014 at 17:51, Jack Burke burke...@gmail.com wrote: Lately I've been playing with using a multipolygon as a way to handle the too-many-address-entries problem. Join the building=roof and building=retail into a multipolygon, then apply the address data to that. (I do have to do this before applying the other tags to the areas-that-make-up-the-building bits, but that's easy.) Please have a look at http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature I think it addresses exactly your problem. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bitcoin: Distinction of purchase through website and cash register/Point of sale
No, that's a bad idea. I believe there's a clear consensus that payment:bitcoin=yes is not a proper tag for a shop that doesn't accept bitcoin at its physical location. /Markus On 14 August 2014 12:53, Anita Andersson cc0c...@gmx.com wrote: Since payment:bitcoin=yes is a de facto and used tag and since payment:website:bitcoin=yes is not, I would suggest a combined usage of payment:bitcoin=yes and payment:website:bitcoin=yes until the new tag is chosen by more mappers for their use cases. I'm considering using the combination for the moment so that backwards compatibility is maintained. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bitcoin: Distinction of purchase through website and cash register/Point of sale
On 12 August 2014 20:55, Anita Andersson cc0c...@gmx.com wrote: In Sweden we got an electronics chain called Webhallen who accept Bitcoin as payment through their website and allows the customer to pick up the goods they purchase at any of the business's store locations. It does to my knowledge not accept purchase of goods with Bitcoin through their cash registers or Points of sale. I would just tag each and all of those stores with payment:bitcoin=yes I think that OSM is about mapping the physical world out there, even including payment methods accepted at different brick and mortar shops. But if a shop doesn't accept a certain payment method at its physical location then I don't think it should be tagged that way even if they have a website where that payment method is valid. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bitcoin ATM (amenity=atm | currency:XBT=yes)
On 10 June 2014 12:51, Janko Mihelić jan...@gmail.com wrote: Maybe we could use a broader term that includes ATMs, like financial_kiosk or money_kiosk. I'm not saying we should deprecate amenity=atm, I'm saying amenity=financial_kiosk could be an umbrella term. To me those terms are too similar for it to make sense to have two tags. Better to use the established amenity=atm also for bitcoin atms and qualify it with currencies accepted and dispensed. A qualification that traditional atms also would benefit from having. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Religious Places that belongs to multiple Religion
On 13 January 2014 07:16, Nirab Pudasaini developer.ni...@gmail.com wrote: Pashupatinath is a major place of worship for Hindus. It is also a place of worship for Buddhists. The tag amenity:place_of_worship has a key religion:* but how can we add place of worship which are for multiple religions, as in case of Pashupatinath. Similarly Soyambhunath is major place of worship for Buddhists but also is a place of worship for Hindus. One solution that comes to mind is to tag it with religion=dharmic /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses features or attributes?
On 19 July 2013 18:42, Eugene Alvin Villar sea...@gmail.com wrote: Forking the discussion from Double and misfitting house numbers On Fri, Jul 19, 2013 at 5:13 PM, Pieren pier...@gmail.com wrote: Not for me. I think the address is a feature by ifself, not an attribute of other features (like 'name'). I want to know what do people think about addresses. 1. Are addresses features as Pieren suggests? Thus addresses should be mapped separately or at least tagged singularly on the primary object that represents the address. 2. Or are addresses attributes (like names) of POIs, buildings, and the like? In which case, it would be OK if many POIs are mapped with the same addr:housenumbers. In my opinion addresses are independent map features in their own right. Please have a look at this proposal http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature on how one can associate the same address node with multiple POIs. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 8 April 2013 17:51, Dave Sutter sut...@intransix.com wrote: I like the idea of increasing the level of detail of the streets, and I agree that this would best be done by separating the routing network from the visual presentation. I think this can, however, be done in the existing data model, which is very flexible. Further, we wouldn't need to disrupt the existing data or the renderers since the existing data is the routing network. We would just be adding presentation data, which could be used or ignored. I agree. There seems to be an inherit conflict between routing and rendering because the same objects are used for both. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 7 April 2013 20:37, Martin Atkins m...@degeneration.co.uk wrote: How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? I'd say more detailed mapping. Looking at the picture I think it's obvious that Duboce Avenue should be mapped as two separate highways, placed on each side of the railways. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 14 December 2012 18:41, Erik Johansson erjo...@gmail.com wrote: On Sun, Dec 9, 2012 at 2:17 PM, Markus Lindholm markus.lindh...@gmail.com wrote: Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature What purpose does the role=entrance have when the node/way is going to be tagged building=entrance or entrance=main anyways? You mean that the role description could be left empty because it could always be deduced from tags on the member? I guess it could be possible, but I think it is much much better to have an explicit role descriptions, foremost for the benefit of the next mapper who comes along and wants to improve and edit the relation. So that he can clearly see what the intention is with the different members. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 7 December 2012 10:27, Pieren pier...@gmail.com wrote: On Fri, Dec 7, 2012 at 8:33 AM, Markus Lindholm markus.lindh...@gmail.com wrote: Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 Your relation type name provides_feature is too vague and could be used for all relations... Do you have a alternative suggestion? It's on purpose that I left the name of the relation a bit vague, so that one could expand it later with other roles besides the two (address and entrance) that I came now up with. Anyway, most of the mappers will prefer to create 1 node with duplicated address instead of creating 3 nodes and your relation. Please, think about contributors first. All ideas making data consumers life easier but mappers life much more complicated are failing. Sure, this is not basic level mapping but it builds on existing objects. And as people do more and more micro-mapping this would be a suggestion for how to do it. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 7 December 2012 11:05, Henning Scholland o...@aighes.de wrote: Am 06.12.2012 16:39, schrieb Markus Lindholm: Comments? Hi Markus, I think it's useful to have such a relation. But I would also include building-polygon, like: building entrance target address So the semantics of the building role would be that the target/POI is within the specified building? I guess there could be zero or one member with that role? But a bit redundant information as the POI should be placed within the building polygon. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] New relation type=provides_feature
Few days ago there was a discussion on this list with the subject Door to door routing to buildings with multiple occupants. My thoughts after the discussion was that with increasing micro-mapping we need a relation to tie different objects together. So I thought I would make a proposal for such a relation. Tags: type=provides_feature Members roles: target address entrance There has to be exactly one member with the role target, that would be the POI. There could be multiple members with the other roles. Currently I listed address and entrance as possible member roles, but the list could be open-ended. Comments? /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 6 December 2012 23:10, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/12/6 Markus Lindholm markus.lindh...@gmail.com: Tags: type=provides_feature Members roles: target address entrance Comments? do you know the site relation? It might provide what you are after. Yes, I looked at the site relation, but it has completely different kind of semantics. Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 /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 5 December 2012 10:19, Martin Koppenhoefer dieterdre...@gmail.comwrote: 2012/12/5 Markus Lindholm markus.lindh...@gmail.com: 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. +1, I agree with that, but isn't the logical consequence to tag them on polygons and not on nodes? I don't see that. Polygons are more laborious to create than a node and don't provide for a M-N relationships between addresses and POIs. /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 5 December 2012 14:23, Martin Koppenhoefer dieterdre...@gmail.comwrote: 2012/12/5 Markus Lindholm markus.lindh...@gmail.com: 2012/12/5 Markus Lindholm markus.lindh...@gmail.com: 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. +1, I agree with that, but isn't the logical consequence to tag them on polygons and not on nodes? I don't see that. Polygons are more laborious to create than a node and don't provide for a M-N relationships between addresses and POIs. So your conclusion is to map addresses as nodes because it is less work than a polygon (of which you might already have a preliminary version: the building outline), and than you suggest to create relations between this address-node and every POI with this address? It all depends on the level of ambition. It should be easy and quick to do the most basic mapping. Complex mapping should preferably use the artifacts from basic level as building blocks. The following are perhaps the logical steps in mapping addresses from simple to complex micro-mapping. - One building - one address. The address can be placed directly on the building polygon if one doesn't care to create a separate node inside the building. - As previous step but with knowledge about where the entrance is. Place a node on the building outline with address and entrance tags - Many addresses on the building, just add nodes - Add POIs that you care about - If you think it's important to bind a POI to an address then create a relation for it. Unique benefits with relations: - Possible to handle M-N relationships - Possible to convey what kind of relationship it is between POI and address, if it is a entrance for customers or customers in wheelchair or staff or deliveries or other. /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 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
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] 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 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
Re: [Tagging] How to tag: Legally separated ways
On 15 October 2012 20:08, Colin Smale colin.sm...@xs4all.nl wrote: I don't understand why emergency vehicles are so important in this discussion. In the first place they have wide-ranging exemptions from traffic rules, which (let's be honest) we are never going to tag in OSM. Secondly they are never going to be relying on OSM data (or indeed any normal sat-nav) for lane-precise routing. They are trained to use their eyes and brains to make split-second decisions on what is safe and an acceptable risk under the circumstances of that moment. Thirdly, they will be about 0.01% of the potential users of OSM data - why should we compromise service to the vast majority of real users for the hypothetical benefit of the very few. To be able to do proper routing for emergency vehicles perhaps it would be a good idea to introduce something like landuse=highway that would denote an area suitable for motor vehicles and that is free of physical obstacles. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
On 15 October 2012 10:56, Martin Vonwald imagic@gmail.com wrote: Hi! Some kind of short how-would-you-tag-this-survey. Have a look at part five of this motorway: http://wiki.openstreetmap.org/wiki/File:Lanes_Example_2.png Only part 5 is relevant. Assume there is no physical separation just a double line between the upper and lower two lanes. How would you tag this: a) One way with lanes=4 b) Two separate ways with lanes=2 each c) Tell me! The answer is b. But as I'm sure you've noticed there's some divided opinion about this. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 25 August 2012 01:25, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/8/20 Markus Lindholm markus.lindh...@gmail.com: I've been mostly mapping in large cities, hardly anything in the countryside. So I can only say that I've found it purposeful in the city to map with two highways when legally separated. purposeful in this case translates to mapping for the router *1 in OSM-speak. We're not supposed to map for the renderer nor the router. Exactly for whom are we to map? There is a convention in OSM that two highways represent two carriageways, so when a single carriageway with a legal divider is mapped like this, it is simply wrong according to our conventions. Sounds like you're the official spokesperson for OSM, are you? The convention you're referring to simply states (physically) Divided highways should be drawn as separate ways. It doesn't say anything about legally divided highways, that is left out. Currently mappers treat legally divided highways in different ways. I'm definitely not the only one to map them as two ways. Also, no one has offered any other solution to the routing issue. The divider tag has been proposed, but I think it has been demonstrated not to work, as routing decision are made on the node and not on the line. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 20 August 2012 10:55, Gregory Williams greg...@gregorywilliams.me.uk wrote: -Original Message- From: Markus Lindholm [mailto:markus.lindh...@gmail.com] Sent: 19 August 2012 19:26 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Carriageway divider On 19 August 2012 18:23, Tobias Knerr o...@tobias-knerr.de wrote: On 19.08.2012 15:09, Markus Lindholm wrote: On 19 August 2012 14:49, Fabrizio Carrai fabrizio.car...@gmail.com wrote: This could be a solution but it is against the reality: this kind of road are indeed a single entity. The legal division, i.e. the solid_line is just an attribute. There's a multitude of cases where a single entity is represented by multiple objects in the database, e.g. when the road changes speed limit it has to be split into two highway objects. The same with bus routes, to accommodate then the road was to be split into many parts. A major difference is that it is comparatively easy to re-assemble a way that has been split (because they have common nodes). It's not so easy with two parallel ways that somehow belong together - the connection could only be established by rather complex heuristics based on proximity among other things. In practice, it would simply result in gaps or overlaps appearing randomly depending how parallel the mapper has actually drawn the ways, and on the width assumed (or tagged) for the ways. For which purpose would the two highways be reassembled? Split highways may be reassembled when you're not interested in the attributes that do change between them. For example when you want to reassemble the portions of the same road with the same class and name together but aren't interested in the fact that the speed limit changes partway down, the lighting changes, the surface changes, or that a small portion of it has a cycle or bus route which crosses it for a few tens of metres. If building a routing graph from the data you'd want to keep the graph as simple as possible by ignoring the tags not relevant to your routing and reassembling the adjacent otherwise identical segments. Yes, I understand why one would reassemble highway segments on a route that only differ on the maxspeed tag or other such minor issue. But why would one want to reassemble two highways going in opposite direction and from which there is no direct legal route to the other? /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 20 August 2012 09:39, Elena ``of Valhalla'' elena.valha...@gmail.com wrote: On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote: In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This doesn't correspond to reality: I believe that an emergency vehicle can cross a solid line, while of course they would have problems with a physically separated road. I consider legal restrictions to be part of reality. Also consider that a physical separation might be nothing more than a 20cm high curb that could be as easy to cross for an emergency vehicle as a painted line. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 20 August 2012 12:57, Markus Lindholm markus.lindh...@gmail.com wrote: On 20 August 2012 09:39, Elena ``of Valhalla'' elena.valha...@gmail.com wrote: On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote: In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This doesn't correspond to reality: I believe that an emergency vehicle can cross a solid line, while of course they would have problems with a physically separated road. I consider legal restrictions to be part of reality. Also consider that a physical separation might be nothing more than a 20cm high curb that could be as easy to cross for an emergency vehicle as a painted line. One other aspect: it would not be possible to create correct routes from an address that's in a middle of a block where the the street has lanes in both direction but that are legally separated. Now if the shortest route would be to turn left (in a country with right hand traffic) but the legal route would require to start the trip by going right, there's no way to express that without having to separate highways, one in each direction. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 20 August 2012 13:25, Colin Smale colin.sm...@xs4all.nl wrote: Isn't that what turn restrictions are for? No. Turn restrictions restrict from which highway object to which highway object one can traverse, they can't tell whether you're allowed to make a left or right turn at the start of your route. /Markus Colin On 20/08/2012 13:10, Markus Lindholm wrote: On 20 August 2012 12:57, Markus Lindholm markus.lindh...@gmail.com wrote: On 20 August 2012 09:39, Elena ``of Valhalla'' elena.valha...@gmail.com wrote: On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote: In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This doesn't correspond to reality: I believe that an emergency vehicle can cross a solid line, while of course they would have problems with a physically separated road. I consider legal restrictions to be part of reality. Also consider that a physical separation might be nothing more than a 20cm high curb that could be as easy to cross for an emergency vehicle as a painted line. One other aspect: it would not be possible to create correct routes from an address that's in a middle of a block where the the street has lanes in both direction but that are legally separated. Now if the shortest route would be to turn left (in a country with right hand traffic) but the legal route would require to start the trip by going right, there's no way to express that without having to separate highways, one in each direction. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ 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] Carriageway divider
On 20 August 2012 14:06, Frederik Ramm frede...@remote.org wrote: Hi, On 08/20/2012 12:57 PM, Markus Lindholm wrote: This doesn't correspond to reality: I believe that an emergency vehicle can cross a solid line, while of course they would have problems with a physically separated road. I consider legal restrictions to be part of reality. Yes, but we must make a difference between must not pass and cannot pass. It has already been pointed out that the legal restrictions may not be the same for everyone (emergency services etc.), but even the common motorist or cyclist might choose to ignore legal restrictions - either for banal reason or perhaps because they have an emergency as well - and therefore it is important to distinguish between the physical and the legal side. As I said earlier physical separation doesn't necessary mean cannot pass, because physical obstacles come in all kind of different shape and form. Where I live there are plenty of cases of physical separation that any ordinary SUV could easily cross. And then there's the kind that would require a tank. I think that it would be a more pressing objective to be able to provide a legal route from A to B than to cater for all the shortcuts that are possible but not legal. Of course the former doesn't exclude the latter and one could conceive of new schemes to indicate where it's possible to drive but not legal. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 20 August 2012 16:50, Janko Mihelić jan...@gmail.com wrote: 2012/8/20 Markus Lindholm markus.lindh...@gmail.com Yes, I understand why one would reassemble highway segments on a route that only differ on the maxspeed tag or other such minor issue. But why would one want to reassemble two highways going in opposite direction and from which there is no direct legal route to the other? What about the roads in the countryside? Would you divide roads into lanes if there is a full line, like in the following picture: http://i.imgur.com/p5Oto.png I've been mostly mapping in large cities, hardly anything in the countryside. So I can only say that I've found it purposeful in the city to map with two highways when legally separated. It might well be that that convention doesn't suit well in the countryside, I don't know. So then the convention might differ between city and countryside, like conventions differ between different countries. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 19 August 2012 11:44, Fabrizio Carrai fabrizio.car...@gmail.com wrote: After a short discussion on the italian talk, I would move the discussion in this list. After some tests with OSRM, I missed the availability of a tag to mark the continuos (or discontinued) line that divide the lanes in several single carriageway. In my opinion this is an important indication to the routers to avoid illegal turns across a road. A typical useful application case is a road with many side road [2]. Actually the problem is solved with several turn restriction relations, one for each side way. Tagging the main way with divider=solid_line the problem would have been solved in a easier way, also reflecting the real status of the road. Indeed a Divider=solid_line proposal [3] was already presented . I'm would revamp such proposal. What is your opinion ? Is there any router developer here ? In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 19 August 2012 14:49, Fabrizio Carrai fabrizio.car...@gmail.com wrote: This could be a solution but it is against the reality: this kind of road are indeed a single entity. The legal division, i.e. the solid_line is just an attribute. There's a multitude of cases where a single entity is represented by multiple objects in the database, e.g. when the road changes speed limit it has to be split into two highway objects. The same with bus routes, to accommodate then the road was to be split into many parts. Indeed, the current mapping rules [1] indicate that separate ways have to be traced when there is a physical division. That guideline says that a physical separation requires two highway objects, it doesn't say that one shouldn't do the same with legal separation. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 19 August 2012 15:04, Tobias Knerr o...@tobias-knerr.de wrote: On 19.08.2012 14:09, Markus Lindholm wrote: On 19 August 2012 11:44, Fabrizio Carrai fabrizio.car...@gmail.com wrote: Indeed a Divider=solid_line proposal [3] was already presented . I'm would revamp such proposal. What is your opinion ? Is there any router developer here ? In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This would make it impossible to treat solid lines and physical separation differently in rendering, so imo it is not an acceptable solution. No it doesn't, if the physical object that separates the lanes is of interest then create such an object and tag it accordingly. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 19 August 2012 18:23, Tobias Knerr o...@tobias-knerr.de wrote: On 19.08.2012 15:09, Markus Lindholm wrote: On 19 August 2012 14:49, Fabrizio Carrai fabrizio.car...@gmail.com wrote: This could be a solution but it is against the reality: this kind of road are indeed a single entity. The legal division, i.e. the solid_line is just an attribute. There's a multitude of cases where a single entity is represented by multiple objects in the database, e.g. when the road changes speed limit it has to be split into two highway objects. The same with bus routes, to accommodate then the road was to be split into many parts. A major difference is that it is comparatively easy to re-assemble a way that has been split (because they have common nodes). It's not so easy with two parallel ways that somehow belong together - the connection could only be established by rather complex heuristics based on proximity among other things. In practice, it would simply result in gaps or overlaps appearing randomly depending how parallel the mapper has actually drawn the ways, and on the width assumed (or tagged) for the ways. For which purpose would the two highways be reassembled? /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
On 19 August 2012 15:26, Philip Barnes p...@trigpoint.me.uk wrote: On Sun, 2012-08-19 at 15:04 +0200, Tobias Knerr wrote: On 19.08.2012 14:09, Markus Lindholm wrote: On 19 August 2012 11:44, Fabrizio Carrai fabrizio.car...@gmail.com wrote: Indeed a Divider=solid_line proposal [3] was already presented . I'm would revamp such proposal. What is your opinion ? Is there any router developer here ? In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This would make it impossible to treat solid lines and physical separation differently in rendering, so imo it is not an acceptable solution. +1 It would also not allow for conditions where the solid line only affects traffic in one direction. Of course if the two opposing lanes aren't mutually legally separated then they shouldn't be created as two highways. Also would imply a dual carriageway and therefore imply a higher speed limit where the National Speed Limit tag has been used. That I don't understand at all. You're not proposing a heuristic algorithm that tries to spot dual carriageways and then impose implied speed limits? Routers would still have the ascendancy to route U-turns around the end of the division. At the next crossing U-turns might be allowed or not and a turn restriction relation should be added if not. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
On 3 July 2012 15:03, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/7/3 Pieren pier...@gmail.com: On Tue, Jul 3, 2012 at 2:00 PM, Janko Mihelić jan...@gmail.com wrote: Well, the router could take the overtake tag into consideration, and make you turn around there. They don't do this yet, but probably will. I discover the overtake tag: http://wiki.openstreetmap.org/wiki/Key:overtaking but the wiki doesn't say explicitely that overtaking=no means no u-turn as well. Could we write this assertion ? -1 overtaking isn't used very much either (less than 2000 times), and as written above: a solid line is not only about overtaking and u-turns: you are never allowed to cross it in any case (besides you are an emergency vehicle in case of an emergency or similar, e.g. you are also not allowed to turn left). I think that the divider-proposal has a much better semantics compared to overtaking. Lets tag directly what we mean, not overtaking=no if we want to say no u-turn. In my opinion the most straight forward is to treat legal separation (i.e. solid line) the same way as physical separation, that is to have two ways, one in each direction. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
On 3 July 2012 15:20, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/7/3 Markus Lindholm markus.lindh...@gmail.com: In my opinion the most straight forward is to treat legal separation (i.e. solid line) the same way as physical separation, that is to have two ways, one in each direction. if you make no distinction at all this has the problem that you will get worse results for other use cases (pedestrians, emergency vehicles, bankrobbers, ...). IMHO it is important to be able to differentiate between not possible (physically) and not legal. You could associate the two ways with a relation (i.e. lane-mapping, e.g. area relation), but I feel that is would somehow be overkill. Why not a simple tag that says: there is a solid line between the two opposing lanes (- divider). Physical separation doesn't necessarily mean that it's impossible to cross, it might be no more than a 20cm high curb that an emergency vehicle or a SUV easily could cross. I still think it's more straight forward to map as two separate ways than to add tags to provide a logically consistent view about how to drive from A to B in a legal way. Bank robbers and emergency vehicle drivers make anyway their own decision on the spot. And about pedestrians, I add sidewalks around such street and tag the street with foot=no. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
On 3 July 2012 16:47, Eckhart Wörner ewoer...@kde.org wrote: Hi Markus, Am Dienstag, 3. Juli 2012, 15:38:57 schrieb Markus Lindholm: Physical separation doesn't necessarily mean that it's impossible to cross, it might be no more than a 20cm high curb that an emergency vehicle or a SUV easily could cross. I still think it's more straight forward to map as two separate ways than to add tags to provide a logically consistent view about how to drive from A to B in a legal way. Bank robbers and emergency vehicle drivers make anyway their own decision on the spot. And about pedestrians, I add sidewalks around such street and tag the street with foot=no. There is a reason why this is a bad idea: routing along linear features has to work under the assumption that routes are just paths in the data. By splitting ways, you're removing quite a lot of possible routes; e.g. try pedestrian routing to the house opposite to yours. Well, my house is by a residential street and there's no solid line in the middle :) Usually the solid line is there for an reason, like that there's lot of traffic. I wouldn't like it if a pedestrian routing engine asked me to cross a six lane heavily trafficked street just because there's no physical separation. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
On 3 July 2012 17:02, Janko Mihelić jan...@gmail.com wrote: 2012/7/3 Markus Lindholm markus.lindh...@gmail.com I still think it's more straight forward to map as two separate ways than to add tags to provide a logically consistent view about how to drive from A to B in a legal way. Bank robbers and emergency vehicle drivers make anyway their own decision on the spot. And about pedestrians, I add sidewalks around such street and tag the street with foot=no. Does this mean you separate the road when overtaking is not allowed, and put them together when it's allowed? How can this be better than tagging with overtake=no or divider=legal? I've mostly mapped in cities, where the issue of overtaking isn't that relevant, roads don't change from solid line to broken line just to allow overtaking /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] POI for Hotel
On 15 April 2012 11:33, Toby Murray toby.mur...@gmail.com wrote: On Sun, Apr 15, 2012 at 4:08 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: That's always useful, but it doesn't solve the issue of getting the data for a query like: give me all the hotels cheaper than 66 EUR for a double room with bathroom in this bounding box. I'm not sure why you would attempt such a query with nothing but OSM data. There are multiple websites that specialize in this type of thing and are far better at it than OSM will ever be because they have direct interaction with hotels to handle the volatility in prices, room availability and other considerations that are entirely outside of the scope of OSM. hotels.com, orbitz.com, kayak.com, priceline.com, travelocity.com, etc, etc There could certainly be interaction between these sites and OSM. But OSM is not a travel site and I would never use it as such. Somebody should start an OpenServicesDatabase-project, that would host information about hotels, restaurants, cafes, museums and parks with detailed description of amenities provided along with user reviews. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping as two ways or one, u-turns
On 3 March 2012 10:07, Vincent Pottier vpott...@gmail.com wrote: Le 03/03/2012 08:49, Erik Johansson a écrit : There is nothing separating this road yet it is mapped as two ways: http://osm.org/go/0bCzcBhNM--?m http://goo.gl/KLTpu (Streetview) IMHO, it's a mistake. This is done for routers. Imagine you want to go from the marker to number 117, as it is mapped today the router will know that you can't go back on the same street directly. How can this be mapped with out mapping this as two ways, as it's said in the Editing standards: http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways IMHO, there is a lack of a tag saying that the road can't be crossed, except at crossings e.g. tag:crossable=no. If it is forbiden to U-turn it at a cross, a restriction relation must tell it, or maybe a different tag if all crossings are concerned, e.g. tag:crossable=not_at_all. There was a proposal like that https://wiki.openstreetmap.org/wiki/Proposed_features/Divider that has been abandoned. Not sure of the reason. I think that having separate ways for legally separated opposing lanes is the best scheme currently to represent the truth on the ground. Disclosure: I'm the one who mapped Hornsgatan as it is today. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Key:designation)
On 1 March 2011 21:47, Richard Mann richard.mann.westoxf...@gmail.com wrote: You'all are welcome to: 1) Make another proposal 2) Vote yes or no to the proposal as it stands It's not appropriate to fine-tune the proposal during the voting stage - you either approve or oppose it as it stands. If there's an appropriate majority after 2 weeks, I'll move it to approved. Otherwise we'll just carry on waiting for a better idea (it might be a long wait). My proposal is simply to use an other key, and once a better name for the key is agreed upon to change the existing tags to use the new key /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Key:designation)
On 1 March 2011 20:04, Richard Fairhurst rich...@systemed.net wrote: Martin Koppenhoefer wrote: There is already 2 alternative ways to tag these (path and foot/cycle/bridleway), I feel we don't need a third one. Do try and keep up. This is not a third way of tagging. This is _additional_ information that can be used with either existing scheme. There is no other way of recording the formal legal status of a right-of-way. That's what this tag does. If this tag designation is about formal status in the UK shouldn't it be named something else, e.g. formal_designation_in_uk or something similar. The word designation can mean a lot of different things in different contexts so it sounds like poor idea to reserve it just for this. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Key:designation)
On 1 March 2011 20:51, Richard Fairhurst rich...@systemed.net wrote: Markus Lindholm wrote: If this tag designation is about formal status in the UK It isn't. It's about formal status, full stop. You could just as easily use it to record that a European waterway is UNECE Class Vb. Well, the wiki certainly says that it's about England Wales. But even if it were about formal designation worldwide, isn't there a risk with value collisions, e.g. designation=xyz might mean one thing in England but a slightly different thing in Australia. A data consumer would also have to take into consideration where an object is located before it can make a interpretation about the meaning of the tag. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Draft - Vegetarian/Vegan
On 14/02/2011, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/2/14 Tom Chance t...@acrewoods.net: Hello, Please read and comment on my draft proposal to improve our tagging of vegetarian and vegan food: http://wiki.openstreetmap.org/wiki/Proposed_features/Vegetarian I want to use something more sophisticated than cuisine=vegetarian for restaurants, cafes and shops. I am not an expert in this field, but maybe it would be better to do it the other way round: yes/strictly, i.e. vegetarian=yes implies available while vegetarian=strictly implies that no meat has ever been fried in their pans ;-) AFAIK there is quite a lot of differentiation in the vegetarian community (e.g. Ovo, lacto, ovo-lacto, veganism, raw veganism, fruitarianism, buddhist vegetarianism) if you are an expert in this field, maybe you could extend the proposal to take this into account? Aren't attributes like that more suitable to describe a person than a restaurant. I mean a person can follow a ovo-lacto diet, but find hard to think there would be a restaurant where every meal on the menu would be an ovo-lacto vegetarian meal. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging post-office in Sweden
On 28 August 2010 10:16, just.st...@lesve.org wrote: LeSve wrote, On 2010-08-28 09:46: How should Postoffice be tagged in Sweden. The Postoffices has disapperared and is instead a small part of another shop (or Petrol station etc). Should another node be created which said postoffice or should the shop-node have another key-value telling this. More explanation. This is not called post-office. They called it postombud (post office agent in English) I tag them as two different nodes. One node with amenity=post_office and another with e.g. shop=convenience. Not sure if the question have a definitive answer, but for me at least it makes more sense with two nodes. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] game:patrizer2:* tags
On 18 April 2010 11:15, Ed Avis e...@waniasset.com wrote: Did someone contact the person who added this 'patrizer2' stuff? I did. The response was that she was doing some experimentation and that I should mind my own business. I didn't pursue it any further as OSM is as laissez-faire as it is. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] game:patrizer2:* tags
Hi A question, what's the story behind the game:patrizer2:* tags? I just noticed that Stockholm got a bunch of these tags and I'm curious what they are? http://www.openstreetmap.org/browse/node/25929985 Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] game:patrizer2:* tags
On 6 April 2010 11:21, Tobias Knerr o...@tobias-knerr.de wrote: Markus Lindholm wrote: A question, what's the story behind the game:patrizer2:* tags? I just noticed that Stockholm got a bunch of these tags and I'm curious what they are? Patrizier 2 is a German trading simulation computer game. It was internationally released as Patrician II (and re-released together with an expansion as Patrician III: Rise of the Hanse[1]). The game has a historical setting and features cities that were influential during the Hanseatic period. In the game, cities produce trading goods with varying efficiency. For example, Stockholm produces a lot of iron ore (Eisenerz) and some fish. Apparently, this mapper decided to tag the production efficiencies to the cities' place nodes - which happens to be possible because the game uses real-world places. The data represented by the tags, though, has in-game relevance only. Tobias Knerr [1] http://en.wikipedia.org/wiki/Patrician_III:_Rise_of_the_Hanse Thanks for the info. My second question then --- is this kosher? Populating the OSM database with some game related info? Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
