Re: [Tagging] Proposal - RFC - man_made=lamp
Am 05/nov/2013 um 08:32 schrieb Manuel Hohmann mhohm...@physnet.uni-hamburg.de: Yes, indeed I was thinking about this (or rather light_fitting, which should be UK English), which would be the correct technical term. I finally used lamp for the following reasons: If I see this right, lamp technically seems to refer to the light emitting, usually changeable, component described here: http://en.m.wikipedia.org/wiki/Lamp_(electrical_component) (just the same as the German Lampe, which colloquially is also sometimes used for Leuchte, but actually shouldn't). I'd prefer to stick to correct terminology in order to avoid confusion (e.g. lamp:colour, it should be clear if this refers to the lamp or the fixture) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
On Tue, Nov 5, 2013 at 1:23 AM, Tod Fitch t...@fitchdesign.com wrote: I personally find the traffic_signal:direction tag to be clunky, but it is in the wiki for traffic signals where many/most mappers will find it. And traffic signals are a member of the same class as stop and yield signs in my mind: Things that control right of way at an intersection. It's more than clunky. It's simply failing when someone is reversing the way direction with its prefered editor... I will repeat here what I already said about traffic signals : I also don't like relations in general excepted when we have no alternative. Everybody shall be able to add a node saying here is a traffic light or here is a stop sign. But once you want it to be workable by software, it will need to be linked to its intersection. And for this, the best solution is the relation. It could be even added half-automatically (with some manual validation) when it's missing by searching the nearest intersection (could be a job for a QA tool). I guess something similar is done for speed traps. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal for soft play centres
It has occured to me that this seems to be more of something simliar to tourism=theme_park, yet smaller. I don't know if there is such a tag that is widespread or if it's better to use your own tag. I think it's not such a good idea to use leisure=playground + fee=yes, since it most certainly is not a playground, but sure playgrounds really do span a very big range from a sandbox to extremely large contraptions . I have now tagged two soft play centes with leisure=play_land which is a direct translation from Swedish. Feel free to adopt or change my tags. It would be interesting to tag place where kids can play, many museums/science centers have that as well. On Mon, Nov 4, 2013 at 2:30 PM, nounours kuessemondtaegl...@gmail.com wrote: Hi Dom, I don't know about voting ... But I read your interesting proposal. I completely agree that indoor-playgrounds should be mapped. In Switzerland, it seems that they are normally mapped as leisure=playground and indoor=yes, see example: http://www.openstreetmap.org/browse/node/1687169329 I personally think that keeping things together is better, so why not stay with playground? There are managed playgrounds, and there are indoor_play which are free. There are outdoor playgrounds with opening-hours So, why not use: Leisure=playground Indoor=yes|no Fee=yes|no Managed=yes|no Opening-hours=* Operatortype=public|private Operator=* etc. Maybe a template would help more than a new tag? Greetings, nounours Am 04.11.2013 um 14:07 schrieb Dominic Hosler: Hi everyone, It has been almost two weeks and the discussion seems to have died down. How long should it be left, before initiating a vote, and how long should a vote last on the proposal? This is the relevant wiki page: https://wiki.openstreetmap.org/wiki/Proposed_features/Indoor_play Thanks, Dom On 24 October 2013 14:23, Jonathan bigfatfro...@gmail.com wrote: That's definitely better but I would make the description more generic, such as An indoor area for children to play and then make the padded aspects, cafe etc sub tags that can be added. The indoor_play tag should be able to be used by those in other countries who have similar facilities but minus the padding or cafe. The tage of indoor_play needs to be the umbrella tag. Jonathan http://bigfatfrog67.me On 24/10/2013 12:13, Dominic Hosler wrote: Thanks, I feel a bit silly now, I didn't look hard enough. New page is at: https://wiki.openstreetmap.org/wiki/Proposed_features/Indoor_play for anyone wanting another look. Thanks, Dom On 24 October 2013 12:04, Matthijs Melissen i...@matthijsmelissen.nl wrote: Use the arrow down button on the upper right (next to the Search box) and choose 'Move'. -- Matthijs On 24 October 2013 12:59, Dominic Hosler dominichos...@gmail.com wrote: I have updated the page to indoor play, but I don't know how to actually change the title of the page? Do I need to just delete that one and create a new proposal called Indoor play? Putting a note in the discussion that it has been migrated from the previous soft play proposal? Thanks, Dom On 23 October 2013 20:51, Dominic Hosler dominichos...@gmail.com wrote: I agree we should move away from the trademarked title 'soft_play'. Perhaps if we keep the proposal and change the name of the tag to indoor_play, to include other types as well, as per brad's suggestion. We should also include sub tag qualifiers to specify if it's soft play and for what ages it's designed. I think it would be most appropriate to use indoor play considering its catch all nature and the fact that it is already used by a couple of websites. I will update the proposal and fill in the definition area, I must have just missed it. However, I won't update it till tomorrow because I only have my phone until then. Thanks, Dom Jonathan bigfatfro...@gmail.com wrote: I agree, we need to choose a term that is more generic, maybe leisure=childrens_adventure or kids_play or kids_amusement. There can always be a sub tag defining soft_play? Especially considering that a lot of softplay areas are now included among other internal children's play features? Softplay is just one bit. Jonathan http://bigfatfrog67.me On 23/10/2013 17:47, Brad Neuhauser wrote: Instead of soft play, what about indoor play (or indoor play area/centre)? 1) it seems to be used as a catch all sometimes, even in the UK (ie - http://www.timeout.com/london/events/indoor-play-centres-in-london or http://www.dayoutwiththekids.co.uk/things-to-do-family/Northampton/Indoor-Play-Areas) 2) it is broad enough to cover all of these sort of places, since some indoor play areas may only have some actual soft play equipment meant for younger kids/toddlers (or, if you are only meaning the actual areas that have the soft play equipment, then that might be different) 3) it might make more sense for those outside the UK who don't use
Re: [Tagging] give way and stop tag for ways
On Mon, Nov 4, 2013 at 11:30 PM, Balázs Barcsik 1. extend highway=give_way (and stop) to able to use on ways https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way And how to interpret the tag if the way is between two intersections ? Surely not a good solution. 2. define a new tag: priority_road=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key%3Apriority_road This is more country specific and will not solve many give_way cases where there is no priority road signed. 3. define new tag: priority=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key:priority A lot of new tags for only one feature, no ? 4. define new type - priority: link to my proposal: https://wiki.openstreetmap.org/wiki/Proposal:_relation:priority Only 15 relations are of type=priority in OSM ([1]). The type junction is even more popular (although mainly contributed by the same person). Pieren [1] http://taginfo.openstreetmap.org/relations/priority ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
My understanding is that a give_way node on a way should be placed such that it is closer to the relevant intersection than it is to any other intersection of that way. Thus, as long as you can work out (from this proximity) which intersection it relates to, you have all the information you need to handle it properly: it applies to traffic passing that node heading towards the relevant intersection. Steve On 04/11/2013 22:30, Balázs Barcsik wrote: Hi There! I would like to introduce give_way and stop alerts into navigation tools such as OSMAnd. For this approach a good tagging is needed. So when someone driving and arrives to an intersection then the app would show give way or stop depending on which road he/she is. (or nothing if the road is a priority one) Can you help me define this in a proper way? I think there are several options: 1. extend highway=give_way (and stop) to able to use on ways https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way 2. define a new tag: priority_road=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key%3Apriority_road 3. define new tag: priority=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key:priority 4. define new type - priority: link to my proposal: https://wiki.openstreetmap.org/wiki/Proposal:_relation:priority Thanks, Balazs ___ 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] give way and stop tag for ways
Think about oneway tag. http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing That is a property of a way. So as a routing app I just would like to examine this tag, and forget the relations restrictions: http://wiki.openstreetmap.org/wiki/Relation:restriction Because it is a redundancy - if the oneway tag used properly the routing app can determine whether you can turn right in an intersection or not. In other words - if someone missed defining the road signs at intersections (eg, restriction=no_left_turn) then this does not mean that you can turn left. So I would prefer to create such tags for priority cases - which can be assigned to ways Thanks, Balazs On Tue, Nov 5, 2013 at 11:59 AM, Steve Doerr doerr.step...@gmail.comwrote: My understanding is that a give_way node on a way should be placed such that it is closer to the relevant intersection than it is to any other intersection of that way. Thus, as long as you can work out (from this proximity) which intersection it relates to, you have all the information you need to handle it properly: it applies to traffic passing that node heading towards the relevant intersection. Steve On 04/11/2013 22:30, Balázs Barcsik wrote: Hi There! I would like to introduce give_way and stop alerts into navigation tools such as OSMAnd. For this approach a good tagging is needed. So when someone driving and arrives to an intersection then the app would show give way or stop depending on which road he/she is. (or nothing if the road is a priority one) Can you help me define this in a proper way? I think there are several options: 1. extend highway=give_way (and stop) to able to use on ways https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way 2. define a new tag: priority_road=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key%3Apriority_road 3. define new tag: priority=give_way (stop) link to existing tag https://wiki.openstreetmap.org/wiki/Key:priority 4. define new type - priority: link to my proposal: https://wiki.openstreetmap.org/wiki/Proposal:_relation:priority Thanks, Balazs ___ Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging ___ 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] give way and stop tag for ways
On Tue, 5 Nov 2013, Balázs Barcsik wrote: Think about oneway tag.http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing That is a property of a way. So as a routing app I just would like to examine this tag, and forget the relations restrictions: http://wiki.openstreetmap.org/wiki/Relation:restriction Because it is a redundancy - if the oneway tag used properly the routing app can determine whether you can turn right in an intersection or not. In other words - if someone missed defining the road signs at intersections (eg, restriction=no_left_turn) then this does not mean that you can turn left. So I would prefer to create such tags for priority cases - which can be assigned to ways No, you are simply wrong here. Oneway is a legal concept that really applies for the way and it is different from turning restrictions that applies to particular combination of traversing on the graph edges (ie., a relation). And you cannot ignore turning restrictions as it by no means guarantees that the way itself is oneway legally, just the turning is forbidden from the way you're coming from. -- i.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
Do you think that routing/navigation apps are using turn restrictions tags instead of oneway tag to create the route? I dont think so... On Tue, Nov 5, 2013 at 12:39 PM, Ilpo Järvinen ilpo.jarvi...@helsinki.fiwrote: On Tue, 5 Nov 2013, Balázs Barcsik wrote: Think about oneway tag.http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing That is a property of a way. So as a routing app I just would like to examine this tag, and forget the relations restrictions: http://wiki.openstreetmap.org/wiki/Relation:restriction Because it is a redundancy - if the oneway tag used properly the routing app can determine whether you can turn right in an intersection or not. In other words - if someone missed defining the road signs at intersections (eg, restriction=no_left_turn) then this does not mean that you can turn left. So I would prefer to create such tags for priority cases - which can be assigned to ways No, you are simply wrong here. Oneway is a legal concept that really applies for the way and it is different from turning restrictions that applies to particular combination of traversing on the graph edges (ie., a relation). And you cannot ignore turning restrictions as it by no means guarantees that the way itself is oneway legally, just the turning is forbidden from the way you're coming from. -- i. ___ 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] give way and stop tag for ways
On Tue, 5 Nov 2013, Balázs Barcsik wrote: Do you think that routing/navigation apps are using turn restrictions tags instead of oneway tag to create the route?I dont think so... It's still wrong even if everyone would be doing it. :-) And btw, I was only saying that in order to get it right, you cannot ignore the turn restrictions (not claiming that one should use them only instead of oneway or something along those lines). -- i.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
There are lots of cases where routing software uses turn restrictions, it would be next to useless if it relied on oneways alone. Phil (trigpoint) -- Sent from my Nokia N9 On 05/11/2013 13:09 Balázs Barcsik wrote: Do you think that routing/navigation apps are using turn restrictions tags instead of oneway tag to create the route? I dont think so... On Tue, Nov 5, 2013 at 12:39 PM, Ilpo Järvinen ilpo.jarvi...@helsinki.fi wrote: On Tue, 5 Nov 2013, Balázs Barcsik wrote: Think about oneway tag.http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing That is a property of a way. So as a routing app I just would like to examine this tag, and forget the relations restrictions: http://wiki.openstreetmap.org/wiki/Relation:restriction Because it is a redundancy - if the oneway tag used properly the routing app can determine whether you can turn right in an intersection or not. In other words - if someone missed defining the road signs at intersections (eg, restriction=no_left_turn) then this does not mean that you can turn left. So I would prefer to create such tags for priority cases - which can be assigned to ways No, you are simply wrong here. Oneway is a legal concept that really applies for the way and it is different from turning restrictions that applies to particular combination of traversing on the graph edges (ie., a relation). And you cannot ignore turning restrictions as it by no means guarantees that the way itself is oneway legally, just the turning is forbidden from the way you're coming from. -- i. ___ 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] give way and stop tag for ways
On Tue, Nov 5, 2013 at 2:09 PM, Balázs Barcsik balazs.barc...@gmail.com wrote: Do you think that routing/navigation apps are using turn restrictions tags instead of oneway tag to create the route? I dont think so... Back to your original post, you want to introduce alerts into navigation tools. But you seem to have some gaps on this subject. Of course, routing engines have to handle both, turn restriction relations and oneways tags on ways. But, as already said, the oneway restriction applies to the whole way, for all vehicles arriving there, even from private properties. Where stops or giveway are just prioritizing the access to an intersection. Like traffic signals, they should have a minor impact on the routing itself (some small penalties compared to the highway importance). What you ask is more please GPS, tell me the traffic signs I'm just seeing now with my eyes. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal for soft play centres
2013/11/5 Erik Johansson erjo...@gmail.com I think it's not such a good idea to use leisure=playground + fee=yes, since it most certainly is not a playground, but sure playgrounds really do span a very big range from a sandbox to extremely large contraptions . +1, I think his current proposal leisure=indoor_play is fine, I'd encourage mappers to add explicitly fee=yes/no/amount because otherwise (if fee is implied) we would have to invent another tag for those places that are non-commercial or offer this kind of service as included in the general entrance fee to a bigger place. It would be interesting to tag place where kids can play, many museums/science centers have that as well. IMHO the same tag could be used. I'd also add a link from the current proposal to this page: https://wiki.openstreetmap.org/wiki/Key:playground because the tagging of the equipment could be the same than for leisure=playground where possible. CHeers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
On Tue, Nov 5, 2013 at 5:25 AM, Balázs Barcsik balazs.barc...@gmail.comwrote: So I would prefer to create such tags for priority cases - which can be assigned to ways This breaks down in North America, which lacks this concept. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
Hi, in Germany we have the concept of countys and citys within those countys. E.g. admin_level=8 within admin_level=6. Now as an exception every rule follows bigger citys are their own countys, or dont belong to a county. (Kreisfreie Städte) Administrative wise these citys take all administrative burden of the countys and their respective citys, so they are admin_level 6 AND 8. The problem which arises now is that these citys are currently tagged with an admin boundary of admin_level=6. Thus nominatim is not able to find whether this is a real county or a county free big city. The result is that nominatim returns the name of the city in the county address detail and no city (due to the lack of further admin_level 8 boundarys). A fix would be an admin_level=6;8 on the boundary or duplicating the relation. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] give way and stop tag for ways
And in the UK, I have only come across priority diamonds in mainland Europe. Phil (trigpoint) -- Sent from my Nokia N9 On 05/11/2013 15:20 Paul Johnson wrote: On Tue, Nov 5, 2013 at 5:25 AM, Balázs Barcsik balazs.barc...@gmail.com wrote: So I would prefer to create such tags for priority cases - which can be assigned to ways This breaks down in North America, which lacks this concept. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
On Tue, Nov 5, 2013 at 4:22 PM, Florian Lohoff f...@zz.de wrote: A fix would be an admin_level=6;8 on the boundary or duplicating the relation. I'm surprised you still have such questions in Germany. Your description is not clear since you don't explain what is on the way and what is on the relation. But I can tell how it *should* be : on the boudary way : put the highest admin level (thus, with the lowest numerical number). And create one relation per admin_level, obviously. What I guess is that the admin_level on the way is just used for rendering purpose, not by nominatim which should exclusively work with admin boundary relations or place nodes. For the county free big city, simply don't create a relation with admin_level 6 but keep only the one exclusively for admin_level 8. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
In the UK we do the opposite. In Unitary Authorities, which combine the role of the county with the district (sounds like the same as the Kreisfreie Staedte) we tag the UA as admin_level=6, i.e. at the same level as counties, and not admin_level=8 which is the level for the districts. We also occasionally use designation with specific values (from a controlled vocabulary) to distinguish between the different entities which may share an admin level. Colin On 2013-11-05 16:55, Pieren wrote: On Tue, Nov 5, 2013 at 4:22 PM, Florian Lohoff f...@zz.de wrote: A fix would be an admin_level=6;8 on the boundary or duplicating the relation. I'm surprised you still have such questions in Germany. Your description is not clear since you don't explain what is on the way and what is on the relation. But I can tell how it *should* be : on the boudary way : put the highest admin level (thus, with the lowest numerical number). And create one relation per admin_level, obviously. What I guess is that the admin_level on the way is just used for rendering purpose, not by nominatim which should exclusively work with admin boundary relations or place nodes. For the county free big city, simply don't create a relation with admin_level 6 but keep only the one exclusively for admin_level 8. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
Hi, On Tue, Nov 05, 2013 at 06:18:44PM +0100, Colin Smale wrote: In the UK we do the opposite. In Unitary Authorities, which combine the role of the county with the district (sounds like the same as the Kreisfreie Staedte) we tag the UA as admin_level=6, i.e. at the same level as counties, and not admin_level=8 which is the level for the districts. We also occasionally use designation with specific values (from a controlled vocabulary) to distinguish between the different entities which may share an admin level. How do you distinct the Unitary Authorities with countys based on the relation data? For Germany the name on the relation is in fact the citys name not the countys but you cant tell which is which. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
On Tue, Nov 05, 2013 at 04:55:42PM +0100, Pieren wrote: On Tue, Nov 5, 2013 at 4:22 PM, Florian Lohoff f...@zz.de wrote: A fix would be an admin_level=6;8 on the boundary or duplicating the relation. I'm surprised you still have such questions in Germany. Your description is not clear since you don't explain what is on the way and what is on the relation. But I can tell how it *should* be : on The way is irrelevant. The admin boundarys is a collection of ways, be it waterways, highways or other ways making up the boundary. The relation contains an admin_level=6 which is the level for Countys. With the Kreisfreie Städte the name on _that_ relation is actually the Citys name although the level would imply it to be the countys name. So nominatim is right to show the name as the countys name as thats exactly what has been tagged. But its not only the countys name but more the citys name. the boudary way : put the highest admin level (thus, with the lowest numerical number). And create one relation per admin_level, obviously. What I guess is that the admin_level on the way is just used for rendering purpose, not by nominatim which should exclusively work with admin boundary relations or place nodes. How would nominatim really find adresses belonging to a place/city? We have been there in 2008 without any boundarys and it was a mess to decide which place node this address belongs to - distance is not a measure for choosing your place. For the county free big city, simply don't create a relation with admin_level 6 but keep only the one exclusively for admin_level 8. The point is that the administrative boundarys is one of level 6 AND level 8. - if you only put a level 8 on the relation you loose the information about the importance of the administrative city. - if you only put a level 6 on the relation you loose the information about the city. A county will be the same as the countyless city which it isnt - and there is no way to tell if this is a county without any fine grained boundarys or a countyless city.. This is what we have right now. - If you create both relations e.g. 6 _and_ 8 in seperate relations its not easy to tell whether this is really a countyless city unless geometrically comparing the boundary. So we need a better way to mark multi level admin boundarys. admin_level=6;8 could be a solution. Or a new tag like admin_level=6 admin_level_low=8 or admin_level_range=6-8 Just brainstorming. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
2013/11/5 Pieren pier...@gmail.com I'm surprised you still have such questions in Germany. Your description is not clear since you don't explain what is on the way and what is on the relation. it shouldn't matter. Mostly you don't need a relation at all (if not to reduce redundancy by overlapping ways), as long as there aren't enclaves/exclaves involved. Actually the ways don't have to be any tags at all (IMHO), but boundary=administrative surely helps to reduce destruction by mappers with less capable editors (those that don't expose relations). But I can tell how it *should* be : on the boudary way : put the highest admin level (thus, with the lowest numerical number). And create one relation per admin_level, obviously. for which admin levels? For all admin levels there would be if it wasn't an exception? If they are admin_level=6 and there is no 8 in this case? There is a similar case with Bremen, Hamburg and Berlin, which are level 4 (and 6 and 5?). I'd also use distinct relations for admin_level=6 and 4 in this case, but this is disputed in the German comunity. For the county free big city, simply don't create a relation with admin_level 6 but keep only the one exclusively for admin_level 8. -1, as they are at the same level as a county (or Berlin/Hamburg/Bremen is at the same level as a Bundesland) they should definitely be admin_level=4 (or 6 in Flos example), but the question is if we should also make a relation with admin_level=6 or 8. IMHO yes. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 05.11.2013 16:22, Florian Lohoff wrote: A fix would be an admin_level=6;8 on the boundary or duplicating the relation. Duplicating the relation seems easiest and is what I'd probably do, but of course it is not 100% correct as there aren't two different admin boundaries (or, in the case of Hamburg, and Berlin, three - here admin_levels 4,6,8 are folded into one). Brian Quinion has actually attempted to duplicate the Bremen admin boundary for this very reason in early 2013 http://www.openstreetmap.org/browse/changeset/14997436 and the edit was promptly reverted by user adjuva http://www.openstreetmap.org/browse/changeset/16623822 who claimed that his was tagging for the geocoder. So if we wanted to make it a rule that boundaries are duplicated, we'll certainly have some explaining to do. Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSeVUFAAoJEOx/uhGAJu9HpOkH/3U/bfJINBRQg6e6tpf2Yr4B c7YHqiZ4gLBX3eVaUuLwkaRvWH0rR/cv2aVBRYPknY717cEMuz77VmLEa2ybTL9H RaNDX6VSYUTKgdmfNKv1mSx+jcB/CPDBFI8aReWY9thOKl9LKdA/O1fka8DMTgOn XNWxuxIeKbx01DM35H0tMbcW7h/7IHLN0vPIUFJdloYKGLmIly/LHIjD9BqLG1Uo hUBNHG6Yekkrmi9vPlXKyK4AluxQfjHI2KCzE0xXKuAOXoB+R3PSOKhG44J9ReW/ NR/sa2ZduU0xAp3yyx1JI48in0aos/iaeRVmGKcgcQVRYZ/l7hKtEvRAz3O+T/Y= =WoRT -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gambling
Am 05.11.2013 um 22:14 schrieb Matthijs Melissen i...@matthijsmelissen.nl: And what is the opinion of other users about moving casino into the leisure tag space? I don't see any advantage. Leisure so far was used mostly for sport related places, parks, nature reserves and playgrounds, generally casinos and even more gambling and betting places don't fit so nicely in IMHO and people would probably expect it in amenity, because most stuff is in amenity. Don't know what the problem would be that amenity is said to be overcrowded or full ;-) Anyway, any tag that can be established is fine in the end, so it doesn't really matter as long as people are OK with it and it fits sufficiently into the rest of the system in order to avoid confusion among the mappers. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
On Wed, Nov 6, 2013 at 4:28 AM, Frederik Ramm frede...@remote.org wrote: Duplicating the relation seems easiest and is what I'd probably do, but of course it is not 100% correct as there aren't two different admin boundaries (or, in the case of Hamburg, and Berlin, three - here admin_levels 4,6,8 are folded into one). So if we wanted to make it a rule that boundaries are duplicated, we'll certainly have some explaining to do. Maybe we can apply the idea of a geometric relation (I think first proposed by Frederik, I believe) and use that as a member for an administrative relation. The geometric relation is tagged like a multipolygon and only represents the boundary as an abstract line. Then we have several admin boundary relations of different admin_level=* tags that has this geometric relation as a member. Cons: 1. We would have 1 more relation to deal with 2. The relation-in-a-relation concept is complicated Pros: 1. It would be slightly easier to determine that two admin_level boundaries are coincident without doing geometric calculations or member comparisons. Now that I've written the above, I think the complexity is too big for the problem it solves. So I'm in favor of duplicated relations. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
