Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Colin Smale]

Also true but no need for the "quotes". Mountain rescue teams don't just need 
to call 112/999. And although you can often make an emergency call without a 
SIM (I believe this does not actually work in the UK) nobody can call you 
unless you are registered and authorised on a network.


On 7 August 2023 20:24:30 BST, bkil  wrote:
>Just a note about your "fact": your phone can roam to any available
>network when you are dialing the emergency number. You can even dial
>it without a SIM inserted in most countries. Hence why it displays the
>text "emergency calls only" in such cases. Circuits towards the
>emergency number are also much higher prioritized, so when the line
>seems busy otherwise or produces unusable quality and drop-outs,
>emergency calls will still be more usable (with sufficient coverage of
>course).
>
>On Mon, Aug 7, 2023 at 9:03 PM Colin Smale  wrote:
>>
>> Two users on the same network standing next to each other can get different 
>> results. They may be connected to different base stations. CDMA is a whole 
>> other can of worms.
>>
>> There are so many variables, it's impossible to give detailed data for "cell 
>> phone reception at location X". But the original intention of the proposal 
>> was limited to campsites and a couple of other specific categories of place, 
>> which are often out in the sticks with no coverage. and I can see why it 
>> might be useful to have some kind of indication whether you can expect any 
>> kind of usable coverage at these locations. This would need to be specific 
>> about network, service provider (MVNO) and frequency band at least to be 
>> useful.
>>
>> Some networks allow voice-over-wifi. This might be a useful thing to record 
>> - if the location operator provides wifi, you may be able to use "WiFi 
>> Calling" even if the cellular coverage is dodgy.
>>
>> Interesting fact: Mountain rescue organisations often use SIMs from a 
>> different country, which are free to roam onto any network with a tiny bit 
>> of signal. If you are in your home state you will probably be locked to a 
>> specific network.
>>
>> On 07/08/2023 01:55 BST Mike Thompson  wrote:
>>
>>
>>
>>
>> On Sun, Aug 6, 2023 at 6:39 PM Evan Carroll  wrote:
>>
>>
>>
>> While I don't disagree, that's not an argument for OSM. OSM's job isn't to 
>> mitigate real world safety issues caused by technology. It's to map 
>> generally useful geographically verifiable things.
>>
>> I don't understand how cell coverage isn't verifiable - visit the site (e.g. 
>> campground) in question, pull out your phone, note how many bars, try to 
>> make a call, send a text, use some data (perhaps run a speed test). Yes, it 
>> is only good for your carrier, but the carrier should be recorded. Yes, 
>> there could be network congestion, or a tower could be out, but we map 
>> roads, and they can be congested, or closed due to accidents, flooding, 
>> landslides, construction, etc.  In some way, this is getting back to our 
>> roots, actually getting out and surveying, rather than just relying on 
>> satellite/aerial imagery.
>>
>> Mike
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Colin Smale]

Two users on the same network standing next to each other can get different 
results. They may be connected to different base stations. CDMA is a whole 
other can of worms.
 
There are so many variables, it's impossible to give detailed data for "cell 
phone reception at location X". But the original intention of the proposal was 
limited to campsites and a couple of other specific categories of place, which 
are often out in the sticks with no coverage. and I can see why it might be 
useful to have some kind of indication whether you can expect any kind of 
usable coverage at these locations. This would need to be specific about 
network, service provider (MVNO) and frequency band at least to be useful.
 
Some networks allow voice-over-wifi. This might be a useful thing to record - 
if the location operator provides wifi, you may be able to use "WiFi Calling" 
even if the cellular coverage is dodgy.
 
Interesting fact: Mountain rescue organisations often use SIMs from a different 
country, which are free to roam onto any network with a tiny bit of signal. If 
you are in your home state you will probably be locked to a specific network.

> On 07/08/2023 01:55 BST Mike Thompson  wrote:
>  
>  
>  
> 
> On Sun, Aug 6, 2023 at 6:39 PM Evan Carroll  mailto:m...@evancarroll.com> wrote:
> 
> >  
> >  
> > While I don't disagree, that's not an argument for OSM. OSM's job isn't to 
> > mitigate real world safety issues caused by technology. It's to map 
> > generally useful geographically verifiable things.
> > 
> I don't understand how cell coverage isn't verifiable - visit the site (e.g. 
> campground) in question, pull out your phone, note how many bars, try to make 
> a call, send a text, use some data (perhaps run a speed test). Yes, it is 
> only good for your carrier, but the carrier should be recorded. Yes, there 
> could be network congestion, or a tower could be out, but we map roads, and 
> they can be congested, or closed due to accidents, flooding, landslides, 
> construction, etc.  In some way, this is getting back to our roots, actually 
> getting out and surveying, rather than just relying on satellite/aerial 
> imagery.
>  
> Mike
> ___
> 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] Coach parking

[Colin Smale]

UK native here...

Looking at the vehicles, a bus would be more spartan, set up for fare 
collection, doors for speedy un/loading etc whereas a coach would almost always 
have only a single door (although some have more), be more luxurious, be 
equipped with seat belts etc. In bus-lover-land there are even so-called "Dual 
Purpose" vehicles which are in between being a bus and a coach.

Looking at the usage of the vehicles, a bus would typically be used on 
scheduled services with a predefined timetable and (mostly) predefined stops, 
whereas a coach would often be used on "private hire" arrangements for one-off 
journeys.

Having said that, there are many scheduled long-distance (city to city) 
services using coaches, and buses can also be used for private hire. There is 
also a grey area of express services with multiple stops along a predetermined 
route (I am thinking of the old Green Line network for example).

>From the perspective of traffic law, a "Bus Lane" may be restricted to 
>scheduled services by a licensed operator. Even empty buses returning to the 
>depot may not be allowed (as it is not on "active service"). Other bus lanes 
>might also allow private hire vehicles, it depends on the specific legislation.

My main point being that the way the vehicle is constructed may not be enough 
to determine whether it can use a bus lane or use a coach parking area - the 
circumstances of its use may also be significant.

Colin

> On 09/06/2023 16:24 CEST Greg Troxel  wrote:
> 
>  
> Anne-Karoline Distel  writes:
> 
> > [women's and parent's parking]
> 
> I can believe it exists, and it being common in .eu explains why it's in
> the josm presets.
> > You're right about caravans/ RVs, that should be its own tag as well and
> > be rendered. For coaches, I'm in favour of amenity=coach_parking (or
> > "bus_parking", if people don't like the term "coach". This might be
> > easier for non-native British English speakers), since that's how it's
> > done with cars and bicycles.
> 
> I would use the normal UK term, as OSM tradition is to use UK English.
> It seems coach is for distance and 'bus' is used for within a city as
> part of a rapid transit system.  But we need an en_GB native speaker to
> opine.
> 
> In the US people do use "motorcoach" to refer to a "tour bus" when
> trying to make it sound fancy, so I don't think coach_parking will
> confuse most en_US speakers.  But e.g. Greyhound calls itself bus.
> 
> > On a cynical sidenote, we're gonna need "SUV_parking" soon, because they
> > take up so much space.
> 
> I guess when you see it in the wild we can talk about how to map it.
> 
> In many parking garages in the US, there are spaces labeled "compact car
> only" which is a way of saying "this parking space isn't long enough".
> But generally there are some of those and many regular and nobody has to
> think about it, and I know of no place where you can't park in the
> facility at all if you don't have a compact car.
> 
> ___
> 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 the diameter of a mini-roundabout

[Colin Smale]

On 2 February 2023 09:59:01 CET, Philip Barnes  wrote:
>A mini roundabout often doesn't usually have a diameter. Most are jus normal 
>junctions which have been made mini-roundabouts to set a priority.

You mean they don't have a diameter because they are not even close to being 
circular?

In any case they will have an inner diameter being the size of the big white 
dot, which vehicles that are able to avoid, MUST avoid.

>
>So in terms of large vehicles it is the same problem as any other junctions, 
>whether they can turn left or right. 
>
>In the UK, U turns are prohibited at mini-roundabouts, which I would have 
>thought would be the main usecase for a diameter.
>

The Highway Code only uses the word "avoid" which means to me that they are not 
prohibited, just discouraged

>Phil (trigpoint)
>
>On 2 February 2023 03:31:39 GMT, Matija Nalis 
> wrote:
>>If the actual issue is that HGV cannot pass some road, why not simply mark it 
>>as 
>>`hgv=no`? Besides being simple, it has the additional advantage that routers
>>will actually already use it and direct HGVs somewhere where they can 
>>actually 
>>pass.
>>
>>Or if some lenghts of HGVs can pass, but others not, then maxlength=* 
>>or maxlength:hgv=* or some of the other alternatives from 
>>https://wiki.openstreetmap.org/wiki/Key:maxlength ?
>>
>>On Wed, 25 Jan 2023 21:25:32 +0100, Volker Schmidt  wrote:
>>> I see that I was not precise with my question: I am after a way to tag the
>>> overall diameter of the round surface composed of the mini-roundabout road
>>> surface plus the traversable central part. This is an important measure for
>>> trucks. I happen to live near one of these with an outer diameter of 12 m,
>>> and that attracts regularly articulated lorries like the cheese attracts
>>> flies. This triggered the question.
>>>
>>> Il giorno mer 25 gen 2023 alle ore 19:10 Peter Neale via Tagging <
>>> tagging@openstreetmap.org> ha scritto:
>>>
 According to the Wiki (with which I happen to agree), a mini-roundabout is
 defined as:
>>> >
 "...a special type of roundabout in which the middle can be traversed
  by vehicles, and is
 typically used where there is only limited space available. Road traffic
 flows in one direction around a point in the middle and the traffic in the
 roundabout has right-of-way. The middle of a mini-roundabout is usually
 only a painted circle, but there might also be a low, fully traversable
 (mountable) dome or island."
>>> >
 As it is traversable, does it really have a diameter?  Or, if there is a
 painted circle (are traversable domed area) on the ground, perhaps that has
 a diameter, but does it matter to any prospective map user?
>>> >
 Regards,
 Peter
>>> >
 Peter Neale
 t: 01908 309666
 m: 07968 341930
>>> >
>>> >
 On Wednesday, 25 January 2023 at 17:53:55 GMT, Volker Schmidt <
 vosc...@gmail.com> wrote:
>>> >
>>> >
 Is there an established way to tag the diameter of a mini-roundabout?
>>> >
 We have the tag diameter, but I could not find it applied to
 mini-roundabouts.
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
>>> >
>>
>>
>>-- 
>>Opinions above are GNU-copylefted.
>>
>>
>>___
>>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 the diameter of a mini-roundabout

[Colin Smale]

And, I would add, exceptional transports of up to maybe 100 tons or more may 
get one time permissions to use the road, possibly involving removing street 
furniture to enable the manoeuvre. Changing the physical dimensions of the 
carriageway is a bit more difficult though.

On 2 February 2023 09:39:51 CET, Martin Koppenhoefer  
wrote:
>
>
>sent from a phone
>
>> On 2 Feb 2023, at 04:34, Matija Nalis  
>> wrote:
>> 
>> If the actual issue is that HGV cannot pass some road, why not simply mark 
>> it as 
>> `hgv=no`?
>
>
>because hgv=no means forbidden to hgv (vehicles which may weight more than 
>2.8t).
>
>There are a lot of different sizes for hgv, weight is not the limiting factor 
>in general for curves
>___
>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 the diameter of a mini-roundabout

[Colin Smale]

The "Priority to the right" rule doesn't cover everything. Imagine a junction 
with two cars coming simultaneously from side roads on opposite sides of 
another road at right angles. Both want to leave the junction on the orthogonal 
road, in the same direction. One is making a right turn, and the other is 
making a left turn. Who goes first? The tiebreaker rule is what (I believe) 
Florian is calling "right before left," in the Netherlands it's called 
"shortest turn first". The car that is making the right turn goes before the 
car turning left.

The "priority to the right" rule is normally only encountered in residential 
areas and very rural areas, where the roads are deemed to be of equal 
significance. Where a road with substantial through traffic is involved the 
priority situation is usually made clear by signs (give way/stop, sometimes 
plus yellow diamond on through road) and road markings.

> On 29/01/2023 19:26 CET Philip Barnes  wrote:
> 
>  
> On Sun, 2023-01-29 at 14:31 +0100, Florian Lohoff wrote:
> > On Sun, Jan 29, 2023 at 12:12:06AM +, Philip Barnes wrote:
> > > 
> > > When I first encountered Canadian four way stops in 1980, I did
> > > think these should be mini-roundabouts. 
> > 
> > Thats the main point. In Germany we have a solution of "last resort"
> > which is called "Rechts vor links" - So when there is no other 
> > rules of priority its "Right before left".
> 
> That is a rule I believe exists in most of continental Europe. I
> certainly learned of it as ‘Priorité à droite’ in French lessons at
> school.
> 
> 
> > 
> > Other jurisdications dont have this so there is a problem with
> > producing
> > junctions with "equal priority". The UK solution is the "mini
> > roundabout".
> > 
> > So a mini roundabout is really "mini" or "tiny" - Not necessarily
> > round.
> A roundabout isn't necessarily round either :)
> 
> It about going around, the name comes from the fairground roundabout
> (carousel in American English) or a children's roundabout in
> playground.
> 
> A mini-roundabout in the UK, and in France which is the country which
> comes second in terms of my driving experience are signed with a blue
> sign with white arrows. Different to a normal roundabout. They are
> always traversable but doing so is often made uncomfortable for small
> vehicles by either building them up with concrete so they can be the
> height of a speed bump or with the use of setts.
> 
> Others are just white paint at what was once a give way and nobody goes
> around the paint. They just make priority equal.
> https://www.mapillary.com/app/?pKey=381114187015295
> 
> 
> I did spot this one today,
> https://www.mapillary.com/app/?pKey=509797140032524 which is
> traversable by a truck, but you wouldn't want to in a car.
> 
> 
> > The problem here starts with the imagery in the Wiki which IMHO dont
> > show mini roundabouts, but random roundabouts with traversable
> > center.
> Am not sure what you mean, all of the photos that say mini-roundabout,
> I would interpret as such. The one that looks different is
> https://wiki.openstreetmap.org/w/images/5/5e/Kreisverkehr.jpg but it
> has the mini-roundabout sign so I would treat it a a mini-roundabout. A
> large vehicle turning would have to cross the island. In reality most
> drivers would go straight over it.
> > 
> > And main distinction people read in the wiki is "traversable center"
> > so
> > everything with a traversable center gets tagged by mappers as mini
> > roundabout.
> > 
> I don't think I have ever come across a roundabout with a traversable
> centre, why would it even exist?
> 
> > So we have a problem with the wiki documentation. 
> It looks fine to me, although mini-roundabouts were common in the UK by
> the time I was learning to drive in the late 70s.
> 
> Phil (trigpoint)
> 
> ___
> 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 the diameter of a mini-roundabout

[Colin Smale]

I was trying to offer a universal model that would accommodate both "true" 
roundabouts and mini-roundabouts.
 
In the UK you are expected to make an effort to drive around the "dustbin lid" 
(painted circle) in the middle of the mini-roundabout, but that only makes 
sense for smaller vehicles. Larger things just drive straight over it of course.
 
I disagree that a truck driver is really not supposed to use what you call the 
Truck Apron. It is simply unavoidable for anything longer than a car. Better to 
use the inner ring than to go over the outer kerb trying to avoid it. That's 
what it's there for. In law it depends on whether you consider it part of the 
"rijbaan" or not, and opinions are divided on this. There are however many 
reasons for pushing traffic towards the outside of the circle, including 
regulating the speed, minimising overtaking and improving sight lines.
 
Modelling "turbo-roundabouts" (a real Dutch speciality) is a whole different 
can of worms.
 
By the way, for (very) large vehicles there is a technique called Swept Path 
Analysis, which can be used to calculate whether it will "fit" and be able to 
take a junction. It needs the geometry of the junction, but of course it also 
needs to know a lot more about the vehicle itself which is way beyond OSM.
 
By the way, I live in NL and my son is a traffic policeman...
 
 

> On 29/01/2023 00:17 CET Peter Elderson  wrote:
>  
>  
> Op za 28 jan. 2023 om 23:38 schreef Colin Smale  mailto:colin.sm...@xs4all.nl>:
> 
> > A form of roundabout common in the Netherlands has an inner ring which is 
> > often distinctly coloured and slightly raised, thus making it clear that 
> > traffic is intended to avoid it and use the outer ring, while keeping it 
> > perfectly usable by most vehicles.
> > Example: 
> > https://nl.wikipedia.org/wiki/Rotonde_(verkeer)#/media/Bestand:N746-Noordergraafsingel-Harbrinkhoek.jpg
> > 
> > 
>  
> The raised part is the truck apron. Traffic, including trucks, is not 
> dsupposed to use the truck apron. The kerb and the raised part warn the 
> trucker who forgets that.
> The roundabout shown there is a true roundabout. Mini-roundabouts do not 
> exist in Nederland, but we do have fake roundabouts (dot or circle in the 
> middle, possibly raised, no kerb, no roundabout rules. 
> Come to mention it, true roundabouts by themselves do not have special 
> priority rules in Nederland, just the oneway rule indicated by the roundabout 
> traffic signs. However, .priority is almost always indicated by at least 
> shark's teeth. If it isn't, traffic from the right has priority, same as on 
> regular junctions. (We're driving on the right).
> 
> As for diameters, I think the (minimal) turning circle or maximal rigid 
> vehicle length is what traffic needs. I am not sure that it can be calculated 
> from the diameters of inner centre circle, outer centre circle and 
> circumference of the entire traffic area.
>  
> 
> > 
> > > On 28/01/2023 22:12 CET Philip Barnes  > > mailto:p...@trigpoint.me.uk> wrote:
> > >  
> > >  
> > > Diameter implies there is something circular. The paint is often round, 
> > > not always, but most are just former T junctions or cross-roads where 
> > > there is nothing to measure the diameter of .
> > > 
> > > Phil (trigpoint)
> > > 
> > > On 25 January 2023 17:50:54 GMT, Volker Schmidt  > > mailto:vosc...@gmail.com> wrote:
> > > 
> > > > Is there an established way to tag the diameter of a mini-roundabout?
> > > >  
> > > > We have the tag diameter, but I could not find it applied to 
> > > > mini-roundabouts.
> > > > 
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> > > 
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org
> > https://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] tagging the diameter of a mini-roundabout

[Colin Smale]

Generalising for all roundabouts, I propose a model in which there are three 
diameters:
 
D1) outer diameter, where the outer kerb is
D2) "guide" inner diameter, the outer diameter of the inner ring intended to 
"discourage" traffic
D3) inner diameter, where the inner kerb or wall is (not traversable)
 
