Re: [Tagging] AddrN
Oh no, why one more proposal? Another broken "solution" for a problem which is already solved. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
On 18/01/2015 5:14 PM, tagging-requ...@openstreetmap.org wrote: Date: Sun, 18 Jan 2015 00:14:36 -0600 From: "John F. Eldredge" To: "Tag discussion, strategy and related tools" , Volker Schmidt Subject: Re: [Tagging] Tagging road illumination quality Message-ID: <14afbadb528.27a5.8c042f3e6e983dd0f57452e62f7f8...@jfeldredge.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" You could use a light meter to measure how bright the light is. That isn't the only factor in the suitability of the lighting, but it is objective. My 'smartphone' can give a light reading -Andriod using app 'GPS Status' in lux or foot candle. There should be others that do the same kind of thing. Uses the camera function to determine the light from the exposure. But 'we' will need guidance on how best to measure it. Possibly pointing it at the ground immediately under the light for a hi reading, and anothe midway between two lights for a low reading and take the average? Maybe a google will turn up some ideas? The phones won't be accurate but should be good enough for an indication. -- John F. Eldredge -- j...@jfeldredge.com "Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that." -- Martin Luther King, Jr. On January 16, 2015 11:18:33 AM Volker Schmidt wrote: >I would like to enter illumination quality for bicycle infrastructure >(cycleways) in OSM. >Any suggestions welcome > >Volker ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
I am very cautious about any of this kind of measurement for the following reasons: 1) the results will be very difficult to standardise 2) the effort is far beyond that what a mapper can reasonably do. If you wanted to do it properly you needed to mount a measuring device in such a way that it looks downwards to measure the reflected light, may be on some kind of arm protruding from your vehicle (bicycle in my case) and then record continuously the measurement. Now you have to consider the parameters: measurement device characteristics distance from the ground weather conditions (we would need to define "standard dry weather", because with rain you will have the problem of direct reflectosn of light sources) signal integration parameters (do you average over 10m for example?) and most likely others. Then you still have the problem of how to define the illumination quality of a stretch of cycle path. Assume you have a 100m stretch with nice illumination but there is a tiny S-bend exactly overshadowed by an evergreen tree, which produces a pitch dark spot of 10m at a dangerous point. What do you do? Put an illumination value every 5 meters or, and that's what I would do, mark the entire 100m stretch as lit=very_poor (or something similar). Constructive and realistic suggestions are welcome. Volker On 18 January 2015 at 11:34, Warin <61sundow...@gmail.com> wrote: > On 18/01/2015 5:14 PM, tagging-requ...@openstreetmap.org wrote: > > Date: Sun, 18 Jan 2015 00:14:36 -0600 > From: "John F. Eldredge" > To: "Tag discussion, strategy and related tools" >, Volker Schmidt > > Subject: Re: [Tagging] Tagging road illumination quality > Message-ID: > <14afbadb528.27a5.8c042f3e6e983dd0f57452e62f7f8...@jfeldredge.com> > <14afbadb528.27a5.8c042f3e6e983dd0f57452e62f7f8...@jfeldredge.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > You could use a light meter to measure how bright the light is. That isn't > the only factor in the suitability of the lighting, but it is objective. > > > My 'smartphone' can give a light reading -Andriod using app 'GPS Status' > in lux or foot candle. There should be others that do the same kind of > thing. Uses the camera function to determine the light from the exposure. > But 'we' will need guidance on how best to measure it. Possibly pointing it > at the ground immediately under the light for a hi reading, and anothe > midway between two lights for a low reading and take the average? Maybe a > google will turn up some ideas? The phones won't be accurate but should be > good enough for an indication. > > -- > John F. Eldredge -- j...@jfeldredge.com > "Darkness cannot drive out darkness; only light can do that. Hate cannot > drive out hate; only love can do that." -- Martin Luther King, Jr. > > > > On January 16, 2015 11:18:33 AM Volker Schmidt > wrote: > > > > I would like to enter illumination quality for bicycle infrastructure> > (cycleways) in OSM. > > > > Any suggestions welcome>> Volker > > > > ___ > 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] waterway=wadi problem
On Sat, Jan 17, 2015 at 12:14:53PM -0800, Tod Fitch wrote: > > > > usually you will assume it if there are ponds of open water or swamps > > in several places along a valley. > > A pond/swamp/oasis/cienega in an arid or even semi-arid area is a significant > feature that deserve mapping in its own right. Using that to infer > information about a nearby or connected item seems a stretch to me. ponds and such should be mapped. Infering an underground waterflow from them may or may not be a stretch depending on the information that you have available. Often the underground waterflow is locally well known or can be inferred from many other informations. > The more I think about this issue the more I am coming to the feeling that > waterway=wadi ought to be deprecated and we should come up with a way of > further defining "intermittent" to distinguish between seasonal and ephemeral > flow patterns. Based on other responses on this thread maybe: that would be the best thing to do.. seems like otherwise every single mapper would use wadi in a different way. > waterway=* > intermittent=yes/no (default assumption of "no") > intermittent:frequency=winter/spring/summer/fall/seasonal/ephemeral/unknown > (default assumption of "unknown") +intermittent:frequency=random_rare/random_frequent ? We are still missing a definition of natural=valley afaics. There are some old proposals but I have been told on some other mailing list that valeys are nowadays mapped as a line natural=valley along the valley bottom. So maybe we should also document this or make a proposal to that effect. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)
Sorry but I'm sceptical about the scheme. It adds very little value compared to its own complexity. In particular the timing of the lights is highly volatile in modern cities, and it seems impossible to collect the ground truth as a mapper just by observing them. Take the 2050 traffic lights in Berlin for example [1], which are controlled in 3 tiers. Each junction works autonomously with predefined programmes for different times of the day and days of the week, even if disconnected. In the next tier, junctions are regionally clustered, so they can sync for better traffic flow. In the third tier, they are connected with two fibre rings to the traffic management centre in the former airport Tempelhof buildings, where their cycles can be completely changed and adapted: to the current traffic flow or accidents, in response to mass events, and e.g. to switch a 'green corridor' for a state visitor. Thus as a mapper with a stop watch, you never know which of these programmes you are currently observing. Tom [1] Ref: VMZ Berlin, 2013 Lukas Schaus wrote on 2015-01-15 12:15: Hello Everybody, please take some time to read my proposal concerning more detailed modelling of traffic signals and tell me your thoughts. http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals I will keep track of the discussion page and the Comments section of the proposal. Greetings Lukas Schaus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - leisure=fitness_centre
Would be great to get a bit more feedback. Maybe also on the talk page. Just want to keep this alive ;) http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/leisure%3Dfitness_centre Just had the great idea to suggest tagging gyms/fintess centres for the German a weekly task (new year's resolutions incoming), when I realized we still don't have tagging schema for it. After I failed to address the issues with leisure=gym in my last proposal (ambiguity of the word "gym) and don't see how to address them I made this new proposal with leisure=fitness_centre as I see it as only viable option left. http://wiki.openstreetmap.org/wiki/Proposed_features/leisure%3Dfitness_centre __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
My main suggestion would be to re-use the same scheme as Key:opening_hours to define the time when the waterway is likely to flow. I would also discard rare/frequent as too subjective. Instead: approximate duration are not perfect but should improve mutual understanding. For instance as in: waterway = * + intermittent = yes | no | periodical | random (default:no) ++ intermittent:periodical = [opening_hours scheme] (likely to flow at this date) eg. Mar-Jun | OR | Nov 20-Feb 20 | OR | ... ++ intermittent:random:interval = [approximate duration] (typical/assumed duration between two flowing events) eg. 2 weeks | OR | 3 years | OR | ... ++ intermittent:random:duration = [approximate duration] (typical/assumed duration of one flowing event) eg. 12 hours | OR | 3 days | OR | ... I am sure some people would like to go in more details, so why not: + intermittent:origin = rain | snowmelt | geothermal | ... + intermittent:effect = stream | torrential | flood | ... Mateusz Konieczny wrote: > Please, no "intermittent=ephemeral". Key intermittent was defined to have > only a single valid value, turning it into free-form tag is a bad idea. > > Maybe intermittent=yes, intermittent:type=ephemeral? Maybe other tags began with a key and a single valid value. Afterwards they evolved to multiple valid values for added details and nuances. Multiple valid values [option1|option2|...|optionN] is not the same as free-form [name/note/source/description=*], is it? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
> Am 18.01.2015 um 12:16 schrieb Volker Schmidt : > > Assume you have a 100m stretch with nice illumination but there is a tiny > S-bend exactly overshadowed by an evergreen tree, which produces a pitch dark > spot of 10m at a dangerous point. What do you do? Put an illumination value > every 5 meters or, and that's what I would do, mark the entire 100m stretch > as lit=very_poor (or something similar). I d split the way - at least for properties I care for, illumination details that go beyond the lit yes/no attribute are not yet in my workflow. I'd rather go for mapping individual street lamps before measuring raster data of light intensity, but currently this also seems too tedious ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
On 18.01.2015 09:18, Andrew Shadura wrote: > Oh no, why one more proposal? Sorry, my fault. Dmitry did it first. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
Streetlamp mapping does not help. All our city cycleways are within the lighting radius of street lamps, but - they are often interspersed with street-linign trees. - lamps may be on the opposite side of the street than the cyclepath - street lamps have illumination bodies pointing at strange angles - some street lamps are not strong enough - cycle ways are separated from streets by guard rails that throw a dark shadow excactly on the cycle way (in more than one place) This is admittedly the most bizarre of the problems So if I go ahead with a smoothness-like approach, is it better to use lit=no|yes|poor|sufficient|good or lit=yes lit:level=poor|sufficient|good Thanks Volker On 18 January 2015 at 16:20, Martin Koppenhoefer wrote: > > > > > > Am 18.01.2015 um 12:16 schrieb Volker Schmidt : > > > > Assume you have a 100m stretch with nice illumination but there is a > tiny S-bend exactly overshadowed by an evergreen tree, which produces a > pitch dark spot of 10m at a dangerous point. What do you do? Put an > illumination value every 5 meters or, and that's what I would do, mark the > entire 100m stretch as lit=very_poor (or something similar). > > > > > I d split the way - at least for properties I care for, illumination > details that go beyond the lit yes/no attribute are not yet in my workflow. > > > I'd rather go for mapping individual street lamps before measuring raster > data of light intensity, but currently this also seems too tedious ;-) > > cheers, > Martin > ___ > 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] Tagging a corner address with addr:street:corner=*
On 17.01.2015 23:47, Eugene Alvin Villar wrote: > But imagine for a minute that you are back in > the 1990s (without GPS) in a third-world country and you only have a paper > map. If you are given a restaurant to visit with an address such as #45 > Ayala Avenue, you would, in the worst case, go down the whole length of > Ayala Avenue looking for the correct house number. But if instead you were > given Ayala Avenue corner Makati Avenue, then you can go straight to the > intersection and just look around for the restaurant. One difference between Europe and the Philippines may be that housenumbers in Europe were invented for administration, not for retrieval or navigation. I should add that cities were smaller at that time (18th century). There was no need to search for a restaurant. You either knew it, or you didn't need it. > I prefer addr:corner_street instead of addr:street_corner. After all, the > data to be recorded under the key is the name for a street, not a corner. > addr:corner is not quite easy to understand without the proper context. addr:corner_street is not easy to understand without the context either. > addr:street1=* would potentially be confused with the addrN proposal. You may be right, because there's one pitfall: street+street2 need to be used in combination, while addr+addr2 are alternatives. > Would > you and others agree that addr:corner_street is the best choice? If yes, > I'll bring this topic up on our mailing list. I don't have a clear preference. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Overhead signs (Überkopfwegweiser)
Well, we already have two systems which work well together to get all tagged. 1. the already mentioned destination*:lanes=* system 2. additionally the relation type=destination_sign So the only thing I would miss are some tags to better tag the properties of the sign itself like direction=*, support=* or ele=*. Do we have traffic_sign=destination_sign or highway=destination_sign or similar tag as main tag for the node. Is gauntry that important, that we need an own main tag dor it or would it better fit as subtag ? Eventually even support=* alone will work. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)
Additional to below I want to mention that on a micromapping style a traffic_signal is placed one the pedistrian crossing or the stop_line. I even came across ones one the stop_line and an addition highway=crossing on the pedestrian crossing. I am tagging direction=* for the direcion it faces. Together with the :lanes tagging you do not need any relation at all but could simply add the information on the node with :lanes tagging cu fly Am 18.01.2015 um 14:14 schrieb Tom Pfeifer: > Sorry but I'm sceptical about the scheme. It adds very little value > compared > to its own complexity. In particular the timing of the lights is highly > volatile > in modern cities, and it seems impossible to collect the ground truth as a > mapper just by observing them. > > Take the 2050 traffic lights in Berlin for example [1], which are > controlled in 3 tiers. > Each junction works autonomously with predefined programmes for > different times > of the day and days of the week, even if disconnected. In the next tier, > junctions are regionally clustered, so they can sync for better traffic > flow. > In the third tier, they are connected with two fibre rings to the traffic > management centre in the former airport Tempelhof buildings, where their > cycles can > be completely changed and adapted: to the current traffic flow or > accidents, > in response to mass events, and e.g. to switch a 'green corridor' for a > state visitor. > > Thus as a mapper with a stop watch, you never know which of these > programmes > you are currently observing. > > Tom +1 > [1] Ref: VMZ Berlin, 2013 > > Lukas Schaus wrote on 2015-01-15 12:15: >> Hello Everybody, >> >> please take some time to read my proposal concerning more detailed >> modelling of traffic signals and tell me your thoughts. >> >> http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals >> >> I will keep track of the discussion page and the Comments section of >> the proposal. >> >> Greetings >> >> Lukas Schaus >> > > > ___ > 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] Feature Proposal - RFC - addrN:*
Am 17.01.2015 um 23:11 schrieb Friedrich Volkmann: > On 16.01.2015 05:48, Ineiev wrote: >> On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: >>> >>> you could use polygons (e.g. 2 distinct multipolygons, one for each >>> address), and add a note to inform your fellow mapping colleagues that the >>> overlap is intended (note is not needed but nice). >> >> I think this solution has an essential advantage: distinct >> multipoligons with single addr:housenumbers can go do distinct >> associatedStreet relations. you can't do it with addrN:; and >> the mapper may want to use associatedStreet e.g. because >> it provides a way to specify parallel addresses in different >> languages (I believe, this feature is used in countries like Ukraine). > > If we need language versions for the street name, we'll probably need them > for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an > associatedStreet relation, but also an associatedCity relation. > > You can (mis-)use the addrN schema for that purpose: > > addr:city= > addr:street= > addr:housenumber=123 > addr:2:city= > addr:2:street= > addr:2:housenumber=123 > > The number of tags multiplies with the number of street/housenumber > combinations, but that may still be simpler than congruent housenumber > polygons all of which are member of several associatedSomething relations. > > I think that the best solution may be: > > addr:city= > addr:city:ru= > addr:street= > addr:street:ru= > addr:housenumber=123 +1 for language sufix. cu ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
I have found a previous topic, so let's continue. It's not an another solution, there is some mess with wiki pages but http://wiki.openstreetmap.org/wiki/AddrN and http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN Are the same scheme Andrew, I have already written, why point's isn't a good decision. There is no un contradictory way to determine, does POI have 1 address (from a nearest point inside one building polygon) or two. Martin, Dan usage of two overlapped polygons or duplicating things for address is a worst case. It will broke geometry, it will broke any kind of statistics for buildings, it will broke 3d and so on. And it's a huge overhead to draw one more polygon just to specify another address. Clifford, "If the business only uses one of the addresses, then the problem is solved with two nodes, ideally inside a building polygon." No both addresses is in use, if you open yellow pages - there is two addresses, even more, there is two addresses in government address plan. And one more time, how would you distinguish such two cases: One building with one polygon, and every enter marked as node with it's on address (some countries and some cities use address per entrance approach) In this case, building itself doesn't have an address One building with one polygon, and two addresses What would you suggest as an address for POI point inside such building polygon? For node buildings, how would you know, is it two buildings marked by nodes or two addresses for one building. Guys, it's look awkward because you have never met such things as two addresses for one building in real life. And it's not a problem to support such scheme, I have done plsql function that treats addrN case as two poins (table rows) for 3-4 hours, and I'm not an SQL expert. Nominatim already treats double addresses (marked via conscription numbers scheme)___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 17 January 2015 at 22:16, Friedrich Volkmann 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 > The provides_feature relation may be fine for entrances and parking places, > but using it for addresses adds too much unnecessary complexity to the > database. I am not sure if the "address" role is bad, but we shouldn't use > it in cases where we can do without that relation. If there is a need to explicitly associate one or more addresses with a building I don't see any other coherent way. Shoehorning multiple address into single object just goes against how things are modelled in OSM /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
2015-01-18 20:52 GMT+00:00 Markus Lindholm : > On 17 January 2015 at 22:16, Friedrich Volkmann 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! Best Dan ___ 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 wrote: > 2015-01-18 20:52 GMT+00:00 Markus Lindholm : >> On 17 January 2015 at 22:16, Friedrich Volkmann 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:*
Addresses are funny beasts. They may mean something different for the delivery guy, the mailman, the administration, the owner of the building, the cab driver who needs to let out a passenger. Maybe we should also indicate whether we mapped the ground parcel, the building, the doorbell, the mailbox, the service road/footway leading to the house... If you want to have both addresses and POIs only once, your only option is to use relations to tie them together unambiguously. In The Netherlands I found places where the address of the ground floor appartment differs from the appartment built on top of it. Do we have a good way to map those? The 'front' doors were in the back and one had to climb stairs to get to them. I don't really have an opinion. All I know is that in The Netherlands they now mapped multiple house numbers on dedicated nodes , which they placed withing the building contour in some diagonal fashion, and sometimes there are more than 10 for the same building. No idea if more than 100 also occurs. These are actual housenumbers not flat numbers. In Brussels we simply put 2 nodes inside the corner buildings. Buildings with 2 addresses are quite common there too. Both the addresses in Brussels and The Netherlands were imported from sources with a suitable license. Jo 2015-01-18 22:23 GMT+01:00 Markus Lindholm : > On 18 January 2015 at 22:11, Dan S wrote: > > 2015-01-18 20:52 GMT+00:00 Markus Lindholm : > >> On 17 January 2015 at 22:16, Friedrich Volkmann 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 > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
Dmitry, Conscription numbers are not double addresses, you're mixing things up. -- Cheers, Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)
Hi, Am 2015-01-18 um 19:02 schrieb fly: > Additional to below I want to mention that on a micromapping style a > traffic_signal is placed one the pedistrian crossing or the stop_line. I > even came across ones one the stop_line and an addition highway=crossing > on the pedestrian crossing. > > I am tagging direction=* for the direcion it faces. > > Together with the :lanes tagging you do not need any relation at all but > could simply add the information on the node with :lanes tagging I agree you. I have described a way to map it without relations using lane tagging which should exist if you want to have useful traffic simulations. https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals#This_tagging_scheme_is_the_total_opposite_of_KISS I mentioned this proposal at German OSM forum. http://forum.openstreetmap.org/viewtopic.php?id=29712 Main comments there: A large number of traffic lights/crossings have no programm. The show green to the branch streets if a waits there. Otherwise they show red to the branch streets and green to the main street. There are also traffic lights in cities which - show green for a couple of minutes if fire brigades approach to "clean the way". - can have extra-extra programms if a special event changes traffic flow - have multiple programms (one on the morning rush hour, one for the low-traffic periode between 9 and 12 a.m., one afternoon programm, one evening rush hour programm, one late-evening programm and a Sunday programm) Best regards Michael -- I prefer GPG-encrypted emails. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
On Sun, Jan 18, 2015 at 11:46 AM, Dmitry Kiselev wrote: > Clifford, > "If the business only uses one of the addresses, then the problem is solved > with two nodes, ideally inside a building polygon." > > No both addresses is in use, if you open yellow pages - there is two > addresses, even more, there is two addresses in government address plan. > > And one more time, how would you distinguish such two cases: > One building with one polygon, and every enter marked as node with it's on > address (some countries and some cities use address per entrance approach) > In this case, building itself doesn't have an address > > One building with one polygon, and two addresses > > What would you suggest as an address for POI point inside such building > polygon? > For node buildings, how would you know, is it two buildings marked by nodes > or two addresses for one building. > > Guys, it's look awkward because you have never met such things as two > addresses for one building in real life. > And it's not a problem to support such scheme, I have done plsql function > that treats addrN case as two poins (table rows) > for 3-4 hours, and I'm not an SQL expert. Nominatim already treats double > addresses (marked via conscription numbers scheme) > > Dmitry, Like a lot of us, I've never seen a building with multiple addresses (addrN), but I don't doubt that they exist. The only issue I see is a business residing within the building. My expectations would be they would pick one or the other. But without any knowledge it is hard to guess. So I fall back to how I tag building addresses. - Single building and single address, the address is included with the building outline - Single building with multiple addresses, the address information is include separate address nodes with the exception [1] noted below - POIs - tag with individual address nodes except where the POI occupies the entire building then tag the building outline -For addrN I would use two nodes if there is no building outline, no change from today's practice. -For addrN with a building outline I would use multiple nodes inside the building outlines, no change for today's practice. -POIs - this is where the addrN proposal works. Tag either the building outline with addrN or a single node inside of the building outline with addrN. There is one other aspect that I don't thing has been discussed. Normally you could use the building polygon to find POIs inside. However without a new tag, ie. addrN, it doesn't work. Nominatim would appear to work using todays address tagging practices if it only one of the addresses were used. I'm not sure what nominatim would do given two addresses. One of my concerns with this tagging is how to make it clear that it isn't for buildings with multiple entrances. We could end up with a bigger problem than the limited number buildings that fit the criteria of the addN proposal. I'm going to ask a friend that works for the county government on addressing to see if he can offer any insight into this issue. [1] The exception is when you have a main building address information along with nodes for units. Right now I'm working on an import where we a main building address and nodes for each unit. -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
So we have 2 millions things in OSM going against OSM modeling tradition: http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber It's same story, two addresses for one object. First: hn-street-city Second: hn-city Scheme is different, but principle is the same, two addresses for one object via tags. Sun, 18 Jan 2015 21:52:20 +0100 от Markus Lindholm : >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 > >> The provides_feature relation may be fine for entrances and parking places, >> but using it for addresses adds too much unnecessary complexity to the >> database. I am not sure if the "address" role is bad, but we shouldn't use >> it in cases where we can do without that relation. > >If there is a need to explicitly associate one or more addresses with >a building I don't see any other coherent way. Shoehorning multiple >address into single object just goes against how things are modelled >in OSM > >/Markus > >___ >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] Feature Proposal - RFC - addrN:*
Markus, there is no problems with distinct addresses at all if you treat them as first class citizen in your database. Table address id, scheme, hn, street, quarter, neighbourhood, city, e.t.c Table POI id, name, brand, operator, something, else Table POI_Addr POI (POI.id), addr (address.id) So you'll get distinct addresses and distinct POI with multiple addresses. Of course keeping two addresses (or three or more, look at the Vilnus) is more difficult than one address. But cause of this difficulties isn't an OSM tagging schema cause of this difficulties is multiple addressing itself. Me and Friedrich do not propose to trow away addr points or conscription numbers. There is a demand for addressing schema based on tags, and such schemes pop up every year. So I want, when somebody will find that he need to map 2 or more addresses and points (or anything else based on fake geometry) doesn't fit him, I want him to use addr2 and not addr:2 or addr_2 or street2+housenumber2. And if we don't have description for multiple addresses mapping via tags, it will be created and used without proposals and RFCs. Sun, 18 Jan 2015 22:23:30 +0100 от Markus Lindholm : >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 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AddrN
Andrew, and what is the difference? And why they are mapped in the same way as addresses? And why they appears in real life in a same way as addresses, and used by people in a same way as addresses? If something looks like a duck, and acts like duck maybe it's a duck. There is a lots of situations when we have more than one address. In some cases, especially when we have separated entrances or staircases or things with different addresses are separated in space separate points is better, in some cases they are not indeed. Mappers reinventing multyaddressing schemes not because they don't know about points, mappers do it, because there is many situations when separated points doesn't fit their needs. And I want all such reinventions be the same. If you happy with separated geometry - you are welcome, if you don't - let's come to one scheme. I have described why you might be unhappy with separated geometry earlier. Sun, 18 Jan 2015 23:32:15 +0100 от Andrew Shadura : >Dmitry, >Conscription numbers are not double addresses, you're mixing things up. >-- >Cheers, > Andrew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On Sat, Jan 17, 2015 at 11:11:23PM +0100, Friedrich Volkmann wrote: > On 16.01.2015 05:48, Ineiev wrote: > > On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: > >> > >> you could use polygons (e.g. 2 distinct multipolygons, one for each > >> address), and add a note to inform your fellow mapping colleagues that the > >> overlap is intended (note is not needed but nice). > > > > I think this solution has an essential advantage: distinct > > multipoligons with single addr:housenumbers can go do distinct > > associatedStreet relations. you can't do it with addrN:; and > > the mapper may want to use associatedStreet e.g. because > > it provides a way to specify parallel addresses in different > > languages (I believe, this feature is used in countries like Ukraine). > > If we need language versions for the street name, we'll probably need them > for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an > associatedStreet relation, but also an associatedCity relation. TTBOMK the city/country part of the address comes from the city multipoligon, and it does have an established way to specify localized versions. > You can (mis-)use the addrN schema for that purpose: > > addr:city= > addr:street= > addr:housenumber=123 > addr:2:city= > addr:2:street= > addr:2:housenumber=123 Indeed, it would be a misuse. the user of data should be able to identify the language. > The number of tags multiplies with the number of street/housenumber > combinations, but that may still be simpler than congruent housenumber > polygons all of which are member of several associatedSomething relations. > > I think that the best solution may be: > > addr:city= > addr:city:ru= > addr:street= > addr:street:ru= > addr:housenumber=123 Agreed; but those would be a bunch of new tags, while associatedStreet is already documented in wiki and hopefully supported by software. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
> addr:city= > addr:city:ru= > addr:street= > addr:street:ru= > addr:housenumber=123 It's unnecessary. addr:city= addr:street= addr:housenumber=123 Is enough, all kind of translations might be taken from matched street/city as good as any kind of old_names or alt_names Ofc. any scheme might be misused. Mon, 19 Jan 2015 02:40:14 -0500 от Ineiev : >On Sat, Jan 17, 2015 at 11:11:23PM +0100, Friedrich Volkmann wrote: >> On 16.01.2015 05:48, Ineiev wrote: >> > On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote: >> >> >> >> you could use polygons (e.g. 2 distinct multipolygons, one for each >> >> address), and add a note to inform your fellow mapping colleagues that the >> >> overlap is intended (note is not needed but nice). >> > >> > I think this solution has an essential advantage: distinct >> > multipoligons with single addr:housenumbers can go do distinct >> > associatedStreet relations. you can't do it with addrN:; and >> > the mapper may want to use associatedStreet e.g. because >> > it provides a way to specify parallel addresses in different >> > languages (I believe, this feature is used in countries like Ukraine). >> >> If we need language versions for the street name, we'll probably need them >> for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an >> associatedStreet relation, but also an associatedCity relation. > >TTBOMK the city/country part of the address comes from the city >multipoligon, and it does have an established way to specify >localized versions. > >> You can (mis-)use the addrN schema for that purpose: >> >> addr:city= >> addr:street= >> addr:housenumber=123 >> addr:2:city= >> addr:2:street= >> addr:2:housenumber=123 > >Indeed, it would be a misuse. the user of data should >be able to identify the language. > >> The number of tags multiplies with the number of street/housenumber >> combinations, but that may still be simpler than congruent housenumber >> polygons all of which are member of several associatedSomething relations. >> >> I think that the best solution may be: >> >> addr:city= >> addr:city:ru= >> addr:street= >> addr:street:ru= >> addr:housenumber=123 > >Agreed; but those would be a bunch of new tags, while >associatedStreet is already documented in wiki and hopefully >supported by software. > >___ >Tagging mailing list >Tagging@openstreetmap.org >https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