A mini-roundabout with no central obstruction will have D3=0 but may have D2>0 
(possibly 1m-3m)
A normal UK roundabout will not use D2
A form of roundabout common in the Netherlands has an inner ring which is often 
distinctly coloured and slightly raised, thus making it clear that traffic is 
intended to avoid it and use the outer ring, while keeping it perfectly usable 
by most vehicles.
Example: 
https://nl.wikipedia.org/wiki/Rotonde_(verkeer)#/media/Bestand:N746-Noordergraafsingel-Harbrinkhoek.jpg
 
These numbers can be used for simple navigation instructions as has been 
mentioned. But they could also be useful for route planning for oversize 
transports: can they make it around/across, given the available road width and 
the geometry of the turn they want to take?
 
Generalising further could replace circles and their diameters with concentric 
polygons to allow for odd-shaped roundabouts, but that might be a bridge too 
far at the moment?
 

> On 28/01/2023 22:12 CET Philip Barnes  wrote:
>  
>  
> Diameter implies there is something circular. The paint is often round, not 
> always, but most are just former T junctions or cross-roads where there is 
> nothing to measure the diameter of .
> 
> Phil (trigpoint)
> 
> On 25 January 2023 17:50:54 GMT, Volker Schmidt  wrote:
> 
> > Is there an established way to tag the diameter of a mini-roundabout?
> >  
> > We have the tag diameter, but I could not find it applied to 
> > mini-roundabouts.
> > 
> ___
> 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] craft vs office for service enterprises/establishments.

[Colin Smale]

Psychologists and psychotherapists are different things...

On 25 January 2023 23:00:59 CET, Graeme Fitzpatrick  
wrote:
>On Thu, 26 Jan 2023 at 02:51, Daniel Bégin  wrote:
>
>> and office=psychologist because they provide services.
>>
>
>I would usually use healthcare=psychotherapist for them.
>
>Thanks
>
>Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Colin Smale]

On 2020-12-13 21:53, Peter Elderson wrote:

> Just to clarify: 
>> crossing=priority Indicates that the node is a pedestrian crossing   
> when applied to highway=cycleway, should this read bicycle crossing?  
> 
> when applied to a highway=cycleway, does the tag imply priority for cyclists, 
> pedestrians, or both?

And what happens if a cycleway crosses a footway, as happens commonly
here in the Netherlands? 

We also have an analogous problem here where cycle tracks cross roads.
In many (but nowhere near all) cases the cycleway has priority.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag for dualband GPS ?

[Colin Smale]

On 2020-12-01 11:14, Warin wrote:

> The differences are less than 10m. (The points of the green track are where 
> data exists, the straight lines between those points simply connect the 
> measured points. ) 
> 
> The 'simplify way' in JOSM is normal set for a maximum difference of 3m as a 
> way of reducing data bloat while sacrificing some accuracy.

What accuracy is optimal for OSM? Why should we sacrifice any accuracy
at all? Who chose 3m as a tolerance figure? That sounds rather high to
me - it's the width of a small road, or half a house. If we are going to
draw a line at all, I would go for something <= 1m. 

Truly geometrically redundant points such as intermediate points on a
straight line are fair game, but de-wiggling by applying DP-type
algorithms should be done very sparingly IMHO. Smoothing and curve
fitting may also be fine on GPS traces, as you could consider them as
actually improving the data, but the argument of "data bloat" should not
be invoked as an excuse to arbitrarily sacrifice accuracy.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Colin Smale]

On 2020-11-18 21:31, Joseph Eisenberg wrote:

> Consider that the natural=coastline is defined as representing the mean high 
> water springs line, that is, the line of the highest tides.

Sorry to pick nits, but tides can be higher than MHWS; the "mean"
implies a long-term average, which will often be exceeded.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Colin Smale]

On 2020-10-25 15:47, Allroads wrote:

> All landuse what is used for legally public roads, laid down in a zoning plan 
> by the Government "bestemmingsplan" should be called landuse=highway no, 
> because the content of a bestemmingsplan is what is politically desired and 
> legally permitted, it is a plan. Landuse is not about the zoning plan, it is 
> about the actual current landuse, regardless of its compatibility with the 
> legal situation.

That's the irrevocable plan, then all is shaped. 

There can be a considerable amount of time between the approval of a
"bestemmingsplan" and its actual implementation in the case of certain
properties. When a plan is changed (a political decision) this gives
rise to claims for damages, and official waivers for the current status
(that may only apply to the current residents for example). There are
lots of ways in which the reality can legally diverge from the
"bestemmingsplan". 

As OSM prefers the reality to the theory, a zoning plan can only be an
indication. It will however often be in line with reality.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Artificial

[Colin Smale]

On 2020-10-21 10:59, Robert Delmenico wrote:

> I'll do some more research before the vote goes ahead. I've read quite a bit 
> of research around gendered language since first mentioning this idea.  
> 
> I'll be sure to list them in the proposal but feel free to send through any 
> sources that are both for and against the arguments I have raised. I'm 
> thinking that I'll mention the arguments both for and against on the proposal 
> page as this is a big proposal which if it succeeds will have a big impact. 
> 
> If anyone has any arguments for or against that they wish to have included in 
> the proposal, please feel free to leave them on the talk page for the 
> proposal.

If this goes through, it will be traumatic, however you look at it. Do
you have any suggestions how to abstract this specific example into a
more generic process to a) review all tags currently in the database; b)
all wiki content suggesting tagging; and c) all future proposals, to
assess their appropriateness in the current and likely future
environment?  

I don't mean to be flippant - this is a serious suggestion. If we are
going to have this kind of discussion around any graphology
incorporating "possibly offensive" groups of letters we had better have
a proper policy in place and a well-oiled process to deal with it.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity:source

[Colin Smale]

Hi Lukas, 

You do realise that all electricity is the same, irrespective of how it
is generated? The "greenness" or otherwise is not determined by the
connection, but by the subscription/contract that the consumer has with
their supplier. 

UNLESS they have a standalone generating capability, like PV or wind
turbine that is not connected to the grid. 

On 2020-09-29 16:00, Lukas Richert wrote:

> Hi, 
> 
> I'd like to propose a new tag that defines the source of publicly available 
> electricity: electricity:source [1] 
> 
> This could be used as an additional information tag on amenities that provide 
> electricity for public consumption, such as bike/car charging stations or 
> camp sites. Many charging stations have nearby solar or use green pricing 
> tariffs. I've also seen camp sites and harbours advertise this. 
> 
> This topic came up as a group wanted to plan a bike tour using e-bikes but 
> only with renewable energy. I noticed that there appears to be no easy way to 
> filter for the source of the electricity provided. 
> 
> Potential discussion: It's not quite clear to me whether power_supply or 
> electricity is preferred for this type of application. It might also be 
> interesting for consumers to see which buildings are powered by green 
> electricity if this is something a store or similar advertises. So it may be 
> worth expanding the proposal to electricity used by the public even if not 
> directly available (e.g. lighting in a store). 
> 
> Best regards, Lukas
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1]
https://wiki.openstreetmap.org/wiki/Proposed_features/electricity:source___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Colin Smale]

On 2020-08-18 22:39, Clay Smalley wrote:

> If you 
> 
> On Tue, Aug 18, 2020 at 12:51 PM Colin Smale  wrote: 
> 
> On 2020-08-18 20:55, Clay Smalley wrote: 
> 
> On Tue, Aug 18, 2020 at 11:26 AM Colin Smale  wrote: 
> There are two use cases here: one is "what is the address of this building 
> (or whatever)" and the other is the reverse situation: "where can I find 
> number XXX". As long as we have tagging that is potentially ambiguous we 
> won't be able to cover both. 
> In the US I know of cases where an apartment number can follow the street 
> address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I 
> know of the suffix being used to indicate apartment number, or floor number - 
> e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other 
> characters are used for the floor/flat such as A/B/C or I/II/III - in these 
> cases it is unambiguous because it is non-numeric. 
> Can you point out some examples? I've never seen that syntax used in US 
> addresses.

If you mean the US example, some friends were living in Long Island
City, Queens, NY, and their apartment address was something like
1100-157 50th Ave. The other examples are possibly typically European.
Here in the Netherlands there are all kinds of notations in use for
sub-units. The national addressing standard has a field for an
alphanumeric "house number suffix" for this that people in IT know
about, but the average Johan might not know what a
"huisnummertoevoeging" is. Normally the full number, including the
suffix, is written together with some kind of separator. 

I think you misunderstand hyphenated addresses in Queens. The second
part of the hyphenation is not a flat/apartment number. As an example,
the Dunkin Donuts at the corner of 31st St and 36th Ave has an address
of 31-02 36th Ave, with no apartment number. The US Postal Service
considers this to be equivalent to 3102 36th Ave, and will deliver mail
to the same place regardless of whether you include the hyphen, though
the address written on the entrance is hyphenated. Most building numbers
in Queens have a hyphen before the last two digits. 

Thanks for the explanation.. It is indeed a while ago since I was there.
Any idea how this is structured in IT systems? Is "house number"
alphanumeric? Are the two parts stored separately? Or is it simply a
question of formatting, inserting a "-" before the final two digits? 

Maybe we should use a different character to indicate a range, such as a
slash? 

>> There are also areas where the whole neighbourhood has a single street name, 
>> and everybody has a very long house number; the initial digits of the house 
>> number indicate the specific road within the neighbourhood. Sometimes these 
>> house numbers are written as 123-45 to aid navigation.
> 
> Examples?

https://www.openstreetmap.org/#map=17/51.80636/5.80412 

https://www.openstreetmap.org/#map=17/51.83527/5.78425 

https://www.openstreetmap.org/#map=18/52.29739/4.68692___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Colin Smale]

On 2020-08-18 20:55, Clay Smalley wrote:

> On Tue, Aug 18, 2020 at 11:26 AM Colin Smale  wrote: 
> 
>> There are two use cases here: one is "what is the address of this building 
>> (or whatever)" and the other is the reverse situation: "where can I find 
>> number XXX". As long as we have tagging that is potentially ambiguous we 
>> won't be able to cover both. 
>> In the US I know of cases where an apartment number can follow the street 
>> address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I 
>> know of the suffix being used to indicate apartment number, or floor number 
>> - e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other 
>> characters are used for the floor/flat such as A/B/C or I/II/III - in these 
>> cases it is unambiguous because it is non-numeric.
> 
> Can you point out some examples? I've never seen that syntax used in US 
> addresses.

If you mean the US example, some friends were living in Long Island
City, Queens, NY, and their apartment address was something like
1100-157 50th Ave. The other examples are possibly typically European.
Here in the Netherlands there are all kinds of notations in use for
sub-units. The national addressing standard has a field for an
alphanumeric "house number suffix" for this that people in IT know
about, but the average Johan might not know what a
"huisnummertoevoeging" is. Normally the full number, including the
suffix, is written together with some kind of separator. 

There are also areas where the whole neighbourhood has a single street
name, and everybody has a very long house number; the initial digits of
the house number indicate the specific road within the neighbourhood.
Sometimes these house numbers are written as 123-45 to aid navigation. 

>> On the other hand using the "1-5" notation to indicate a range is pretty 
>> well understood in the UK at least. What it is missing is the 
>> "interpolation" value (even, odd, all). 
>> So let us sort this mess out by defining: 
>> 1) that a hyphen indicates a range 
>> 2) sub-addresses like a floor or apartment number must not use the hyphen 
>> notation, but must be given in addr:unit 
>> 3) an address using the range syntax should indicate the interpolation 
>> scheme by means of addr:interpolation=*
> 
> This leaves the situation in Queens, NY unsolved, where hyphenated addresses 
> do not indicate ranges.

As I mentioned above I know that hyphenated addresses can be used for
subdivisions (apartments etc). Are there any other scenarios for
hyphenated addresses?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Colin Smale]

On 2020-08-18 16:10, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 18. Aug 2020, at 05:34, Paul White  wrote:
>> 
>> I wanted to raise a concern about tagging house numbers on a building using 
>> a hyphen to denote the address range (e.g 33-55 Main Street).

> It's their address, and I might also map the individual numbers and their 
> positions additionally, so it might eventually become more clear to someone 
> looking at the situation.
> Sometimes when the business uses 37/39 I will admittedly convert this to 
> 37;39 for clarity.

There are two use cases here: one is "what is the address of this
building (or whatever)" and the other is the reverse situation: "where
can I find number XXX". As long as we have tagging that is potentially
ambiguous we won't be able to cover both. 

In the US I know of cases where an apartment number can follow the
street address, i.e. 10-321 meaning Street Address 10, apartment 321. In
Europe I know of the suffix being used to indicate apartment number, or
floor number - e.g. 379-3 meaning Street Address 379, Floor/Flat 3.
Sometimes other characters are used for the floor/flat such as A/B/C or
I/II/III - in these cases it is unambiguous because it is non-numeric. 

On the other hand using the "1-5" notation to indicate a range is pretty
well understood in the UK at least. What it is missing is the
"interpolation" value (even, odd, all). 

So let us sort this mess out by defining: 
1) that a hyphen indicates a range 
2) sub-addresses like a floor or apartment number must not use the
hyphen notation, but must be given in addr:unit 
3) an address using the range syntax should indicate the interpolation
scheme by means of addr:interpolation=*___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-17 00:12, Martin Koppenhoefer wrote:

> sent from a phone 
> 
>> On 16. Aug 2020, at 15:26, dktue  wrote:
> 
>> Ok, then I'm going to edit the wiki [1] now.
>> 
>> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
> 
> sorry for this late comment, but maybe it would be better to use 
> station:position=top/mid (or middle) / bottom 
> 
> reasoning is that aerialway:station might be wanted for subtypes of the 
> stations (I am not an expert for aerialway station types, but sooner or later 
> someone will come along who is, and even if they decide to use "station" for 
> these potential subtypes, it would still be confusing having also an 
> aerialway:station with different meaning)

The OP's intention was to label the "valley station" and "mountain
station" in machine-readable form (a controlled vocabulary domain). The
discussions about how to distinguish them, showed that the only
significant characteristic is the altitude. Other attributes like the
presence of the drive motors, ticket sales etc are not determinants of
the "valley" vs "mountain" labels.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

[Colin Smale]

Nope You can't have a mid terminal, by definition. And as "terminal"
is used with similar semantics to "station" here, if you start with
aerialway:station you don't need to include "terminal" or "station" in
the value as well. 

That web page doesn't refer at all to the "top station" or the "bottom
station", but it does refer to a "midstation"; I am not sure what you
actually derived from that page?

On 2020-08-15 18:25, Yves wrote:

> Had a look at http://www.skilifts.org/old/glossary.htm, came up with :
> 
> Aerialway:station=top_terminal, mid_terminal, bottom_terminal
> 
> Yves 
> 
> ___
> 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] Antwort: Re: Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-15 15:15, dktue wrote:

> The main thing is that people often refer to "Talstation" and "Bergstation" 
> but this information is not machine-readeable but mostly encoded in the names 
> of the stations. My goal ist to make this machine-readeable because it almost 
> all cases people can refer to it even if they do not know the station's name. 
> It's obvious what's meant in almost every case what I mean when I say 
> "Bergstation Mutteralmbahn" [1] even if the station's name doesn't say so 
> [2]. So let's put this into machine-readeable tags to enable applications to 
> solve a problem not for specialists but for the general map purpose we're 
> building.
> 
> In my opinion we did have the right discussion and have a very good proposed 
> definition with easy values that people with a basic understanding of english 
> can understand. Do you agree?

Yes, I agree, provided the values are "top/bottom" or "upper/lower" and
not "head/base". Even "mountain/valley" could be problematic as it
depends on the geography and not simply on the geometry (an end-station
half-way up the mountain, what is that?). The distinction is purely
about the altitude of the end-station relative to the other, not about
whether it is surrounded by shops or rocks. 

This will enable a user to select all top-stations for example, or to
label the stations on a given cableway appropriately.

> [1] https://www.openstreetmap.org/way/26746748
> [2] https://www.openstreetmap.org/node/293382166
> 
> Am 15.08.2020 um 15:03 schrieb Colin Smale: 
> 
> It seems we can't even agree on what question to ask an "expert". @dktue I 
> think you started this discussion... What was your intention at the time? Was 
> it "how do we identify top/bottom stations on a cable car"? If you ask an 
> "expert" you might get an answer involving the project numbers for the build 
> phase, or the serial numbers of the pylons. Let's stop looking for even more 
> solutions until we have clearly defined the problem. Otherwise you will end 
> up with 100 different "solutions" and an argument about which is best. If 
> it's about tagging the stations as upper/mid/lower according to their 
> altitude and topological location, then we are there already; you should 
> prepare a tagging proposal and put it to the vote.
> 
> And bear in mind the values should ultimately be meaningful to a normal 
> person, not just to a ski lift engineer, and to people with limited English 
> (so using French/German/Italian nomenclature for example would not be 
> helpful). 
> 
> On 2020-08-15 14:37, Yves wrote: 
> 
> Maybe (as always here) we are too few specialists on this list to find the 
> right values. I know of two forum funivie.org and remontées-mécaniques.net 
> that specialize in the field, but in Italian and French. Does anybody know of 
> a similar community, but English speaking?
> Maybe we could have good advice and get a few new mapper's on board.
> Yves
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Antwort: Re: Aerialway stations

[Colin Smale]

It seems we can't even agree on what question to ask an "expert". @dktue
I think you started this discussion... What was your intention at the
time? Was it "how do we identify top/bottom stations on a cable car"? If
you ask an "expert" you might get an answer involving the project
numbers for the build phase, or the serial numbers of the pylons. Let's
stop looking for even more solutions until we have clearly defined the
problem. Otherwise you will end up with 100 different "solutions" and an
argument about which is best. If it's about tagging the stations as
upper/mid/lower according to their altitude and topological location,
then we are there already; you should prepare a tagging proposal and put
it to the vote.

And bear in mind the values should ultimately be meaningful to a normal
person, not just to a ski lift engineer, and to people with limited
English (so using French/German/Italian nomenclature for example would
not be helpful). 

On 2020-08-15 14:37, Yves wrote:

> Maybe (as always here) we are too few specialists on this list to find the 
> right values. I know of two forum funivie.org and remontées-mécaniques.net 
> that specialize in the field, but in Italian and French. Does anybody know of 
> a similar community, but English speaking?
> Maybe we could have good advice and get a few new mapper's on board.
> Yves
> 
> ___
> 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] Antwort: Re: Antwort: Re: Aerialway stations

[Colin Smale]

Yes, I object to the specific values, as I (and others) said earlier.
The use of "base" and "head" is not intuitive and will lead to confusion
and errors amongst non-fluent English speakers. More basic words like
"top" and "bottom", or maybe "upper" and "lower", are preferable.

You can/should remove the word "opposite" from the definition; this will
make it completely independent of the other definitions. 

On 2020-08-15 13:44, dktue wrote:

> To make in unambiguous, the definition would then be:
> 
> aerialway:station=base
> 
> for the station at an end of the aerialway with the lower altitude,
> 
> aerialway:station=head
> 
> for the station at the opposite end of the aerialway (hence with a higher 
> altitude) and
> 
> aerialway:station=mid
> 
> for any station not being at the end of and aerialway regardless of the 
> altitude.
> 
> Anyone who wants to improve or oppose to this definition?
> 
> Cheers
> dktue
> 
> Am 15.08.2020 um 13:37 schrieb Werner.Haag@leitstelle.tirol: 
> 
>> Hi,
>> 
>> it was mentioned, we have many aerialways in Tyrol and there are really 
>> cases where the mid station is the one with the highest altitude.
>> I found an example ("Schindlergratbahn", base 2035 m, mid 2643 m , head 2579 
>> m, see link ). So i think, the second scheme with  base, mid, head could
>> be the better scheme.
>> https://www.openstreetmap.org/way/23103020 [1] 
>> 
>> Werner
>> 
>> "Yves"  schrieb am 14.08.2020 18:07:53:
>> 
>>> Von: "Yves" 
>>> An: "Tag discussion, strategy and related tools" 
>>> , "Mateusz Konieczny via Tagging" 
>>> 
>>> Kopie: "Tagging" 
>>> Datum: 14.08.2020 18:09
>>> Betreff: Re: [Tagging] Antwort: Re: Aerialway stations
>>> 
>>> I'm not a natural speaker, head like in where the aerialway is heading.
>>> I propose the second scheme because of the duplicate meaning with 
>>> ele in the definition, and because the aim of an aerialway could be 
>>> lower than mid. 
>>> Yves 
>> 
>>> Le 14 août 2020 17:32:08 GMT+02:00, Mateusz Konieczny via Tagging 
>>>  a écrit :
>>> I strongly prefer up/top over head.
>>> 
>>> At least for me (not representative,
>>> not a native speaker), head = up
>>> is not clear.
>>> 
>>> 14 Aug 2020, 17:05 by em...@daniel-korn.de:
>>> Am 14.08.2020 um 16:37 schrieb yvecai:
>>> 
>>> I would propose, if you want to use altitude as a definition:
>>> bottom: the end station with the lower altitude
>>> up: the end station with the higher altitude
>>> mid: any station, not being a base or a head station, irrespective 
>>> of the altitude
>>> Or, alternatively one that does not compete with the ele tag and 
>>> carry a destination meaning (my preference):
>>> base: the 'valley' station, usually with the lower altitude
>>> head: the 'mountain' or 'top' station, usually with the higher altitude
>>> mid: any station, not being a base or a head station.
>>> 
>>> aewrialway:station has my preference
>>> Yves
>>> I like both. Any other people here with a peference for one of Yves' 
>>> schemes?
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://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
 

Links:
--
[1] https://www.openstreetmap.org/way/23103020___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

[Colin Smale]

We really should avoid words like "usually. " If there exceptions to the 
elevation critérium, or if other factors are significant in working out the 
correct value, then this also needs documenting...



On 14 August 2020 17:05:37 CEST, dktue  wrote:
>Am 14.08.2020 um 16:37 schrieb yvecai:
>>
>> I would propose, if you want to use altitude as a definition:
>>
>> bottom: the end station with the lower altitude
>> up: the end station with the higher altitude
>> mid: any station, not being a base or a head station,
>irrespective
>> of the altitude
>>
>> Or, alternatively one that does not compete with the ele tag and
>carry 
>> a destination meaning (my preference):
>>
>> base: the 'valley' station, usually with the lower altitude
>> head: the 'mountain' or 'top' station, usually with the higher
>> altitude
>> mid: any station, not being a base or a head station.
>>
>> aewrialway:station has my preference
>>
>> Yves
>>
>I like both. Any other people here with a peference for one of Yves' 
>schemes?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-14 13:55, dktue wrote:

> Am 14.08.2020 um 13:34 schrieb Colin Smale: 
> 
> On 2020-08-14 13:14, dktue wrote: 
> Am 14.08.2020 um 13:11 schrieb Yves: Base / mid / head? I'm definitely open 
> for that! :-)

OK, two people agree on the strings to use, but what are the semantics?
What sentence would go in the wiki to describe a) when to use the value
and b) what the value implies once it is in the OSM data? 

It sounds like it might be something like: 

base: the end station with the lower altitude 
head: the end station with the higher altitude 
mid: any station, not being a base or a head station, irrespective of
the altitude 

note: based purely on altitude, not arrival/departure inclination 
  That sounds perfectly reasoneable to me!

> As to which key to use, how about aerialway:station={base,mid,head}?
 I suggested station={base,mid,head} because we're using aerial=station
and then it seemed natural to go with station=* but I'd be definitely
happy with aerialway:station=*.

I suggested aerialway:station=* precisely to avoid overloading station=*
(different semantics under different circumstances). 

As a native English speaker by the way I would suggest that "top" and
"bottom" might be simpler instead of "base" and "head". Using easy words
means you don't need to explain it to people who either don't know the
words, or know them in a different context.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-14 13:14, dktue wrote:

> Am 14.08.2020 um 13:11 schrieb Yves: 
> 
>> Base / mid / head?
> I'm definitely open for that! :-)

OK, two people agree on the strings to use, but what are the semantics?
What sentence would go in the wiki to describe a) when to use the value
and b) what the value implies once it is in the OSM data? 

It sounds like it might be something like: 

base: the end station with the lower altitude 
head: the end station with the higher altitude 
mid: any station, not being a base or a head station, irrespective of
the altitude 

note: based purely on altitude, not arrival/departure inclination 

As to which key to use, how about aerialway:station={base,mid,head}?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-13 19:41, Yves wrote:

> If top, middle, bottom have a meaning for the OP, I'm not sure it's really 
> general, counter-examples have been given.

It's not the OP's private project, there is a reason why this is being
debated in public.

> To avoid confusion with elevation, what would be another way to tag them? 
> Motor position have been given, but it is not really relevant for the common 
> user.
> For routing aerialway:access and the connection to a piste:type=downhill 
> start (or whatever) may be sufficient. 
> What is the use case here?

Good question! Not because there isn't one, but because it helps to
understand which problem we are solving, and to get everyone on the same
page before we all start contributing solutions to different problems.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Antwort: Re: Aerialway stations

[Colin Smale]

On 2020-08-13 18:35, Werner.Haag@leitstelle.tirol wrote:

> Hi, 
> 
> in my opinion (i think dktue is right there) it should be easy for a user to 
> distinguish or extract (overpass query) the upper, mid and lower stations. 
> That´s not possible at the moment in OSM. Elevation (ele tag) may be useful, 
> but does not indicate whether a station is the lower or upper one. 
> On the other hand, a tagging with upper_station or lower_station is clear and 
> self-explanatory.

It would also be a denormalisation of the data. In SQL terms you would
use a subquery like "WHERE ele = MIN(SELECT ele FROM stations WHERE...)"
although I suspect the usual use case will be looking for the whole
line, so a simple "ORDER BY ele" would give you all you need to know -
bottom station is first row, top station is last row, rows 2..n-1 are
mid stations. This would avoid any possibility of conflicting
information, e.g. multiple stations tagged as top, or the station with
the lowest elevation being tagged as top station. 

All this is based on the assumption that the definition of the top
station is the one with the highest altitude If any other factors
are in play that could mean that this definition does not always hold
true, then I am keen to hear It's best to check assumptions, even
(especially?) if they do appear obvious.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Colin Smale]

On 2020-08-13 14:49, dktue wrote:

> I think it's easy for a mapper to determine if a station is a bottom_station 
> or a upper_station even if he doesn't know the exact elevation.

I would advise against such generalisations - it depends so much on the
circumstances and the mapper in question. OSM prefers objective data. 

This one has a difference of only 40m. Optically/subjectively it's
pretty much dead level. I have done it many times. 

http://www.ski-aravis.com/component/content/article/53-remonteeslcl/165-clusaz-telepherique-transval-057.html


Despite the minimal difference the website does indicate that one side
is the "top station" and the other side is the "bottom station", but
that's probably not a valid source. Anyway, suppose they were both at
exactly the same altitude. What's the intrinsic difference between top
station and bottom station? The location of the drive motors perhaps?
That would be an objective attribute that we could put into OSM
(motor=yes/no?)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Colin Smale]

On 2020-08-13 14:07, dktue wrote:

> I think that it's quite hard for data consumers (again: think of an 
> overpass-query to find all mid-stations) to determine which role a station 
> has. Like Martin said: Why not just solve the (huge!) special case of 
> mountain aerialways where we really have one bottom_station, zero or more 
> mid_station and one upper_station?

Because cases that don't obviously fit that model will remain untagged,
or get subjectively/wrongly tagged with this model or some other tags.
There are many cases of arialways that start and finish at roughly the
same level. Do they have two bottom stations, or two top stations, or do
you force someone to make a judgement call as to which is slightly
higher than the other? 

If you want to find all mid-stations, do you want to find ALL
mid-stations or are you happy with MOST or MANY or SOME? 

Modelling reality is all about what to leave out. If top-stations,
mid-stations and bottom-stations can be reliably derived from elevation
and topology then there is no need to add a more explicit tag.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerialway stations

[Colin Smale]

So what is wrong with ele=* on the stations and the topography of the
line? Completely (for OSM purposes) objective and uncontroversial. The
data consumer/renderer can make their own mind up about nomenclature.
Many of these lifts go up to go down, or go down to go up, as they cross
ridges and valleys. One man's incline on a segment of the route is
another man's decline based on the station altitudes. Let's tag the
facts, and not subjective naming. 

On 2020-08-12 22:47, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 12. Aug 2020, at 21:39, Yves  wrote:
>> 
>> Alexey, you're right, anyway physical properties like incline are better 
>> tagged on way than on relations.
> 
> and horizontal aerialways aren't completely unheard of either. The incline 
> solution works only for a subset of aerialways. Generally, for horizontal 
> aerialways top and bottom / valley do not apply, i.e. the original question 
> is directly related to a specific (frequent) configuration: an aerialway 
> which surmounts a significant height difference. We do not have to find a 
> universal solution if the question relates only to this special case.
> 
> 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] Rio de la Plata edit war

[Colin Smale]

On 2020-08-07 11:18, Christoph Hormann wrote:

> On Friday 07 August 2020, Colin Smale wrote: 
> 
>> The word "ocean" is already subjective... [...]
> 
> Oh please.  Not again another attempt to deflect into a discussion of 
> language semantics

Completely the other way around. I hope to remove the dependence on
terms subject to interpretation in favour of relatively
non-controversial terms such as "water," "foreshore" and "land." 

> The distinction between a river and the world ocean is real and a 
> fundamental aspect of our scientific understanding of the geography of 
> this planet.

But the big "grey area" where a given point could be considered either
or both (or something else entirely like "estuary", "salt marsh" or
"mangrove") is what we are discussing here. A taxonomy requiring that
each point is in exactly one of {land,river,ocean} is not viable for OSM
because (around the edges) it requires specialist knowledge to
determine, it depends on which "specialist" you take as a reference and
is not verifiable by the average mapper. 

> That digital maps have - based on the precedent set by 
> Google - almost universally ignored this fact does not change it.

You say Google have "ignored" this. What makes you think that we can
find a solution where Google haven't?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-07 12:04, Mateusz Konieczny via Tagging wrote:

> Aug 7, 2020, 11:36 by colin.sm...@xs4all.nl: 
> 
> On 2020-08-07 11:18, Christoph Hormann wrote: 
> 
> That digital maps have - based on the precedent set by 
> Google - almost universally ignored this fact does not change it. 
> 
> You say Google have "ignored" this. What makes you think that we can find a 
> solution where Google haven't?

This is an absurd argument, we did plenty of things where Google and
Google Maps failed. 

This is not an argument at all, it's a question. Empirical evidence
would suggest we have also not yet found a solution, so we are in no
position to gloat about this. 

Currently we are still in the dick-waving stage and not converging on a
consensus that will be usable by most mappers and data consumers. 

Let's start with a hypothesis - a certain tagging model which we expect
will be good enough (to start with). Then check how that fits against
real-world situations, make incremental refinements to the model, and
iterate. Perfection is the enemy of the good! If the result of this
discussion is to be of any value at all, it must fit with most of the
world, both the geographical realities and the human/cultural aspects.
Getting too deep into the details too early is bound to fail.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-07 09:27, Christoph Hormann wrote:

>> I concur with a lot of your observations and like you i had essentially 
>> given up on the idea of the coastline representing meaningful 
>> information in the long term.  But considering this is a very sad 
>> conclusion which essentially means OpenStreetMap failing in its primary 
>> goal in the single most fundamental mapping task of the planet, namely 
>> the distinction between ocean and land, i am trying my best here to 
>> work towards a consensus - no matter how slim the chances are from my 
>> perspective.

The word "ocean" is already subjective... We need fundamentally to
distinguish between land, foreshore and water. These are objective there
should be not much argument, except for maybe which low/high water line
to use (mean springs or whatever). What the various areas are CALLED is
the subject here, and clearly one man's coastline is another man's
riverbank. But the fundamental pair of lines, creating the three zones
(land, foreshore and water) are required in any case. 

By including a definition in OSM of the transition from river to
estuary, or from estuary to sea, we are actually "tagging for the
renderer" because we are removing the choice from the data consumer and
forcing a particular paradigm on the (OSM)-world. We have proven time
and time again that it is impossible to synthesise a compromise that
suits everyone - it just ends up suiting no-one.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-04 22:46, Paul Allen wrote:

> On Tue, 4 Aug 2020 at 19:54, Joseph Eisenberg  
> wrote: 
> 
>> Similarly, should Puget Sound and San Francisco Bay be mapped as 
>> natural=water + water=river? These are also estuaries.
> 
> I suspect the answer is contained within the question.  We have the words 
> "ocean" and "estuary" because we consider them to be different things.  We 
> might bicker a little about where the dividing line is but understand them as 
> being different concepts.  Where does the coastline end?  At the start of 
> the estuary.

In my perception they can overlap.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-04 17:40, Martin Koppenhoefer wrote:

> +1, similarly in Italy, the baseline is defined through (relatively few) 
> coordinates in a law, which is located always on the most outer points of the 
> land or on islands, it has few to do with the coastline. For example the Gulf 
> of Taranto is completely included.

The status of the Gulf of Taranto is disputable as it appears to have no
basis in international law.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Have our tagging voting rules changed recently?

[Colin Smale]

On 2020-08-04 10:06, Andrew Harvey wrote:

> I'd suggest that if you vote no, it will be helpful for the community if you 
> could elaborate on why you're voting no, without enforcing a reason as 
> mandatory. Is it because this feature shouldn't be mapped, is it because 
> there is an alternative tag. So if the vote fails all this feedback can be 
> taken onboard for a revisal of the proposal and second round of voting.

The explanation should possibly have been given earlier, during the
consultancy phase? In a vote, the only thing that should count towards
the outcome is how you vote, not why you voted that way. All votes have
equal weight, irrespective of their motivation. 

However, in the ensuing inquest it is obviously useful to understand why
a proposal was not supported by many people.. For that matter, it is
also useful to know what made people support it as well. 

Putting a proposal to the vote should IMHO not be done unless the
discussions are clearly pointing towards approval. A vote is not a
substitute for the discussion, it should be a confirmation that
consensus has been achieved.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail (Michael Reichert)

[Colin Smale]

Hi Garry, 

On 2020-06-13 18:49, Garry Keenor wrote:

> Also, there are only 2 networks that I can identify worldwide that are 4th 
> rail, and I've tagged them both already. :-)

You may have missed one I just discovered that the LIM lines of
SkyTrain (Vancouver) have some kind of 4-rail system: 

"Two power rails (positive and negative) were chosen instead of the
conventional single third rail system with return via the track, to
eliminate electrolytic corrosion in underground structures and in the
guideway itself. This dual power rail system also provides significant
protection against ground faults." 

https://www.ejrcf.or.jp/jrtr/jrtr16/f44_vancouver.html#:~:text=Propulsion%20uses%20two%20Linear%20Induction,technology%20to%20mass%20transit%20systems.


I haven't yet been able to find any decent images that show the topology
of the 5 (2 running, 2 power, 1 propulsion) rails in cross-section 

Regards, 
Colin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Colin Smale]

On 2020-07-30 15:05, Alan Mackie wrote:

> On Thu, 30 Jul 2020 at 13:35, Colin Smale  wrote: 
> 
>> On 2020-07-30 14:02, Frederik Ramm wrote:You might not like it, but the EU 
>> is already a super-state that acts as one, with a federation of states 
>> below. I know the whole idea of a "United States of Europe" and a formal 
>> federal constitution is toxic, but basically we are already there. What is 
>> left to do is to remove the opt-outs and other exceptional treatment 
>> afforded to certain states.

> If this is truly the case then we already have a label for this: 
> admin_level=2 (but see below).

The absolute number of the admin_level is less relevant than the
relative position in the hierarchy. The level for the EU must be above
(i.e. numerically lower) than the level of its members. If the EU comes
in at level 2, then the member states would have to go to level 3 or 4;
as many countries already use these levels, it could cause an avalanche
of changes and cause the tagging in Europe to get unacceptably out of
step with the rest of the world. The EU is a unique construct, so it
should not be surprising if it needs a unique solution in OSM. 

> I would prefer to map the EU as a contract than as an administrative
> boundary. There are many such contracts around the world, where smaller
> countries pool their defense or other typically national capabilities,
> and I would not be surprised if there were situations where countries
> pool their defense with one group, and their currency with another.
> Mapping these things as "areas on the map" is old-style cartographic
> thinking. We can do better than that. 
> The EU has laws with direct effect, which override national laws. This 
> pooling of capabilities you refer to would not have any laws of its own - 
> only treaties between countries, which may implement certain measures in 
> their national laws as a consequence. The EU is not like that, it has its own 
> laws, that our representatives get to vote on.

EU directives generally have to be transposed into national law by all
the member states. IIRC it is the copy-pasted law that theoretically
holds the power even though the members have all agreed to run
everything through the photocopier. Whether this is a tangible thing or
just a figleaf is for the lawyers to fight over. 

No, it is extremely clear that some EU directives have direct effect,
without any action being required from the member states. 

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=LEGISSUM%3Al14547 

> Even *if* a boundary was mapped, it would probably more pragmatic to map
> the outer boundary of the Schengen region than the outer boundary of the
> EU states. 
> The Schengen region is DEFINITELY not an admin boundary. It does not 
> actually exist in a tangible form, only as EU law and treaties of association 
> on paper. It covers only part of the EU, and several non-EU territories.

I disagree with this, the agents at the border are very tangible. 

The agents at the border don't work for "Schengen" - they work for their
national organisations. There is no "Schengen" to employ them. What I
meant by tangible was some kind of organisation with people and offices.
It also doesn't have its own rules and regulations - they are now part
of the aquis communitaire. Changes to "Schengen rules" are just EU law
changes like any other. Speaking of border agents, it is actually the
absence of such agents (on the internal borders) that characterises
Schengen; the presence of immigration officers at the outer boundary
just makes it like any "normal" international border. 

(This is why a new EU member state would not have to sign up to Schengen
- it would be automatic on accession. If you wanted an opt-out you would
have to negotiate for that)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Colin Smale]

On 2020-07-30 14:02, Frederik Ramm wrote:

> Hi,
> 
> On 30.07.20 13:32, Colin Smale wrote: 
> 
>> The EU is «composed-of» whole member states. It has all the attributes
>> of a governmental administrative body - with the executive, parliament
>> and justicial branches impacting citizens directly.
> 
> To me as a citizen of a EU country it does not feel like the EU is a
> higher-level administrative body than the country. Yes, countries have
> decided to contractually transfer some rights and responsibilities to
> the EU but that doesn't (in my mind) mean the EU is some form of
> super-state. Quitting the EU if you don't like it is much easier than
> seceding from a country.

Ask the Brits how easy it is to leave... 

You might not like it, but the EU is already a super-state that acts as
one, with a federation of states below. I know the whole idea of a
"United States of Europe" and a formal federal constitution is toxic,
but basically we are already there. What is left to do is to remove the
opt-outs and other exceptional treatment afforded to certain states. 

> I would prefer to map the EU as a contract than as an administrative
> boundary. There are many such contracts around the world, where smaller
> countries pool their defense or other typically national capabilities,
> and I would not be surprised if there were situations where countries
> pool their defense with one group, and their currency with another.
> Mapping these things as "areas on the map" is old-style cartographic
> thinking. We can do better than that.

The EU has laws with direct effect, which override national laws. This
pooling of capabilities you refer to would not have any laws of its own
- only treaties between countries, which may implement certain measures
in their national laws as a consequence. The EU is not like that, it has
its own laws, that our representatives get to vote on. 

On the other hand, if you are actually questioning the inclusion of
administrative boundaries in OSM as a basic principle, that would be a
different can of worms entirely. 

> Even *if* a boundary was mapped, it would probably more pragmatic to map
> the outer boundary of the Schengen region than the outer boundary of the
> EU states.

The Schengen region is DEFINITELY not an admin boundary. It does not
actually exist in a tangible form, only as EU law and treaties of
association on paper. It covers only part of the EU, and several non-EU
territories.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail

[Colin Smale]

On 2020-06-13 18:58, Garry Keenor wrote:

> Colin, 
> 
> Thanks for your comments. 
> 
> I want to clear one very important thing up. The tag electrified=* is 
> currently being used in OSM to define the *contact system* in use, not the 
> power supply. All railway electrification systems require a sliding contact 
> between train and infrastructure to transfer electrical current.

OK fair point. You and I may have a more holistic view of the whole
complex ecosystem of components that are needed to make an electric
train move, but I can imagine the "general public" may well have a
narrower view and see the pantograph or contact shoe as the "power
supply to the train". 

When tagging hyperloop and maglev systems there is often no *contact
system* as such I guess we should think of something like
"electrified=induction"?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail

[Colin Smale]

On 2020-06-11 13:36, Paul Allen wrote:

> On Thu, 11 Jun 2020 at 12:30, Peter Neale via Tagging 
>  wrote:
> 
>> ...or (almost getting serious now) we could just assume that, if the 3rd 
>> rail is mentioned, then the 1st and 2nd must be there (otherwise it wouldn't 
>> be 3rd rail) and, if the 4th rail is mentioned, then the 1st, 2nd and 3rd 
>> must also be there.
> 
> Please desist from pedantic frivolity.  It only encourages others to follow 
> suit 
> by saying things like "3 rail and 4 rail are grammatically better" and then 
> where 
> would we be?

My suggestion to use (for example) 3rail instead of 3rd_rail was also
for the benefit of non-English speakers. I have seen countless examples
of "1rd" and "5st" and similar errors. Describing it as a 3-rail or
4-rail system is IMHO less likely to result in mis-spelt tags.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail

[Colin Smale]

On 2020-06-11 13:28, Peter Neale via Tagging wrote:

> At the risk of being called pedantic, or frivolous, surely it should be, 
> "1st+2nd+3rd+4th rail" (after all, it won't work without the 1st and 2nd 
> rails)! 
> 
> ...or (almost getting serious now) we could just assume that, if the 3rd rail 
> is mentioned, then the 1st and 2nd must be there (otherwise it wouldn't be 
> 3rd rail) and, if the 4th rail is mentioned, then the 1st, 2nd and 3rd must 
> also be there.

There might be a maglev system somewhere using two conductor rails,
which would then be the 1st and 2nd? 

Remember we are discussing the power supply, not the running rails. The
power supply only needs the 3rd and 4th. Take away the running rails,
jack up the train, and you could still get the motors to turn (safety
systems permitting). 

A serious question arises though... The Wuppertaler Schwebebahn get its
power from the 2nd rail (it's a suspended monorail). What do we do with
this? electrified=2nd_rail?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail (Colin Smale)

[Colin Smale]

Hi Garry, thanks for your reply. I am pleased to hear that the "related
issues" are already on the radar and I am more than happy to see them in
a following proposal.

One thought about 3rd_rail/4th_rail vs 3rail/4rail: The term "4th rail"
is actually semantically incorrect, and should really be "3rd+4th rail"
(after all, it won't work without the 3rd rail.) That problem would not
occur if we tag it as "4-rail" or "4rail." 

Thanks, 

Colin 

On 2020-06-11 09:49, Garry Keenor wrote:

> Colin, 
> 
> Thanks for your comments. I'm a bit behind so I'll try to catch up with your 
> comments to date. 
> 
> Re: 3rd_rail/4th_rail vs 3rail/4rail 
> I really don't mind and will go with the majority. Not sure how you determine 
> a majority with this process! 
> 
> Re: keeping electrified=rail to mean 3rd rail and have a new 
> electrified=4th_rail or  electrified=4rail We did discuss that as a group, 
> and again if that is the majority preference, I would not have a problem with 
> it. 
> 
> Voltages for individual rails 
> We do have some thoughts on that which I will share in a later proposal, but 
> I would like to keep this change discussion focused purely on electrification 
> type. 
> 
> Dual voltage areas 
> We do have a specific proposal/solution for that problem  which I will share 
> in a later proposal, but I would like to keep this change discussion focused 
> purely on electrification type. 
> 
> 3 phase electrification 
> II haven't thought about that one, let's get this proposal through the 
> process and I'll put it on the list to think about. 
> 
> best regards, 
> 
> Garry 
> ___
> 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 - 3rd and 4th rail

[Colin Smale]

When I just checked around Gunnersbury I noticed that someone is already
retagging the London Underground to electrified=4th_rail so this
discussion is probably already irrelevant 

On 2020-06-09 23:12, Michael Reichert wrote:

> Hi Colin,
> 
> Am 09/06/2020 um 15.36 schrieb Colin Smale: 
> 
>> Great idea. Not sure about using "3rd" and "4th" though - it's a bit
>> tightly coupled to the English language and possibly prone to error.
>> Wouldn't "3rail" and "4rail" fit the bill? 
>> 
>> Actually, as electrified=rail is so widely used at present, how about
>> making that explicitly "3rd rail" and introducing a new value for the
>> 4-rail system?
> 
> I am in favour of splitting "rail" into two new values for systems with
> a 3rd and a 4th rail (no matter how it is spelled exactly in the value).
> Currently all 3rd rail and 4th rail systems are tagged as "rail", aren't
> they? If we followed your suggestion, "rail" would mean "3rd rail or 4th
> rail system" and "4th rail" would mean "guaranteed 4th rail system".
> It's a bit like "yes" is a incomplete value for electrified=* which
> should be replaced by a more precise value like contact_line if one
> knows it.

It would have the heuristic advantage of already being right in almost
all cases, thus minimising the re-tagging effort. 4-rail systems are
quite rare actually, and well-localised. 

>> How would we indicate the voltage/frequency of the two rails
>> independently? On the London Underground it's mostly +420/-210 (these
>> days +500/-250) but there are some areas where +750/0 is used
>> (Richmond-Gunnersbury for example).
> 
> Is voltage=* used on that lines as the difference between positive and
> negative, i.e. voltage = 750 = 500 - (-250)?

Yes it is at present, giving no way of distinguishing between +500/-250
and +750/0. The reason for using +750/0 is that the track is shared
between 3-rail and 4-rail trains, both operating at 750V. Normal
"Underground" track electrified at +500/-250 would only give 500V to
these trains, and the running rails are not intended to carry the return
current. The track signalling would probably get upset. So this
distinction is necessary to show (in)compatibility between sorts of
trains. 

An obvious (but probably controversial) candidate would be
voltage=500;-250 - How about voltage:outer=500, voltage:centre=-250? 

>> While we are at it, could we take the opportunity to find a way to
>> represent three-phase dual-overhead systems (Switzerland etc) as well?
> For readers being confused: Gornergratbahn in Zermatt uses it.
> https://en.wikipedia.org/wiki/Gornergrat_Railway

And indeed the Jungfrau. It is currently tagged as voltage=1125,
frequency=50, electrified=contact_line which is correct but incomplete. 

We are missing two characteristics here. Firstly that there are two
overhead wires instead of one, and secondly that the power supply is
3-phase instead of single-phase. 

Might I also mention that we don't have a "clean" way of tagging for
dual electrification? I know of plenty of cases of 3rd-rail DC combined
with a overhead line, sometimes for transitioning from one system to the
other, and sometimes to accommodate different stock on the same lines
such as heavy rail on overhead power and metro on 3rd rail.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail

[Colin Smale]

Great idea. Not sure about using "3rd" and "4th" though - it's a bit
tightly coupled to the English language and possibly prone to error.
Wouldn't "3rail" and "4rail" fit the bill? 

Actually, as electrified=rail is so widely used at present, how about
making that explicitly "3rd rail" and introducing a new value for the
4-rail system?

How would we indicate the voltage/frequency of the two rails
independently? On the London Underground it's mostly +420/-210 (these
days +500/-250) but there are some areas where +750/0 is used
(Richmond-Gunnersbury for example). 

While we are at it, could we take the opportunity to find a way to
represent three-phase dual-overhead systems (Switzerland etc) as well? 

Colin 

On 2020-06-09 10:13, Garry Keenor wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/3rd_and_4th_rail  
> 
> Definition: A track electrified with a 4th rail system, with two additional 
> rails on insulators and two shoe pickup by the train, and traction current 
> returning via one of the insulated rails  
> 
> best regards, 
> 
> Garry 
> ___
> 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] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-06-01 15:05, Kevin Kenny wrote:

> On Mon, Jun 1, 2020 at 5:49 AM Colin Smale  wrote: 
> 
>> IIRC Indian Reservations can, and do, cross state boundaries, in which case 
>> they don't fit in this hierarchy. Or am I wrong here?
> 
> Some do. The only one of New York's that crosses the state line is
> Akwesasne, which is not recognized as a unified entity by any
> government but its own. (The Federal government calls the portion in
> New York the 'Saint Regis Indian Reservation'.) The hierarchical point
> is that every point in the state is in exactly one City, Town or
> Indian Reservation and no City or Town claims an Indian Reservation as
> part of its domain.  No Town crosses a county line, and the instances
> where a City or Indian Reservation does can be counted on the fingers
> of one hand.

I just looked on Wikipedia, and 24 out of 326 Indian Reservations cross
state boundaries. Of those, most are split between 2 states, but there
are four reservations that bridge three states. 

Wikipedia also says: "An Indian reservation is a legal designation for
an area of land managed [1] by a federally recognized Indian tribe [2]
under the U.S. Bureau of Indian Affairs [3] rather than the state
governments of the United States [4] in which they are physically
located" which supports my position that they are not part of the normal
administrative hierarchy of USA-state-county-city/town where each entity
at a lower level is part of exactly one entity at higher levels. 

In your example (St Regis) it seems Akwesasne actually crosses the
national boundary into Canada as well! 

  

Links:
--
[1] https://en.wikipedia.org/wiki/Land_tenure
[2] https://en.wikipedia.org/wiki/Tribe_(Native_American)
[3] https://en.wikipedia.org/wiki/Bureau_of_Indian_Affairs
[4] https://en.wikipedia.org/wiki/State_governments_of_the_United_States___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-06-01 02:49, Kevin Kenny wrote:

> I don't map special-purpose administrative districts, of which New
> York has a whole menagerie. I don't object if others do, but don't try
> to fit them into the boundary=administrative hierarchy.  They don't
> go. In New York, the admin_levels are as tabulated on the Wiki: 2=US
> 4=NY 5=New York City (don't ask!) 6=county 7=city, town, Indian
> Reservation

IIRC Indian Reservations can, and do, cross state boundaries, in which
case they don't fit in this hierarchy. Or am I wrong here?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-06-01 08:14, Kovoschiz wrote:

>> would instead be distinguished by additional tags e.g.
> `boundary=administrative + administrative=police`
> 
> New `boundary=*` relations (there are a lot of values
> https://taginfo.openstreetmap.org/keys/boundary#values) could be proposed
> for these purposes if warranted. Don't adopt `boundary=administrative` for
> these other uses.

+1 otherwise it devalues the semantics of "administrative" if it is used
for a wide variety of things.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-29 15:46, Kevin Kenny wrote:

> On Fri, May 29, 2020 at 6:32 AM Colin Smale  wrote: 
> 
>> In the UK (especially Scotland) land ownership is pretty absolute. Every bit 
>> of land is owned by someone, even if that owner is The Crown. The owner has 
>> an absolute right to determine who has right of access, except for certain 
>> cases, like a Public Footpath or designated open access land that falls 
>> under the "right to roam" legislation. A person's house and driveway does 
>> not fall under these exceptions, so there is no right of access, except with 
>> the landowner's permission. So here we have "access=private". That does not 
>> mean you cannot knock on the door, or deliver a parcel however; whether by 
>> so doing you are committing civil trespass is not a priori clear - it 
>> depends on the circumstances; modelling all these circumstances in OSM is an 
>> enormous challenge that I don't think we are looking to solve here.
>> 
>> Despite private ownership, the exceptions I mentioned (public highway, open 
>> access) are "access=public" AKA "access=yes". It is illegal to prevent 
>> access.
>> 
>> Of course there are rules and limitations in all cases as to the type of 
>> access: public footpaths are deemed to be ±1m wide and access is only 
>> granted to pedestrians, not to motor vehicles for example.
>> 
>> I believe that there is a defence to trespass on the grounds of "custom"
>> which IMHO would cover deliveries to your door, or someone needing
>> emergency help, or door-to-door salesmen (all in the absence of explicit
>> signing to the contrary of course).
> 
> _Mens rea_, at least in most of the US, is an element of criminal
> trespass, and the liability for the civil tort of trespass is limited
> to actual damages in most cases. Since most of the key definitions in
> this part of the Common Law were established before our legal systems
> diverged, I imagine that is so in the UK as well. If you haven't
> damaged property by your unauthorized presence, and you haven't been
> told that land is private or invaded the curtilage of a dwelling, the
> owner has no cause of action. In effect, all they can do is to demand
> that you leave; the cause of action doesn't arise until you fail to
> comply.

In the UK it is apparently not required to demonstrate actual damage: 
https://www.inbrief.co.uk/land-law/trespass/ 

You might like to peruse this document, which is an explainer for
members of parliament: 
https://researchbriefings.files.parliament.uk/documents/SN05116/SN05116.pdf


If any actual damage is done however, then the damage itself may
constitute a criminal offence ("Criminal Damage"). 

As trespass is a civil tort the police won't turn out to help. You (the
landowner) will have to take the trespasser to court, which is an
inalienable right. The question is then, how will the magistrate think?
What makes a valid claim, and what is a valid defence? As it is not a
criminal case, I am not sure if mens rea comes into it. But the "intent"
will definitely influence the court. As they say, ignorance [of the law]
is no excuse; so pleading that you did not realise it was private
property or that you were not allowed to be there will not help,
possibly unless you claim that you has misread the boundary on a map,
for example. Walking across what is clearly someone's garden and then
claiming you thought it was open-access land is not going to get you
anywhere, I suspect.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-29 14:02, Martin Koppenhoefer wrote:

>> On 29. May 2020, at 12:57, Colin Smale  wrote:
>> 
>> Sorry, I think I had a different photo in mind. It's pretty clear that the 
>> footway is associated with the road, so if you have access to the road, you 
>> can walk on that footway.
> 
> I cannot see this. To me there is a sequence road, lawn, footway, identical 
> lawn, house, and no indication where a potential boundary between private and 
> public would be located. I'm pretty sure the building is private though ;-)
> 
>> But between the footway and the house you have to assume it is associated 
>> with the house,
> 
> do you? Because this is the "typical" situation, or are there more hints?

We only have the photo to go on. It is my assumption that the footway
follows the road, past multiple properties, and that it is intended for
pedestrians to pass along parallel with the road. It's only an
assumption, but it sounds like the most likely scenario to me. Do you
think it would be OK for you to walk over the grass towards the house
without good reason like an intention to ring the bell? If it were my
garden you had better watch out. 

> You have to assume you have no right to be anywhere, unless you have reason 
> to believe you are allowed. That's the law (in England and NL at least). 
> that's a sad law, in Germany it's the opposite: you may assume you can be 
> everywhere unless you have reason to believe it is forbidden.

Are you referring to Jedermannsrecht? From wikipedia I get the
impression that that applies to open countryside and would correspond to
"open access areas" in England. Do you have reason to believe somebody's
front garden is forbidden? To me that's a no-brainer. 

Maybe this is a symptom of a cultural difference. To a Brit like me, "an
Englishman's home is his castle" is how we are brought up.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-29 13:27, Paul Allen wrote:

> On Fri, 29 May 2020 at 11:32, Colin Smale  wrote:

> [lengthy snip] 
> 
>> You refer to a specific case - "when visiting the house". It would be 
>> unlawful if you were just out for a stroll, without the intention of 
>> visiting the house. Access=permissive would imply that it would be OK to 
>> walk up the driveway to have a look around the garden, and that is not the 
>> case.
> I feel that access=permissive is not entirely useful for driveways.  How 
> do you get permission?  Is it legally acceptable to walk along the driveway 
> to the house to ask permission to walk along the driveway to the house in 
> order to talk to the householder about something?  It all gets a bit 
> recursive.

Indeed, access=permissive makes no sense for a private driveway.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-29 12:38, Martin Koppenhoefer wrote:

> Am Fr., 29. Mai 2020 um 12:32 Uhr schrieb Colin Smale 
> : 
> 
> On 2020-05-29 08:29, Arne Johannessen wrote: 
> 
> Here's an example for such a situation:
> (9)  https://en.wikipedia.org/wiki/File:Big_single-family_home_2.jpg
> 
> I expect this driveway is on private property. But I see nothing supporting 
> the use of the access=private tag here. 
> You are not allowed to enter it without a valid reason. That's private. Just 
> because the gate is open does not give you the right to enter.

Which gate? I do not see any gate, nor fence, nor does it seem clear
where the private property begins. (No signs either). 

Sorry, I think I had a different photo in mind. It's pretty clear that
the footway is associated with the road, so if you have access to the
road, you can walk on that footway. But between the footway and the
house you have to assume it is associated with the house, and you have
no right to walk on the grass or walk on the driveway, although there
are legitimate reasons to do so. Depending on the jurisdiction, the
landowner may be able to bring a case against you. It's access=private.
You have to assume you have no right to be anywhere, unless you have
reason to believe you are allowed. That's the law (in England and NL at
least). But that doesn't mean you can never enter, just that you need a
"qualifying reason" to do so.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-29 08:29, Arne Johannessen wrote:

> Colin Smale wrote: 
> 
>> [...] So it would sound reasonable to me that, if your
>> letterbox is in your front door, you accept that the postman can pass
>> over your land to fulfil his legal duty.
> 
> Sure. But access=private has nothing to do with private ownership. See below.

They are different, but related. 

In the UK (especially Scotland) land ownership is pretty absolute. Every
bit of land is owned by someone, even if that owner is The Crown. The
owner has an absolute right to determine who has right of access, except
for certain cases, like a Public Footpath or designated open access land
that falls under the "right to roam" legislation. A person's house and
driveway does not fall under these exceptions, so there is no right of
access, except with the landowner's permission. So here we have
"access=private". That does not mean you cannot knock on the door, or
deliver a parcel however; whether by so doing you are committing civil
trespass is not a priori clear - it depends on the circumstances;
modelling all these circumstances in OSM is an enormous challenge that I
don't think we are looking to solve here. 

Despite private ownership, the exceptions I mentioned (public highway,
open access) are "access=public" AKA "access=yes". It is illegal to
prevent access. 

Of course there are rules and limitations in all cases as to the type of
access: public footpaths are deemed to be ±1m wide and access is only
granted to pedestrians, not to motor vehicles for example. 

> I believe that there is a defence to trespass on the grounds of "custom"
> which IMHO would cover deliveries to your door, or someone needing
> emergency help, or door-to-door salesmen (all in the absence of explicit
> signing to the contrary of course). 
> 
> Well, explicit signing like "keep out" is what's currently being discussed.
> 
> Or places that may be unsigned, but still make it clear that by entering 
> without permission, you break the law and may have to answer for it. Think of 
> a closed gate or something like that; the details of what's lawful and what 
> isn't vary by jurisdiction.
> 
> That's what access=private is being used for.

Of course definitions can vary by jurisdiction. In UK/NL (countries that
I happen to know well), even if the gate is open your presence on the
land may be unlawful, depending on your intent (but that doesn't mean
you can be prosecuted for anything). But a "keep out" sign does not
override legal right of access. The sign itself may not be legally
posted. Does the sign apply to a point ("forbidden to pass this sign"),
or to an area? What is the extent of the area? I have never seen an "end
of keep out" sign. 

> On 2020-05-28 02:36, Arne Johannessen wrote:
> For example, here are a few images of "keep out" signs. Now think of somebody 
> making a package delivery. How are they supposed to determine whether 
> "implicit" permission exists in their individual case or not? Is it different 
> for some of these signs, or are they all the same in this regard?
> I expect a "keep out" sign would probably override implicit permission?
> Agreed.
> 
> Mateusz changed the wiki to say different. Clearly, consensus does not 
> currently exist to support that change.
> 
> BTW, let me point out that choosing not to take legal action is not the same 
> thing as giving permission.
> And assuming that no one will take legal action is not the same thing has 
> having received permission.
> Which is exactly why a driveway is access=private. Maybe a delivery
> driver doesn't have "permission" as such, but he may have a reasonable
> justification to use your driveway.
> I think you're confusing access=private with ownership=private here.
> 
> This is an example of a typical access=private driveway:
> (8)  https://4.imimg.com/data4/OR/NG/MY-11485274/ms-gate-500x500.jpg
> 
> Note the strong gate and the intercom on the right pillar, which could be 
> used to obtain permission to enter. A delivery driver would probably be 
> expected to use that intercom, even if the gate happened to be open (again, 
> the actual legality may vary by jurisdiction).
> 
> Most driveways have less imposing access restrictions in place. Many have no 
> physical barriers or signs at all. They're still private ground, but with 
> nothing to indicate restrictions to a visitor, it would not be unlawful to 
> enter the driveway when visiting the house. Therefore, such driveways are 
> _not_ access=private; perhaps they are access=destination or 
> access=permissive, but as Flo pointed out, adding these tags to driveways in 
> OSM isn't very useful.

You refer to a specific case - "when 

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

Hi Arne, 

On 2020-05-28 02:36, Arne Johannessen wrote:

> Colin Smale  wrote: 
> 
>> In the UK simple trespass to land is not illegal, it is for the landowner to 
>> claim under civil law: "unjustifiable interference with land which is in the 
>> immediate and exclusive possession of another". What constitutes 
>> "unjustifiable" is the key here. Delivering a package would sound like 
>> justification to me (IANAL).
> 
> According to Wikipedia: "Justification by law refers to those situations in 
> which there is statutory authority permitting a person to go onto land, such 
> as the Police and Criminal Evidence Act 1984, which allows the police to 
> enter land for the purposes of carrying out an arrest."
> 
> https://en.wikipedia.org/wiki/Trespass_in_English_law#Defences_2
> 
> This seems to mean that there would need to be a law specifically allowing 
> access for package deliveries in order for that to be "justified". I'm 
> assuming such a law doesn't exist in the UK (but you're most welcome to 
> correct me).

The UK is a common-law system, so there is a lot of stuff that is not
explicitly covered by statutes, just by case history through the years
full of concepts like "reasonableness." 

Well, the postal service has an obligation to deliver to every address,
and has standards for the letter box and its accessibility. As a
householder, if you want to receive letters, you need to have a
compliant letterbox. So it would sound reasonable to me that, if your
letterbox is in your front door, you accept that the postman can pass
over your land to fulfil his legal duty. Parcels are different as they
are not part of the Universal Service Obligations. 

I believe that there is a defence to trespass on the grounds of "custom"
which IMHO would cover deliveries to your door, or someone needing
emergency help, or door-to-door salesmen (all in the absence of explicit
signing to the contrary of course). 

Google told me that the United States Postal Service does not deliver on
private land, which would explain why they have their mailboxes at the
side of the road and not at their front door. 

>> I disagree that permission needs to be explicit for access=private.
> 
> Okay. Can you explain, specifically, how "implicit" permissions are supposed 
> to work?

With hindsight, what I called "implicit permission" might better be
termed "reasonable excuse" 

> For example, here are a few images of "keep out" signs. Now think of somebody 
> making a package delivery. How are they supposed to determine whether 
> "implicit" permission exists in their individual case or not? Is it different 
> for some of these signs, or are they all the same in this regard?

I expect a "keep out" sign would probably override implicit permission? 

Implicit permission would be covered by "custom" and "reasonableness" -
if you actually tried to sue a delivery driver for trespass the case
would be thrown out of court, unless you had some kind of sign, barrier
etc showing that you forbid what in most cases is a normal activity. 

> BTW, let me point out that choosing not to take legal action is not the same 
> thing as giving permission.
> And assuming that no one will take legal action is not the same thing has 
> having received permission.

Which is exactly why a driveway is access=private. Maybe a delivery
driver doesn't have "permission" as such, but he may have a reasonable
justification to use your driveway.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-27 08:17, Arne Johannessen wrote:

> Mateusz Konieczny via Tagging  wrote: May 26, 
> 2020, 08:28 by a...@thaw.de: Mateusz Konieczny via Tagging 
>  wrote: 
> Maybe it can be argued that there is implicit permission for delivery 
> services?
> My uncle has farm, with clearly private yard (it is unsigned).
> 
> Postman or package delivery would be welcomed there and - even if package 
> would not be requested, but random person driving to
> front of his house would not be and AFAIK would violate law. 
> I think what you're describing is access=destination, not =private.

Why? 
I interpreted "random person" as meaning "random traffic, not destined
for your uncle's residence".

But perhaps you meant that the person is in fact a visitor destined for
your uncle's residence - maybe trying to sell something or conducting a
poll or whatever - and that doing so would be illegal? If so, in what
way is it "clear" to the visitor that what they're doing is illegal? 
It wouldn't be illegal, it might be unlawful, which is a slightly
different concept. If it went to court, I am sure the judge would
consider whether the visitor had "reasonable grounds" to go to the door.
Door-to-door selling (assuming that activity is permitted in general)
would probably be "reasonable grounds", unless your uncle had put up a
sign like "no salesmen." But then again, if the visitor rang the bell at
4 in the morning, he had better have a good story. 

In the UK simple trespass to land is not illegal, it is for the
landowner to claim under civil law: "unjustifiable interference with
land which is in the immediate and exclusive possession of another".
What constitutes "unjustifiable" is the key here. Delivering a package
would sound like justification to me (IANAL). 

>> "access=destination" means "no transit traffic, no other restrictions".
> 
> Not quite. access=destination means "traffic for a particular destination 
> only". When used on a residential driveway, the destination would be the 
> residence itself (or perhaps a garage attached to it). 
> 
> access=private means even traffic destined for that residence is disallowed, 
> including both salesmen and postmen.

But it is allowed with implicit/explicit permission... 

> access=permissive means any traffic is allowed (e. g. random kids racing 
> their motor scooters).

...but that permission/tolerance on the part of the landowner can be
withdrawn at any time - your right to use that highway is not set in
law, it is permitted by the landowner for the time being. 

Actually one could claim that motorways and other "special roads" in the
UK might actually come into this category - they are explicitly not
public highways. 

> At least that's how I see it. I know not everyone agrees, and I'm not sure if 
> that's due to misunderstanding (possibly on my part?) or due to lack of 
> consensus.
> 
> What changes nothing for a typical driveway.
> Depends on the area I guess. But yes, I would say that to me, 
> access=destination does seem like a sensible default value for driveways in 
> OSM.
> 
> [access=private wiki page]
> 
> It also doesn't make a clear enough distinction between private ownership and 
> private access (by using the term "private" colloqiually and by showing a 
> picture of what looks like an ownership=private situation).Changed a bit in
> https://wiki.openstreetmap.org/w/index.php?title=Tag:access%3Dprivate=1995183=1986562
> Yes, that's slightly better.
> 
> I think the =private wiki page could be improved by clarifying that =private 
> really does require _explicit_ prior permission.I added "Permission may be 
> implicit, for example delivering a package into a house."
> on Key:Access and Tag:access=private pages, as it appears to match the actual 
> usage.
> I disagree with this edit for the reasons explained at some length in my 
> previous message.

I disagree that permission needs to be explicit for access=private. You
need permission, that's all. And that permission is in the exclusive
gift of the landowner (or their delegate). However with
access=permissive you may assume that permission is granted, whereas
with access=private permission is not granted by default (you need to
ascertain that you have permission, be it explicit or implicit). 

> Also: Can you explain how one would _implicitly_ arrange permission on an 
> _individual_ basis?

You don't need to arrange "implicit" permission. If you did, it would
become "explicit" permission.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Change of wiki page Key:access

[Colin Smale]

On 2020-05-26 19:31, Mateusz Konieczny via Tagging wrote:

> May 26, 2020, 19:19 by f...@zz.de: 
> On Tue, May 26, 2020 at 06:46:11PM +0200, Mateusz Konieczny via Tagging 
> wrote: 
> May 26, 2020, 18:04 by fernando.treb...@gmail.com: 
> 
>> Bikes may "pass" in two different ways: riding 
>> (bicycle=yes/permissive/destination) or pushing (bicycle=dismount). 
>> Bikes are only completely forbidden if bicycle=no/private. 
>> 
> bicycle=no does not mean that you cannot push bicycle 
> bicycle=no and bicycle=dismount are de facto equivalents 
> we have no widely used tag to indicate "walking with bicycle is illegal here" 
> 
> Is it that in every jurisdication a cyclist pushing his bike is 
> considered a pedestrian?

Sometimes pushing bicycles is explicitly forbidden. 

It is highly conceivable that some rules, in some territories, apply to
the bike as a vehicle, whereas others apply to the activity. Spot the
difference between "no cycles" and "no cycling". If the rule says "no
cycles", I guess that means you can't push it either. 

Is it allowed to push a bicycle through a red traffic light, or the
wrong way down a one-way street? You are not cycling, but it is still a
vehicle. In the UK the law applies to "vehicular traffic" including
someone who is "driving or propelling a vehicle" and fines have been
issued...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] any valid usage of admin_level=1 ?

[Colin Smale]

On 2020-05-25 14:58, Marc M. wrote:

> Hello,
> 
> following a small thread on irc, I have review 20 usage of admin_level=1
> all are mistakes, often by new mapper
> for ex https://www.openstreetmap.org/way/779838275
> is there a case of real use of admin_level=1?
> wiki only said that UE isn't a admin_level=1
> but don't list any valid usage of it
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
> https://overpass-turbo.eu/s/Umf
> 
> are these all errors or is there an undocumented usecase ?

I think the European Union is a good candidate for admin_level=1. It has
all the attributes of an administration, including elected
representatives and (in some cases) directly effective laws. It may be
unique in the world, but that doesn't change the duck-test outcome.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Colin Smale]

On 2020-05-25 10:39, Florian Lohoff wrote:

> On Mon, May 25, 2020 at 01:48:20AM +0200, Mateusz Konieczny via Tagging 
> wrote: 
> 
>> Wrong tagging is not interesting by itself.
>> 
>> I was looking for real-world situation where 
>> 
>> (1) there is some seemingly good overcomplicated tagging
>> (2) there is a good and simpler replacement
> 
> The classic case is that people to not use "vehicle" or "motor_vehicle"
> but tag all individual subtypes individually, sometimes even
> with their parent.
> 
> So there is no need for
> 
> motorcycle=destination
> goods=destination
> hgv=destination
> car=destination
> mofa=destination
> 
> When there is a "motor_vehicle=destination"

Is there a uniform definition of "motor_vehicle" in terms of its
constituent vehicle classes? Do the constituent classes also have a
uniform definition? A problematic example is "psv" where its status is
not simply a function of the vehicle's construction or taxation class,
but also of the use to which it is being put. If a taxi driver takes his
taxi on holiday? A bus running empty back to the depot? This is going to
depend on the specific jurisdiction. How we word the definition of the
OSM tag is of major importance if we are to avoid endless arguments
about these edge cases. 

Interesting fact: in NL, speed limits don't apply to cyclists, because
the law says that speed limits are for motor vehicles. Is an eBike a
"motor vehicle"? Do we need "maxspeed:cycle=none"? BTW this is
rhetorical - just mentioning it here to illustrate how easily we can
project our own bit of the world onto the whole planet and assume it's
the same for everyone.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 07:03, Joseph Eisenberg wrote:

> This was originally sent to the Talk mailing list, but it is better if it is 
> discussed on the Tagging mailing list: 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> I agree that razed, completely demolished railways, where all traces of the 
> former track-bed have been removed, should be removed from OpenStreetMap. 
> 
> It is still considered acceptable to map abandoned railways, where the old 
> railway grade remains, even though the metal rails have been removed.  
> 
> However, note that there are some people who are very committed to mapping 
> historical and abandoned railways, so there may be resistance to removing 
> these features.

1. Live and let live - OSM has always been a broad church. It might not
be your hobby, but it is their's. The bar to actively deleting other
people's work should be set very high indeed. 

2. In the present, it IS a former trackbed, even if you can't see it. In
the past it was an active rail line. 

3. In terms of database bloat, abandoned/razed rails have a completely
insignificant impact. 

4. Downstream consumers/renderers have always been able to ignore things
as they see fit, they can quite easily ignore razed tracks as well.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-05-14 14:07, Paul Allen wrote:

> On Thu, 14 May 2020 at 12:58, Martin Koppenhoefer  
> wrote: 
> 
>>> On 14. May 2020, at 13:16, Paul Allen  wrote:
>>> 
>>> It makes it more difficult to the extent that a decision has to be made as 
>>> to
>>> whether we treat the NHS in the UK as a whole as admin level 1 or NHS Wales
>>> as admin level 1.  Or some other hierarchical arrangement.  Or not bother
>>> mapping it.
>> 
>> level 1 is improbable because level 2 is the national level.
> 
> Increment my numbers, then.

Anyway, getting back to the original subject... Should these NHS area
boundaries be tagged as "boundary=administrative" or something else like
"boundary=state_healthcare"? They are obviously used for some kind of
administration, but my vote would be for the latter.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-05-14 13:15, Paul Allen wrote:

> On Thu, 14 May 2020 at 11:21, Colin Smale  wrote: 
> 
> [Sub-divisions of health boards in Wales] 
> 
>> I am sure someone knows where the boundaries are.
> 
> Yes,  But that doesn't mean they're making the information public.  I had a 
> brief look around Hywel Dda's site and couldn't find even a statement that 
> they covered the three counties of Carmarthenshire, Ceredigion and 
> Pembrokeshire.  The only place I found a list of the sub-divisions was 
> on Wikipedia, but I couldn't see any pointer to the original source ofthose 
> lists.

This indicates that the health board boundaries are maintained by the
Welsh Government (i.e. not by NHS Wales): 
https://gov.wales/written-statement-health-board-boundary-change-bridgend


This shows that each Principal Area is covered by one health board 
http://esriuktechnicalsupportopendata-techsupportuk.opendata.arcgis.com/datasets/680c9b730655473787cb594f328a86fa_0?selectedAttributes%5B%5D=UA19CD=bar=table___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-05-14 11:49, Paul Allen wrote:

> On Thu, 14 May 2020 at 08:39, Colin Smale  wrote:
> 
>> In the UK there are multiple hierarchies of geographic areas, for widely 
>> differing purposes, that frequently (but not always and not necessarily) 
>> share borders. For example Police Regions are based on traditional counties 
>> (which are not "administrative")
> 
> By "traditional," do you mean the ceremonial counties (aka "lieutenancies") 
> and the Welsh preserved counties? 
> 
>> with lots of anomalies.
> 
> Yeah, like Police Scotland.  Or the Police Service of Northern Ireland. 
> Or the various forces in Wales, such as Dyfed Powys.  Dyfed was 
> formed by amalgamating Pembrokeshire, Carmarthenshire and 
> Cardiganshire, was later split back into its component parts 
> (Cardiganshire was renamed Ceredigion in that split), and Dyfed 
> is now a preserved county.

By anomaly I meant where the boundary deviates from the basic high-level
area boundary.  

> Then we have communities.  Which are the secular replacement for 
> parishes and in most cases parish councils have been replaced 
> by community councils, often with the same name.

Civil Parishes in England and Communities in Wales (in fact all
government admin areas) are legally defined as areas of land. The
associated council may or may not exist, and the council may or may not
be active. Council jurisdiction can span multiple such areas
(joint/grouped parish councils, also happens with Communities in Wales),
and a polygon can actually be common to two or more such areas (LCPs,
Lands Common to Parishes). Many areas in England are unparished, meaning
they are not part of any Civil Parish area. What a mess. Scotland and
Northern Ireland are of course different again... 

> And then there are health boards/NHS trusts.  These are devolved.  For 
> example, Hywel Dda University Health Board (Bwrdd Iechyd Prifysgol) 
> is part of NHS Wales (GIG Cymru).  The Welsh health boards are 
> divided into "network clusters", so Hywel Dda has Amman/Gwendraeth, 
> Llanelli, North Ceredigion, North Pembrokeshire, South Ceredigion, 
> South Pembrokeshire and Taf/Tywi.  Good luck trying to figure out 
> the boundaries of those.

I am sure someone knows where the boundaries are. Why should the fact
that health in Wales is a devolved responsibility make it any more
difficult?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Colin Smale]

On 2020-05-14 04:02, Andrew Harvey wrote:

> Agreed with Phake, any boundary that's used for administrative purposes could 
> be included, that's what I understand from 
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative. That 
> doesn't mean that each area needs to have it's own legal entity and 
> administrator, nor need to be able to set laws, rules, codes etc. just that 
> the boundary itself is used for some administrative purposes.

I would suggest a filter that the area needs to be formally defined,
possibly by some level of government. I agree that whether or not there
is any active form of local government is not a prerequisite. But we
need to draw the line somewhere If a group of neighbours got
together and said "our area is called Homesville" would that qualify? If
a company with a huge plant divided the campus into North, South, East
and West with Regional Managers, it is using the areas for
"administrative purposes" but I would not expect this to be reflected in
OSM as admin boundaries. 

As with everything in OSM it should be "independently verifiable" which
implies there should be some publicly accessible single source of truth,
i.e. the definition of the area is written down somewhere that Joe
Bloggs or I could access freely. 

In the UK there are multiple hierarchies of geographic areas, for widely
differing purposes, that frequently (but not always and not necessarily)
share borders. For example Police Regions are based on traditional
counties (which are not "administrative") with lots of anomalies. They
are subdivided into districts. Calling these areas
"boundary=administrative" instead of "boundary=police" would cause
confusion! 

The use of admin_level=* allows a proper hierarchy to be defined, but is
currently only used with boundary=administrative. If this concept is
extended into (for example) boundary=police, you enable a parallel
hierarchy, which reflects real life much better and keeps things clearer
for both mapper and user.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-13 10:20, Shawn K. Quinn wrote:

> On 5/12/20 17:18, Graeme Fitzpatrick wrote: 
> 
>> I'd really like somebody to come up with simple definitions of
>> 
>> mappers,
>> 
>> data consumers / customers,
>> 
>> users?
> 
> I'd consider "user" and "data consumer" to be the same thing (but would
> prefer "user" or even "data user" in light of the objection to
> "consumer" used in this context at
> ).
> 
> A "user" is someone who makes use of the data generated by the
> OpenStreetMap project including its volunteers.

I think we should be clear about the distinction between consumers of
the DATA (via APIs and downloads, in XML and PBF formats) and users of
the RESULTS of processing that data (map renderings, other applications
etc). Officially (unless it's changed) OSM is about the DATA, but many
issues with the data don't surface until someone sees the results. These
are two distinct user types or personas, each with their own list of
requirements/expectations. Let's recognise that and treat them
separately in this discussion.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Colin Smale]

On 2020-05-12 12:58, Paul Allen wrote:

> On Tue, 12 May 2020 at 11:43, Sören alias Valor Naram  
> wrote: 
> 
>> Hey,
>> 
>> I am a "data customer", see https://babykarte.OpenStreetMap.de . That's why 
>> I initiated this discussion because this is important for me. But mappers 
>> are not listening to data customers
> 
> Why do you think that other mappers are not data consumers? 
> 
>> and think they know how a database works (only few of them know that and 
>> those come from a technical field).
> 
> Why do you think they do not know these things?  And why do you think it 
> relevant?  Do you perhaps think that namespacing involves the creation 
> of a table for the namespace and that Codd's relational model applies to 
> namespaces?

Can someone come up with a metamodel description of the use of
namespacing? It would be interesting to apply it to the current set of
tags including a ":" character.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-08 18:01, Greg Troxel wrote:

> I think we now know that the existing datums don't differ much from WGS84 
> except Belgium, and given the EVRF2007 datum, it seems clear that Belgium now 
> will have that and the old one, differing by 2m.
> Hence the thing we need to know, we don't, in this case.

Depends how you define "much". According to this info on Wikipedia
(sorry that it is in Dutch), the French also have their own datum, which
is TAW-1.82m, which works out to NAP-0.50m. 

https://nl.wikipedia.org/wiki/Tweede_Algemene_Waterpassing 

A little light reading for Greg: "The transformation of GPS into NAP
heights: Combining NAP, GPS and geoid heights to compute a height
reference surface for the Netherlands" 
https://repository.tudelft.nl/islandora/object/uuid%3Ae661fcdd-6fe8-46e9-b5ea-51dabbd89175___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Voting procedures

[Colin Smale]

The subject of a vote should not be amendable. All the discussions,
debates, consideration of alternatives etc should be BEFORE the proposal
is put to the vote. If a vote fails, THEN the proposal might be amended
and submitted again - but this has to be subject to some time
constraints such as not less than 1 month after the previous vote to
stop people making a quick tweak and resubmitting it immediately. 

When is a proposal "ready for a vote," other than on a timer? How do you
measure or sense if the vote is likely to pass, i.e. a reasonable
consensus has been achieved? A quick check amongst a good sample of the
commenters perhaps? Are they happy that their concerns have now been
addressed? What about having a proposal reviewed for readiness, before a
vote can be announced? 

Which brings us back to the psyche of a "good tagging schema". What's
the difference between a tagging scheme, and a BETTER tagging scheme?
For example allowing flexibility to add details in the future, and
getting the balance right between world-wide standards and regional
variations. Other aspects like alignment with established standards,
both current OSM practise and internationally accepted norms, should
also be on the list. 

Too many comments, right down to the wire, are along the lines of "I
would do it this way..." or "in my country it works like this...". There
will be a period of this kind of exchange of course, but it should
followed by a convergence phase that has a concrete proposal on the
table, that may still undergo minor tweaks but no great changes of
direction. 

On 2020-05-08 18:06, Kevin Kenny wrote:

> On Fri, May 8, 2020 at 9:06 AM Phake Nick  wrote: 
> 
>> Given the proportion of opposing comment being raised, I would say "more 
>> than what have been discussed", as barely anyone raised the point during the 
>> discussion. The only two remotely relevant mentions about it during the 
>> discussion process was 1. one user who think there should be a new parents 
>> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
>> incorrectly assuned "motorcycle taxi" is a combination of two different 
>> features just because the term come with a space. That clearly indicate 
>> discussion was not sufficient and that the proposal should restart the 
>> discussion process.
> 
> Our 'yes/no' voting on proposals leads to a pathological phenomenon
> that I've seen happen several times.
> 
> Someone wants to map a particular feature, and floats an idea for a
> tag 'A' on the list.
> 
> Several other people counter-propose incompatible tags 'B', 'C', 'D' -
> each with its own advantages and disadvantages.
> 
> None of these tags garners a clear majority of commenters.
> 
> Either the proponent abandons the idea, or else falls back on 'any
> tags you like', or actually bites the bullet and makes a formal
> proposal, calling the vote.
> 
> In the last case, which is already uncommon, the vote fails, because,
> if for instance, 'B' becomes the final proposal, all of the supporters
> of 'A', 'C', 'D' vote against the proposal.
> 
> Any of the other schemes would also have been rejected.
> 
> Do we need to refine the system to something like: supermajority that
> the feature should be mapped, and preference voting for how to map it?
> 
> I will concede that I've never called for a vote on any proposal,
> because after testing the waters on this list, I've taken the cowardly
> option of falling back to 'any tags you like'. Even though there
> appears to be a consensus (recall that consensus is not unanimity!)
> that things like 'access=permit' or 'protection_class=*' are small
> steps in the right direction, there was clearly enough controversy
> over the details that it became obvious to me that a vote on either
> proposal would fail.
> 
> In many cases the failures truly are ones of metaphysical
> understanding. For a taxi service, is the vehicle (car, motorcycle,
> pedicab, rickshaw) the essence, and 'for hire' a mere accident, or is
> 'passenger service for hire' the essence, and the choice of vehicle
> the accident? In typical tagging discussions like this one, I often
> see several other attributes being proposed as essential, and the
> attempt to fit the entire world into a taxonomic tree fails because
> nobody can agree which attributes are generic and which are specific.
> That inevitably comes of using Platonic tagging to approximate an
> Aristotelian understanding of the objects being tagged. Tagging will
> always be approximate. The map is not the territory.
> 
> I have little sympathy for those who cannot be troubled to comment on
> a proposal in progress and then pop up with new objections after the
> vote is called. I consider that to be obstructionist behaviour. While
> it does not necessarily negate the technical value of the objection,
> it is annoying in the extreme. It can also serve as a presumptive (not
> determinative!) measure of the technical merit; people with a deep
> technical 

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-08 14:09, Greg Troxel wrote:

> Martin Koppenhoefer  writes:
> 
> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
> 
> 3) Look up the data sheet and mark it as ele:datum=NGVD29 or
> ele:datum=NAVD88 as it turns out. 
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish). 

As I mentioned before, the national datums of the Netherlands and
Belgium differ by over 2m, which for everything connected to water is
very significant. Waterways often form the border, with bridges that
cross the border. You cannot use a map/chart (at last for tidal waters)
if you don't know what datum it uses. 

In OSM we often leave out "obvious" annotations, giving rise to a kind
of "default" (such as maxspeed in km/h). But there is always a way of
making it explicit, for those who feel the need. In this case we may
agree to define "ele" as relative to the "local datum" or WGS84 or
whatever, but we must always provide a system for making that explicit,
and (preferably) a means to derive the intended basis for values that
are not explicitly qualified.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there any tagging scheme for carillons already?

[Colin Smale]

On 2020-05-06 17:28, Martin Koppenhoefer wrote:

> what are the requirements, do you require the sound coming from actual bells, 
> or would a recording of bells playing from loudspeakers qualify as well? 
> Midi-generated sounds?

Sorry to nit-pick, but Midi doesn't generate sounds, it commands
instruments to do that. I am pretty sure there are carillons that can be
programmed in some way to play automatically, whether that be through
Midi or punch-cards like street organs.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-04 09:10, Peter Elderson wrote:

> Thanks for explaining why my android phone says I am at +38m (+/- 3) in my 
> backyard when in fact it is at Dutch sea level -4.4m.

GPS receivers, including Android phones, should adjust the GPS WSG84
height to "sea level". But the vertical accuracy of GPS is much less
than the horizontal accuracy, and it needs more satellites in the fix to
give a decent altitude. I live pretty much at 0m NAP, and the altitude
it shows varies a lot, both above and below zero.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Colin Smale]

On 2020-05-03 13:05, Volker Schmidt wrote:

> Martin 
> I am not an expert, but it looks as if the Wiki page Key:ele [1] is not 
> up-to-date. 
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".  Hence 
> there should be no difference between WGS84 and EGM96 elevations. 
> 
> Also it would be helpful, f you could give examples of local elevation 
> systems which would need explicit tagging. 
> When I see an elevation value on the ground I do not see any reference to the 
> reference system, so I cannot know, as a mapper, what reference system is at 
> the base of the informaton that I find on the ground. In that respect the 
> proposal is not at all clear from a practical perspective.

I think most countries with a coastline commonly use "sea level" as the
vertical basis. The definition of "sea level" differs from country to
country of course. NL uses "NAP" (Normaal Amsterdams Peil; normal
Amsterdam level) whereas Belgium uses "TAW" (Tweede Algemene
Waterpassing; second general water-levelling) as its basis. The
difference is 2.33m, which might not be so important for the heights of
mountains but along the coast it is critical for the correct
understanding of water depths, tides etc. The Westerschelde estuary
flows through NL until just before it reaches Antwerp (Belgium). To
avoid expensive misunderstandings it is essential that all bathymetric
data, tidal data, bridge heights etc be very clearly labelled with their
datum. 

  

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:ele___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Colin Smale]

On 2020-04-05 21:16, Andy Townsend wrote:

> On 05/04/2020 16:36, Joseph Eisenberg wrote:Can someone confirm if 
> "urgent_care" makes sense in British English,
> rather than "walk-in" or something else?
> 
> I'm English, and I would not know what "urgent_care" meant. After reading the 
> wiki page, it is unclear whether refers to designated walk-in centres, or the 
> "accident" end of "accident and emergency", or any other healthcare providers 
> that offer non-appointment access?

More likely to be towards the "emergency" end of A I would think...
Just because something is caused by an accident, doesn't make it
life-threatening. "urgent care" sounds like something that couldn't wait
for your GP to open tomorrow morning.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Sorting waterway relations?

[Colin Smale]

On 2020-02-27 10:04, Mateusz Konieczny via Tagging wrote:

> 27 Feb 2020, 09:55 by colin.sm...@xs4all.nl: 
> 
>> If it was semantically important, we should be scanning for and flagging up 
>> waterways with out-of-order ways.The fact that we are not, shows that the 
>> ordering of the ways is not essential for a correct geometrical 
>> interpretationQED
> 
> This proof assumes that OSM validators 
> are completed and detecting all possible 
> semantic issues. 
> 
> This is not true, just look at 
> JOSM/osmose/iD issue tracker, every 
> one has plenty of open issues suggesting 
> new validator checks.

I'm sure there are thousands of ideas for validators. But this one has
apparently never been thought important enough - if it is indeed buried
in the issue trackers somewhere. Anyway, the validators should ideally
follow the agreed rules, not create them. 

>> it is possible that re-ordering the members of one relation, causes the 
>> members of another relation to become out-of-order.
> 
> Why reordering members in one relation would 
> reorder members of other relation?

You are right, I retract this statement. Sorry, I hadn't thought it
through and was thinking of the order of the nodes in a way.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Sorting waterway relations?

[Colin Smale]

On 2020-02-27 01:47, Joseph Eisenberg wrote:

> When you make or sort a relation of type=waterway, do you check if the
> source or mouth of the river is first on the list of ways?
> 
> Another user just suggested that the spring/source of the waterway
> should start the list, then the mouth of the river at the ocean (or
> where it empties into a larger waterway) should be last. This practice
> has not been followed in the areas where I have mapped.
> 
> https://wiki.openstreetmap.org/wiki/Talk:Relation:waterway#Sort_order.3F
> 
> Is this done in your area?

In general there is no real need to sort the members as the geometry can
be reconstructed by chaining the end nodes. If it was semantically
important, we should be scanning for and flagging up waterways with
out-of-order ways. The fact that we are not, shows that the ordering of
the ways is not essential for a correct geometrical
interpretationQED 

As a consequence of some mappers desire to share ways between relations
of unrelated types (e.g. waterway and admin boundary) it is possible
that re-ordering the members of one relation, causes the members of
another relation to become out-of-order. If we all use separate ways
with shared nodes, the relations can be re-ordered without causing
collateral damage. 

It is accepted that a way has a direction, which is sometimes
semantically significant (water flow direction, one-way streets etc) and
sometimes not. Getting the ways into a particular order is of course a
different subject to pointing the way in the right direction. Once again
I appeal to mappers to use separate ways (with shared nodes) for
different concepts, even if they are co-linear, to allow for the
direction of the ways to mean different things in different contexts.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] admin_level on ways

[Colin Smale]

On 2020-01-27 13:59, Martin Koppenhoefer wrote:

> Am Mo., 27. Jan. 2020 um 13:11 Uhr schrieb Colin Smale 
> : 
> 
>> OSM clearly associates coastline with high water: 
>> https://wiki.openstreetmap.org/wiki/Coastline 
>> 
>> If the admin boundaries are very close, or even coincident with high water, 
>> I would expect two ways in OSM, possibly overlaying each other, possibly 
>> sharing nodes. Whether they should actually share nodes is another 
>> discussion; the coincidence of coastline and admin boundary is not by 
>> design, but a consequence of our lack of accurate data. That would suggest 
>> they should not share nodes, so they can be updated independent of each 
>> other.
> 
>> What does Italian law say about local government jurisdiction over the 
>> foreshore, between high water and low water? What about around estuaries, 
>> does the admin boundary follow the coastline up to the tidal limit? Do 
>> planning laws apply, for example? I understand the largest tides in the Med 
>> are on the African side, up to 2m. Depending on the slope of the shore, that 
>> could give a substantial area of foreshore.
> 
> Actually I have just found a text which states that in the part of the land 
> closest to the sea the municipalities are now "having important 
> administrative functions", while until some years ago this area was 
> exclusively under national control. So with the "recent" reforms, while this 
> area (including beaches and beach resorts, marinas), still belongs to the 
> state (ownership), it is now managed by the municipalities. The division 
> between national property and other (public and private) property can be seen 
> in the IT system S.I.D. ;-) 
> The competence of the Municipality extends also on the territorial sea (12Nm) 
> when there aren't primary national interests standing against it. 
> 
> Basically, if I have understood it correctly, the state has given competences 
> to the Regions, which have mostly transfered them to the Municipalities and 
> some to the Provinces, but reserve some planning and controlling competences. 
> 
> The Provinces may depend on the legislation of the Regions, e.g. in Toscana 
> they have to plan, realize and maintain structures to protect the coast and 
> the coastal population. 
> They may also authorize earthworks in the coastal area and placement of 
> cables and ducts in the sea. 
> 
> taken from a municipal webpage: 
> http://www.comune.livorno.it/urbanistica-territorio/demanio/demanio-marittimo 
> http://www.comune.livorno.it/demanio-marittimo/riparto-delle-competenze-stato-ed-enti-locali/competenze-dello-stato
>  
> http://www.comune.livorno.it/demanio-marittimo/riparto-delle-competenze-stato-ed-enti-locali/demanio-marittimo-pianificazione
>  
> 
> You should find other relevant information also here 
> Titolo II, Capo 1, del Codice della Navigazione (R.D. 30.3.1942 n° 327) and 
> the connected 
> Regolamento di Esecuzione (D.P.R. 15.2.1952 n° 328). 
> legge  n° 494/'93 art. 6   about "piani di utilizzo del demanio marittimo" 
> 
> TL;DR; 
> It seems, ownership (domain) remains at the national level, but there are 
> come competences given to regions, provinces and municipalities, which seem 
> to extend into the 12Nm territorial waters. 
> 
> I am sending this now because I cannot invest more time, but I am aware it is 
> not in a complete state ;-)

Thanks, it's already a mine of information! Which supports the premise
that the admin boundaries do not (blindly) follow the coastline / high
water mark.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] admin_level on ways

[Colin Smale]

On 2020-01-27 12:43, Martin Koppenhoefer wrote:

> Am Mo., 27. Jan. 2020 um 11:21 Uhr schrieb Colin Smale 
> :
> 
>> However, practically this leeds to ambiguous situations, where for example 
>> admin_level=4 is added to islands and might be misinterpreted as 
>> administrative "standalone" level 4 entities (with the island name etc.). 
>> While a clear separation of administration and coastline could solve this, 
>> it would still mean continuous additional maintenance effort due to 
>> duplication of already present information.
> 
> I would like to take this opportunity to point out that admin boundaries and 
> coastline are conceptually and geographically distinct, and should almost 
> never coincide. Admin boundaries are typically at the low-water mark, and 
> sometimes miles off shore, whereas the coastline is defined as the high-water 
> line. 
> 
> While I am aware of this, it is not something that is actually reflected in 
> OSM (at least in my area) and is not something I believe we can realistically 
> distinguish (it may be different where high and low tide are significantly 
> different, but if they are very close, as is the case in the mediterranean, 
> it is hard to map). I would not want to request to be able to distinguish 
> high and low water in order to be able to map administrative boundaries 
> (although if you do use different geometry, it is of course fine).

OSM clearly associates coastline with high water:
https://wiki.openstreetmap.org/wiki/Coastline 

If the admin boundaries are very close, or even coincident with high
water, I would expect two ways in OSM, possibly overlaying each other,
possibly sharing nodes. Whether they should actually share nodes is
another discussion; the coincidence of coastline and admin boundary is
not by design, but a consequence of our lack of accurate data. That
would suggest they should not share nodes, so they can be updated
independent of each other. 

What does Italian law say about local government jurisdiction over the
foreshore, between high water and low water? What about around
estuaries, does the admin boundary follow the coastline up to the tidal
limit? Do planning laws apply, for example? I understand the largest
tides in the Med are on the African side, up to 2m. Depending on the
slope of the shore, that could give a substantial area of foreshore.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] admin_level on ways

[Colin Smale]

On 2020-01-27 10:43, Martin Koppenhoefer wrote:

> I wonder what is the current state of admin_level on ways, in particular with 
> respect to osm-carto. Historically, the recommendation was to add the lowest 
> admin_level additionally to the ways that are part of admin relations (to 
> help applications that render boundaries based on ways, for examples 
> eliminates the need of "flattening" overlapping boundaries in case you would 
> want to use non-continuous line styles).

Another related issue is the hierarchy or precedence of types of
boundaries; where an admin boundary is also the boundary of a national
park, or a political area for example. What do you put in boundary=* on
the way? I always put something in there, so my usual editor for
boundary stuff (Potlatch2!!!) shows a distinctive line, instead of a
narrow black line which is also used for millions of other types of way
like barrier=*. Admin_level is only defined for boundary=administrative,
so if the way was tagged as boundary=political then admin_level=* might
be flagged as a potential error. Hence I give boundary=administrative
the highest priority on the ways. 

> However, practically this leeds to ambiguous situations, where for example 
> admin_level=4 is added to islands and might be misinterpreted as 
> administrative "standalone" level 4 entities (with the island name etc.). 
> While a clear separation of administration and coastline could solve this, it 
> would still mean continuous additional maintenance effort due to duplication 
> of already present information.

I would like to take this opportunity to point out that admin boundaries
and coastline are conceptually and geographically distinct, and should
almost never coincide. Admin boundaries are typically at the low-water
mark, and sometimes miles off shore, whereas the coastline is defined as
the high-water line. I know there are different variants of "high water"
and "low water", but they are irrelevant here. The admin boundary will
coincide with the coastline where there is a vertical wall or cliff. The
island name should I guess be on the coastline; this mostly also be a
multipolygon relation for that island, so in that case the name should
be on that relation.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] distance_from_road tag

[Colin Smale]

On 2020-01-15 14:05, Philip Barnes wrote:

> On Wednesday, 15 January 2020, Colin Smale wrote: On 2020-01-15 13:52, Lionel 
> Giard wrote:
> 
> Yes this is something you can do with any distance algorithm in available in 
> any GIS tool. That's not something that i would ever map as it would vary 
> with any geometry change of the ways between the road the point you measure, 
> added to the fact that it add nothing to explicitly map it (in my opinion at 
> least). It is essentially what any routing app will calculate when you ask 
> "find the nearest POI" for example. 
> Surely the question is not about straight-line geometric distance/time
> but about route distance along paths etc. in pedestrian mode. "Nearest"
> is not nearest in terms of geometric distance, but the POI with the
> shortest route.
 It is, but surely in calculating that distance it is easier and better
to simply map the paths? 

Absolutely, but actually a router that can handle routing over a polygon
might be more versatile as it would not be restricted to the lines that
people have mapped as paths. Imagine an algorithm that can take a
polygon (town square, park, whatever), detect all ingress/egress points,
use visibility rules to get round concave bits and obstacles like
fountains and statues, create a temporary routing graph, deduplicate
common segments and otherwise optimise, and use that to route people
across the polygon. In this case the "pedestrian" can be guided to the
target POI without the necessity of having every possible pedestrian
path mapped while still respecting barriers (which we do have in OSM)
such as buildings, walls, fences, ditches etc.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] distance_from_road tag

[Colin Smale]

On 2020-01-15 13:52, Lionel Giard wrote:

> Yes this is something you can do with any distance algorithm in available in 
> any GIS tool. That's not something that i would ever map as it would vary 
> with any geometry change of the ways between the road the point you measure, 
> added to the fact that it add nothing to explicitly map it (in my opinion at 
> least). It is essentially what any routing app will calculate when you ask 
> "find the nearest POI" for example.

Surely the question is not about straight-line geometric distance/time
but about route distance along paths etc. in pedestrian mode. "Nearest"
is not nearest in terms of geometric distance, but the POI with the
shortest route. 

> Le mer. 15 janv. 2020 à 12:45, Mateusz Konieczny  a 
> écrit : 
> 
>> I propose describing distance_from_road tag, defined as 
>> "distance in meters from nearest road" as a misguided idea that should not 
>> be used. 
>> 
>> https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently 
>> created by PangoSE and claims 
>> "Useful for indicating the distance to nearest road accessible by a 
>> normal car for people who cannot walk very long because of illness or 
>> pregnancy but anyway want to get out in nature. " 
>> 
>> "I'm quite sure there is a clever GIS way of calculating this using a 
>> routing engine, 
>> unfortunately no tool or website has yet been created to easily visualize 
>> this yet. 
>> When this is available we could probably get rid of this tag or generate its 
>> values by bot." 
>> 
>> I am 100% sure that such tags are not welcomed and especially bot idea is 
>> really 
>> poor, but I want to ask other for confirmation. 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://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] Tagging Free Water for cafés, bars, restaurant

[Colin Smale]

On 2020-01-13 12:18, European Water Project wrote:

> Hello, 
> 
> 1) 
> free_water=yes if it is available to anybody, and free_water=customers  is 
> very confusing and people will mis-tag free water for paying customers as 
> free_water=yes

This model is used for many other tags in OSM. One of the most
fundamental tags, access=*, uses it to show "access only for customers"
for example. See
https://wiki.openstreetmap.org/wiki/Tag:access%3Dcustomers .
free_water=customers would not look out of place at all in that list. 

The other dimension that has been mentioned, is "bring your own
container" vs. "we supply the container". Something like
"container=customer", "container=supplier" or "container=both" perhaps?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=vending_machine/vending=bottle_return - operator=

[Colin Smale]

On 2020-01-13 09:59, Martin Koppenhoefer wrote:

> Am Mo., 13. Jan. 2020 um 09:25 Uhr schrieb Jake Edmonds via Tagging 
> : 
> 
>> Do you have a suggestion Martin?
> 
> maybe a generic 
> 
> amenity=bottle_return_machine ?

Why limit it to bottles? We don't do that with vending machines; Why do
it here? The type/class of RVM can be indicated by
reverse_vending=bottles just like we use vending=drinks. 

> could be used for all kind of machines that take bottles, and amended with 
> tags about the kind of bottles. It also seems easier to understand for 
> non-natives (while describing more specifically the purpose) than "reverse 
> vending machine".

Anyone looking at the current tagging is going to see lots of terms that
they don't understand, for reasons of language or knowledge/experience.
The device in question is called a reverse vending machine in English,
even if some people think it sounds weird. Can you suggest a synonym
that would mean more to a random non-native-speaker, without changing
the meaning to a hyponym? I note that even the wiki page for
amenity=vending_machine refers to these devices as a reverse vending
machine.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

[Colin Smale]

On 2020-01-13 10:18, European Water Project wrote:

> Dear All,  
> 
> I thought this subject could wait, but it is becoming pressing early than I 
> expected.  
> 
> As part of our project (and that of similar non-profits - most of which are 
> not open data but nevertheless great organisations), we want to voluntarily 
> encourage cafés, bars and restaurants to offer free tap water bottle refill 
> to anyone off the street.  Refill has had significant success in the UK and 
> surprising the feedback is that the impact of increased customer traffic far 
> outweighs any issue of cannibalization.  
> 
> If it is not already the case, could we develop a tagging standard for this 
> case. Maybe "amenity = cafe & free_water = yes" 
> 
> It would be important to develop at the same time a distinct tag for another 
> cause, which we support but will not be targeting is restaurants which offer 
> free tap water for paying customers. 
> Maybe "amenity = restuarant & free_carafe = yes"

How about free_water=yes if it is available to anybody, and
free_water=customers if it is only available to paying customers? 

I assume this could actually apply to all manner of objects, including
pubs, bus stations, town squares... If so, there is no need to reference
amenity=cafe etc in the tagging standards, other than as a non-normative
illustration or example. 

Referencing carafe is not a good plan; firstly that is the container,
not the contents and this proposal is about the contents. Secondly, many
other things are frequently served in carafes, such as wine. So
free_carafe=yes may end up disappointing a few people...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addresses on buildings

[Colin Smale]

On 2020-01-07 22:21, Paul Allen wrote:

> On Tue, 7 Jan 2020 at 21:00, Colin Smale  wrote: 
> 
>> So if I am now more explicit about my intention to help this discussion 
>> towards a conclusion.
> 
> Actually, you sorta hijacked a discussion about whether to put the address on 
> a 
> building or a nearby gatepost.  This discussion is probably needed too.

I don't think it was so much hijacking the discussion, more getting it
back to fundamentals. If an address is for the benefit of delivering
letters, its location in OSM should ideally approximate to the postal
delivery point: the front door, the front gate... Locating it implicitly
at the centroid of the building outline, or the centroid of the
associated grounds, would be suboptimal. A building, being a single OSM
object, can only really have one address. As a building can
fundamentally have N (maybe hundreds for blocks of flats) addresses for
postal purposes, then there is no point in putting an address on a
building. If a company resides in a premises, it may be useful to put
their postal address adjacent to (i.e. on the same OSM object as) the
other attributes of the company as "contact information" i.e. how to
address a letter so it gets to this building, but not by definition what
to put in your satnav. Then if multiple companies share an OSM building
they all have their own node and thus their own address. HOWEVER if you
want an address for navigation purposes, a single set of address
components will suffice to get you to the right building, irrespective
of who you are visiting. 

Fix the complex case, and the rest is easy. 

>> What an address refers to, is different in the UK compared to other 
>> countries. We will never find a single model to fit the whole world that is 
>> not abstracted to the point that it becomes useless. Let's stop chasing our 
>> tails, and accept that.
> 
> Already have.  Long ago.  Not sure that what we have, even in the UK, is 
> entirely 
> fit for purpose because I have several examples in my own town alone that 
> don't fit 
> that model.  These are, to some extent, country-specific editor preset 
> issues: figure 
> out what works in a given country and persuade the people maintaining the 
> editors to 
> adopt it.  Yes, I'm simplifying a lot (again). 
> 
>> Back to the philosophical question: Is a normal "address" in OSM: a) for 
>> delivering letters, or b) for navigation, or c) an identifier of a 
>> building/premises, or d) something else?
> 
> The philosophical question is actually should we limit/prohibit any of those 
> uses?  I 
> think not.  We can't force any mapper to add all of the info, but we ought 
> not to prevent 
> them from doing so. 
> 
>> Should/could we cater for these different definitions of "address", e.g. by 
>> having tags like addr:{address_type}:{address_element}? This is a question 
>> that IMHO is probably best addressed at global level; then let each country 
>> have its own model within that framework.
> 
> Gut feeling, without any real analysis, is we don't have address_type, we 
> just have 
> address_elements.  Because in one country address_element X may be a critical 
> component of address_type A but in another country it's a critical component 
> of 
> address_type B.  Just have address elements and it's up to the consumer to 
> make 
> sense of them.

I agree with your gut feeling. But it is bad for OSM's data quality
if we cannot state what frame of reference was used for addressing. If
one mapper uses strict postal addressing (unreliable for navigation),
and another uses physical addressing (not matching the postal
addresses), and we cannot tell the difference from the OSM tagging, then
we are presenting our data consumers with a challenge, in the same way
that having maxspeed=N without explicit or implicit units would cause
problems. Even in the UK speed limits in km/h are used on many rail/tram
systems...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addresses on buildings

[Colin Smale]

On 2020-01-07 21:14, Paul Allen wrote:

> On Tue, 7 Jan 2020 at 19:42, Colin Smale  wrote: 
> 
>> I'm glad you said "probably", because it is of course not always true. And 
>> these edge cases are what we need to accommodate. Limiting the discussion to 
>> just handling the easy cases is cheating.
> 
> I know it's not true because I've had to deal with some of these oddities. 
> Sometimes we can have a scheme that handles oddities in its stride without 
> imposing unnecessary difficulties on the normal cases.  I haven't seen 
> anybody 
> suggest anything like that (yet) for addresses.  But I still think we should 
> optimize 
> for the common case and not optimize for the abnormal case.  Make the easy 
> things 
> easy and the hard things possible rather than make everything hard.

Optimisation should be phase two. First define a model that works, then
optimise. Ignoring the edge cases just delays the pain. We are long past
the point of handling the simple cases. 

>> Bit of a philosophical question: What is an address? In the UK, the Post 
>> Town and Postcode are for the purposes of delivering mail. If they happen to 
>> be useful to other parties, that's great, but it is only a side-effect.
> 
> Post town is actually the opposite of useful.  People put the post town in 
> their address 
> rather than their nearest named locality which makes it hard to find them 
> when looking 
> at a printed map.  Actual nearest locality is far more useful whether looking 
> at a 
> printed map or making a nominatim query.  Post Town is no longer necessary 
> even for 
> delivering mail, it's just a historic artefact that serves no useful purpose 
> any more.

Royal Mail do not say the Post Town is optional. RM also know of
localities and dependent localities, which may or may not bear any
resemblance to an inhabitant's perception of where they live. 

[...] 

>> Administrative boundaries are not relevant in UK addressing, unlike many 
>> European countries (I know about NL, DE, BE, FR) where "places" have defined 
>> boundaries.
> 
> Administrative boundaries are not usually relevant but are often given and 
> often 
> required when filling in forms.  They sometimes are relevant; there are 
> several 
> localities called Tarbert (sounds like a Dilbert character) in Scotland and 
> without a 
> postcode you need a county to figure out which one is which.  There are other 
> places 
> in the UK where the county is needed to disambiguate, and even some where you 
> need 
> more than just the county.

Postal counties have been deprecated for years, but are still in many
people's minds. Metropolitan counties are no longer "administrative".
Traditional counties maybe? But almost certainly not administrative
counties. 

>> The relationship between buildings and postcodes is N:M. If we replace the 
>> word "building" with "premises" and saying that an address refers to a 
>> "premises" may get us a bit closer, given that a "premises" may consist of 
>> part of a building, a  whole building, multiple buildings or any combination 
>> thereof.
> 
> I simplified, a little.  For anything that has a postal address in the UK, 
> the building(s) 
> number or name, plus the postcode, uniquely identifies it for the purposes of 
> postal 
> deliveries.  But the other stuff can be useful for other purposes.

So if I am now more explicit about my intention to help this discussion
towards a conclusion. What an address refers to, is different in the
UK compared to other countries. We will never find a single model to fit
the whole world that is not abstracted to the point that it becomes
useless. Let's stop chasing our tails, and accept that. 

Back to the philosophical question: Is a normal "address" in OSM: a) for
delivering letters, or b) for navigation, or c) an identifier of a
building/premises, or d) something else? Should/could we cater for these
different definitions of "address", e.g. by having tags like
addr:{address_type}:{address_element}? This is a question that IMHO is
probably best addressed at global level; then let each country have its
own model within that framework.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addresses on buildings

[Colin Smale]

On 2020-01-07 20:04, Paul Allen wrote:

>> But why do we need to have the full street address on the building at all?
> 
> To identify it.  In the UK, house number or name, plus postcode is sufficient 
> to 
> uniquely identify it.  People, however, still find other information useful.  
> Such as 
> the address being 7 Foo Street means it's probably accessible by Foo Street.

I'm glad you said "probably", because it is of course not always true.
And these edge cases are what we need to accommodate. Limiting the
discussion to just handling the easy cases is cheating. 

Bit of a philosophical question: What is an address? In the UK, the Post
Town and Postcode are for the purposes of delivering mail. If they
happen to be useful to other parties, that's great, but it is only a
side-effect. The street name, plus house number/name, are more directly
addressed at members of the public trying to find the property in
question. Administrative boundaries are not relevant in UK addressing,
unlike many European countries (I know about NL, DE, BE, FR) where
"places" have defined boundaries. 

The relationship between buildings and postcodes is N:M. If we replace
the word "building" with "premises" and saying that an address refers to
a "premises" may get us a bit closer, given that a "premises" may
consist of part of a building, a  whole building, multiple buildings or
any combination thereof.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=vending_machine/vending=bottle_return - operator=

[Colin Smale]

On 2020-01-05 21:02, Martin Koppenhoefer wrote:

> sent from a phone 
> 
>> On 5. Jan 2020, at 16:46, Colin Smale  wrote:
> 
> The term vending machine is misrepresenting these machines and should not be 
> used. 
> 
> They are frequently called "reverse vending" machines - instead of the 
> customer trading money for goods, they trade goods for money. 
> https://en.wikipedia.org/wiki/Reverse_vending_machine

clearly „reverse vending machine" is a completely different term/concept
than „vending machine", although it plays with the idea of using the
same words and change the meaning by adding „reverse" to it 

It is also a clearly related concept. I hereby propose: 
   amenity=reverse_vending_machine 
   reverse_vending=bottle_return 
Problem solved.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=vending_machine/vending=bottle_return - operator=

[Colin Smale]

On 2020-01-05 16:22, Martin Koppenhoefer wrote:

> sent from a phone
> 
> I would characterize them completely differently, nothing is sold, and you 
> don't get a discount coupon but rather a receipt to get back your deposit. 
> The term vending machine is misrepresenting these machines and should not be 
> used.

They are frequently called "reverse vending" machines - instead of the
customer trading money for goods, they trade goods for money. 

https://en.wikipedia.org/wiki/Reverse_vending_machine___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=vending_machine/vending=bottle_return - brand:

[Colin Smale]

Jake, could I ask you to state what country/state you are referring to?
These practices are likely to be different across the world. For
example, some countries (such as the Netherlands where I am now) have a
pseudo-mandatory system where the retailers pretty much have an
obligation to facilitate the deposit schemes, but that usually only
covers products they sell themselves. So there would be no real need for
"brand" or "operator" in NL. Other countries will probably have
different systems - maybe they do not charge an extra deposit on the
bottles, but still offer a (small) discount when they are returned.
Finding a tagging scheme to fit the whole world requires extensive
analysis of as many different perspectives as possible.

On 2020-01-05 13:15, Jake Edmonds via Tagging wrote:

> Some bottle return vending machines only accept bottles of a particular 
> beverage brand. 
> 
> Of the existing 137 bottle return nodes, none specify if there are any 
> restrictions of which brands of bottles can be returned. 
> 
> I would like to propose using brand= but wanted to check if there were any 
> other suggestions before I add it to the wiki.
> ___
> 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] Tag for "tax free shopping"

[Colin Smale]

On 2020-01-01 02:04, Jarek Piórkowski wrote:

> On Tue, 31 Dec 2019 at 19:16, Colin Smale  wrote:What 
> do you consider a definition of "duty free" or "duty free shop"
> that would be useful to a OSM data consumer?
> Which OSM data consumer?
> 
> Just a reminder: I didn't start this, I am merely trying to add a nuance to 
> the data modelling.
> I appreciate it, I'm just not sure if this nuance has any significance
> to any real-world usage.

I actually tend to agree. But to address my concern. the definition of
duty_free=yes will have to be far less absolute. Phrases like "all
passengers" could be replaced with "passengers" or "qualifying
passengers" for example (but not "international passengers"). To me, the
way a tag is defined is actually more important than the word that is
used in the tag. 

As an aside, I saw some support for shop=duty_free. This is an abuse of
shop=* and cannot be allowed! Shop=* indicates what is sold there, not
fiscal arrangements. You can buy duty-free (tobacco, alcohol, perfume
etc) but also tax-free electronics, cameras etc. I suppose one could
nit-pick about the difference between tax and duty but that is probably
not relevant to the average user.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for "tax free shopping"

[Colin Smale]

On 2020-01-01 00:54, Jarek Piórkowski wrote:

> On Tue, 31 Dec 2019 at 18:48, Colin Smale  wrote: 
> 
>> Just to be clear: in the situation I am referring to, an article priced at 
>> GBP120 in such a mixed shop is GBP120 net to an exporting passenger, but 
>> GBP100 net + GBP20 tax (@20% VAT) to a non-exporting passenger. Everybody 
>> pays the same, but the accounting is different.
>> 
>> The implementation in a couple of shops is described here:
>> http://www.whsmithplc.co.uk/vat/
>> https://www.schiphol.nl/en/page/taxfree-explained/
>> 
>> So the shop is both tax/duty free, and not, at the same time. Hence it does 
>> not fit the proposed description of either duty_free=yes or duty_free=no. So 
>> we need a value to represent "yes, if your next destination is outside the 
>> current customs area." Duty_free=mixed would also not quite cover it IMHO as 
>> it might imply that it only applies to certain goods, whereas the 
>> distinction I am trying to make is based on destination.
> 
> What do you consider a definition of "duty free" or "duty free shop"
> that would be useful to a OSM data consumer?

Which OSM data consumer?

Just a reminder: I didn't start this, I am merely trying to add a nuance
to the data modelling. 

IF we are going to label duty.free-ness, it might indeed to be useful to
have agreement about a couple of usecases so we can discuss the tagging
more objectively. Speaking as a regular air passenger, it wouldn't add
much value for me personally, as I assume there are no tax-free
facilities within the EU anyway, and there are, I assume at every
(air/sea)port I use, when crossing the EU customs area border. Away from
(air/sea)ports it's a different story of course, with a variety of
tax-free purchase/refund schemes. 

I can imagine a shop's membership of a refund scheme to be important,
and the associated export points/offices (should all be tagged with a
reference to the refund scheme.) 

By the way, I am assuming that we are only discussing retail purchases
of goods by individual consumers, not services or B2B transactions which
would open up whole new cans of worms.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for "tax free shopping"

[Colin Smale]

On 2019-12-31 23:55, Jarek Piórkowski wrote:

> On Tue, 31 Dec 2019 at 17:37, Colin Smale  wrote: On 
> 2019-12-31 23:04, Hauke Stieler wrote: that's true, the EU is one special 
> case here. But would the status of a
> traveler influence the tagging schema of "duty_free=*" in your opinion? 
> The EU is only a special case because there are multiple countries within a 
> single customs area for these purposes. Many airports accommodate both 
> domestic and international passengers in mixed areas. The only other way I 
> can see duty free shops working us if domestic passengers were actually 
> banned from making purchases. This used to be the case within the EU, at some 
> airports at least.
> 
> In terms of tagging, the scenario described could be something like 
> duty_free=export - meaning YES if you are exporting it beyond the customs 
> union area (~~EU), otherwise NO.

Arguably, duty_free=export is the default meaning of duty-free.

In this case the shop is a "duty-free shop", it's just that not
everyone gets the same prices there (because you can't take advantage
of the tax/duty-free status if you're not leaving the customs area).

Just to be clear: in the situation I am referring to, an article priced
at GBP120 in such a mixed shop is GBP120 net to an exporting passenger,
but GBP100 net + GBP20 tax (@20% VAT) to a non-exporting passenger.
Everybody pays the same, but the accounting is different. 

The implementation in a couple of shops is described here: 

http://www.whsmithplc.co.uk/vat/ 

https://www.schiphol.nl/en/page/taxfree-explained/ 

So the shop is both tax/duty free, and not, at the same time. Hence it
does not fit the proposed description of either duty_free=yes or
duty_free=no. So we need a value to represent "yes, if your next
destination is outside the current customs area." Duty_free=mixed would
also not quite cover it IMHO as it might imply that it only applies to
certain goods, whereas the distinction I am trying to make is based on
destination.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for "tax free shopping"

[Colin Smale]

On 2019-12-31 23:04, Hauke Stieler wrote:

> Hi,
> 
> that's true, the EU is one special case here. But would the status of a
> traveler influence the tagging schema of "duty_free=*" in your opinion?

The EU is only a special case because there are multiple countries
within a single customs area for these purposes. Many airports
accommodate both domestic and international passengers in mixed areas.
The only other way I can see duty free shops working us if domestic
passengers were actually banned from making purchases. This used to be
the case within the EU, at some airports at least. 

In terms of tagging, the scenario described could be something like
duty_free=export - meaning YES if you are exporting it beyond the
customs union area (~~EU), otherwise NO.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for "tax free shopping"

[Colin Smale]

On 2019-12-26 06:14, John Willis via Tagging wrote:

> However, in airports, there are pointedly "duty free" shops for (all) 
> travelers. that have no ability to collect taxes for any purchase, so 
> shop=gifts + duty_free=designated might be a good way to do it for these 
> specialty shops in international zones, Compared to shop=supermarket + 
> duty_free=yes that would be at a normal market that offers that service for 
> foreign travelers who happen to shop there.

Whether duty-free is available depends on the passenger's status as
well. In Europe at least duty-free is not available to passengers within
the EU customs area. The shop will check the destination of the
passenger (via their boarding card) before concluding the sale. If the
passenger is not clearly leaving the customs area, then duty and taxes
are charged. This doesn't mean that the price to the passenger has to
change however, as the shop may choose to keep the total price the same;
but the way it is accounted, and what has to be handed over to the
government, will differ.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Colin Smale]

On 2019-11-11 09:47, Martin Koppenhoefer wrote:

> Am Mo., 11. Nov. 2019 um 09:37 Uhr schrieb Jan Michel : 
> 
>> On 11.11.19 01:09, Martin Koppenhoefer wrote:
>>> I generally agree with your remarks, just here I would like to point out 
>>> that there aren't any scooters in the "mofa"-class (AFAIK, not limited 
>>> to Piaggio Vespas), (motorized) scooters begin in the moped class.
>> 
>> Many of them can be ordered with a reduced maximum speed to be driven 
>> with a 'mofa' license.
> 
> you're right, sorry, seems I'm living for too long time away from Germany now 
> to have a good idea about the current situation. In many (most?) countries, 
> there isn't a mofa class at all, and you may not even need a driving license 
> for the bigger 50ccm class. For example there is no EU-vehicle class for 
> Mofas, it's a German specialty: 
> https://de.wikipedia.org/wiki/EG-Fahrzeugklasse#Klasse_L

And Dutch (snorfiets/bromfiets), and Belgian (klasse A/klasse B)... More
widespread than you think...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?

[Colin Smale]

On 2019-10-29 02:43, Joseph Eisenberg wrote:

> There is also a proposal to map the mean low spring tide line, the
> lowest tide line along the coast:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dmean_low_water_springs
> - so the estuary could end at the point where this line meets the
> mouth of the river.
> 
> This would usually be different than the political "baseline", which
> is often further out to sea, though sometimes it would match.

Assuming you mean the baseline for the purposes of territorial waters
etc, it is based on the low water line. There are rules which allow the
baseline to cut across inlets, bays, estuaries etc. So I would invert
your statement: the "political" baseline is the low water line, although
sometimes it is further out to sea.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] place or border_type ?

[Colin Smale]

On 2019-10-29 01:21, Paul Allen wrote:

> I have an innate dislike of such countrification on a global map.  It's 
> better than 
> hijacking tags without adding a country code ("The rest of the world uses X=Y 
> to mean 
> Z but in my country X=Y means W"), but only marginally so.  The problem comes 
> when 
> we add X:de=* and then find it also applies to France, and Italy, so have to 
> then either 
> add X:fr and X:it which are synonyms of X:de or persuade mappers in France 
> and Italy 
> to use X:de.

I suspect that the similarities of meaning between countries are more by
coincidence than by design, unless they are defined by some
supranational body like the EU or UN. If X:de, X:it and X:fr appear to
mean the same thing, it doesn't mean there aren't subtleties which would
be lost for ever if the tagging was conflated. 

> From a very brief examination of what kreisfreie Städte are they seem to bear 
> some 
> similarities to the UK's unitary authorities.  
> https://en.wikipedia.org/wiki/Unitary_authority 
> If the concepts are substantially the same, then we end up adding 
> border_type:uk or 
> using border_type:de in the UK.

In the UK a combination of admin_level and designation is adequate. The
UK local government system is not always hierarchical, however. At the
parish level much is unparished, and concepts like "lands common" don't
fit a perfect hierarchy. There are also Combined Authorities. 

The UK system of local government means there is a wider-than-usual gap
between local authority areas and "places" (which I define to be the
answer given by a local to "where do you live"). The admin boundary
system and "place" demarcation (where that is possible) are completely
orthogonal. 

> I'd prefer a way of handling these that doesn't require country codes.

Country-specific concepts require country-specific tagging, and there is
nothing more country-specific than local government. The only way to
avoid country-specific tagging is to agree on a common definition for
the whole world. This is OSM... Good luck with that___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating mini_roundabout

[Colin Smale]

I would suggest it is not necessary to replace the simple node with a circular 
way. I think it is perfectly acceptable if it is considered as a simple turn 
instead of negotiating a roundabout, from a routing perspective. An instruction 
to turn right at the junction would not be improved by an instruction to take 
the third exit. If the navigator knows that a junction is a mini roundabout, an 
instruction to turn right at the (mini) roundabout would probably be optimal. 

On 23 October 2019 11:35:53 CEST, Florian Lohoff  wrote:
>On Wed, Oct 23, 2019 at 09:24:30AM +, Philip Barnes wrote:
>> On Wednesday, 23 October 2019, Jez Nicholson wrote:
>> > So, for those who like definitions: In the UK, a "mini roundabout"
>is
>> > simply a small roundabout that is either flush to the road or
>slightly
>> > raised so that large/long vehicles are able drive over it if they
>need to.
>> > If it has anything on it, like a lamp post, it is a "roundabout".
>It is not
>> > the size, it is the being able to drive over it that matters
>> >
>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/561491/mini-roundabouts-report.pdf
>> >
>> There is also the rule that you should not do U turns at mini
>roundabouts, so it is important that mapping retains this important
>distinction.
>> 
>> These are a very common feature, it does seem odd that routers are
>not supporting them.
>
>The point is that a mini roundabout does need a LOT of preprocessing to
>put it into some graph for your classical A* or Dijkstra. You need to
>eliminate the node and replace it with a circular road much like a
>junction.
>
>Flo
>-- 
>Florian Lohoff f...@zz.de
>UTF-8 Test: The  ran after a , but the  ran away
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Colin Smale]

On 2019-10-11 11:09, Snusmumriken wrote:

> It is up to the driver. I think he can ignore most of the traffic laws
> in the cause of getting as fast and as safe to where he needs to go. So
> he would use his own judgment and not so much what a routing engine
> tells him what he can do.

That may be the case in some countries, but in the UK there are
limitations on what laws emergency vehicles can and cannot break. 

Countries also have differing definitions of what constitutes an
"emergency vehicle" for these purposes. A regular doctor on his way to
an emergency, organs for transplant for example... in the UK they cannot
use blue lights, and "people die" because these vehicles get stuck in
traffic. 

See this website for all the complexities: 
http://www.ukemergency.co.uk/blue-light-use/ 

The question is, how to model this in OSM? Or do we just model for
normal cars? Just like for trucks, routing for emergency vehicles needs
parameterisation for the vehicle characteristics and the specific use to
which it is being put *at that moment*.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag proposal: 'add=milestone'

[Colin Smale]

I would just like to make a point about mileages/kilometrages.
Physically marked positions (e.g. a milestone or a sign with an address)
can not be replaced by, or derived from, the actual distance along the
road. 

These distances are not constant. Roads get diverted, split, recombined
etc which can change the distance AND the zero-point. If you follow the
hectometer (100m) markers on motorways in the Netherlands you will see
loads of discontinuities caused by changes through the years.
Occasionally, where a change makes a road longer, a whole segment is
"recalibrated" to avoid duplicate markers or gaps. Where a road is made
shorter, a "jump" in the values is used. 

On 2019-10-09 08:43, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 9. Oct 2019, at 03:24, Jorge Aguirre  wrote:
>> 
>> After reading all the responses and comments made regarding this issue I 
>> would like to modify the originally proposed tag name ('addr=milestone') to 
>> a new proposal to name it:  'addr=road_marker' - which works for both the 
>> kilometer and mile highway location markers.
> 
> this implies road markers must be present, right? Isn't this mainly about the 
> distance from some zero point, even in the absence of road distance markers? 
> It could be addr:kilometrage to refer specifically to this distance, but I 
> agree on the other hand this would have a reference to kilometers in the tag, 
> which isn't universally working well on a global level 
> 
> 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