Re: [Tagging] date not in YYYY-MM.DD format should go into a sufix edtf ?

[Richard Welty]

On 6/5/23 8:12 PM, Minh Nguyen wrote:

Having tried to use both formats in both projects, I do think EDTF is 
the better format overall, and I wouldn't mind seeing it used in OSM. 
However, the ad-hoc format does have one advantage in being able to 
express dates in the Julian calendar directly, rather than making 
mappers perform the conversion themselves.


[1] https://github.com/OpenHistoricalMap/issues/issues/547



one of the things i've been contemplating for OHM time format
development is a strategy for dealing with Julian dates and
potentially non-western dates. but it's a lot and i've been too
busy to make any progress on this for a while.

the thing to keep in mind is that there is nothing much that processes
OSM dates, where as OHM needs to process dates to do the things. this
is what drives the differences.

richard
--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] route=raceway?

[Richard Welty]

there is a long stalled proposal for a relation type of circuit for
handling motor racing tracks. i suspect it will never be approved,
the last time i brought it up there was a general lack of response.

but it seems to me that a new relation type is not necessary anyway.
probably adding a new subtype to route relations would be more than
sufficent:

type=route
route=raceway

this would more than suit my requirements and i have no problem with
going through and changing all the circuit relations i've done in
OSM to use this tagging scheme. there are some subtags from the circuit
proposal that would be useful to carry over for things like start and
finish lines.

thoughts?

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] tagging for fairgrounds

[Richard Welty]

i've had a little discussion of this over on the slack tagging channel.

i'm currently working on some historic World's Fair/Exhibition sites,
and also have reviewed a number of fair grounds in the US.

we really don't have any tagging specific to these sorts of structured
park-like areas that have extensive exhibition spaces. park and
recreation ground are not quite there.

so i'd like to propose one of these two

landuse=fairground
leisure=fairground

i'm ok with either. the idea is that these represent a structured
area with pavilions or exhibition spaces, perhaps a midway, and
so forth. it would be applicable both to such things as the periodic
"World's Fairs" and to the many local fairgrounds (they're all over
the US, tied to county and state fairs during the summer.)
fairgrounds in the US are currently tagged somewhat erratically as
mappers guess at what tags apply.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging for fairgrounds

[Richard Welty]

On 8/27/20 12:35 PM, Paul Allen wrote:
>
> As is fair.  Without further qualification, I'd interpret "fair" as a
> (temporary, mobile) funfair: an annual event with fairground rides,
> stalls, etc. I think American usage may tend more towards trade fairs.
> 
> As for mapping the temporary funfair thing, that's difficult, at least
> around
> here.  Every November the town's biggest car park is closed to parking
> for a week and is used for several fairground rides and a couple of food
> stalls.
> As part of the same event, for a couple of days most of the town centre is
> closed to traffic and the streets are filled with market stalls selling
> all sort
> of things of varying quality, from real bargains to absolute garbage (like
> eBay made physical).  Hard to map.
> 
> There is also an annual agricultural-based show held in some large fields.

i'm fine with a british english equivalent if there is one.

temporary fairgrounds in the US are things on the order of the world's
fairs, which are really international and frequently last for two
seasons, the long side of temporary.

again in the US, state and county fairgrounds are permanent facilities
which function as event space when the fair is not actually going on.
the midway is usually temporary, but the buildings for, say,
agricultural exhibits are permanent, as is the race track (at many
fairs), which might be for horses or cars.

all of the following are fair grounds in upstate NY

washington county fair grounds:

https://www.openstreetmap.org/#map=17/43.09455/-73.54859

rensselaer county fair grounds:

https://www.openstreetmap.org/#map=17/42.90539/-73.58926

altamont fairgrounds:

https://www.openstreetmap.org/#map=17/42.69712/-74.02660

NY State fairgrounds:

https://www.openstreetmap.org/#map=16/43.0749/-76.2197

tagging is wildly inconsistant because there is not clear guidance
on these structured fairgrounds in the wiki. and they are all over the
US. this is a just a quick sampling.

while i recognize that at the present time, OHM concerns are of limited
interest here, tagging historic fairs is a use cae for this tagging as
well. my map of the 1964-5 NY World's Fair (a work in progress) is a
case in point:

https://www.openhistoricalmap.org/#map=16/40.7465/-73.8439&layers=O

so these things do exist, a fair number of them in the US, and are
not really temporary.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] relation proposals

[Richard Welty]

it's not obvious from reading the wiki where proposals for relations
or modifications to existing relations should go. the long stalled
proposal for circuits (race courses) is supposedly in the wrong place,
but i have no idea what the right place is.

i don't plan to try to revive that proposal, but rather i am about to
write a proposal for a new subtype of route to serve the same purpose.
i'd like to know the right place to put it.

thanks,
   richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Relations/proposed/circuit

[Richard Welty]

i would like to get a discussion of this proposal started again:

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit

it fills a need i have and i've been using it in both OSM and OHM.
i have made a couple of new comments on the Talk page. right
this instant i'm looking at mapping street circuits and i think
it'd be nice to talk about this before i commit any time to
them.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What sport=* for automobile racing?

[Richard Welty]

On 8/30/19 7:49 PM, Joseph Eisenberg wrote:

> There are 5 uses of sport=autocross, 2 of sport=auto, 1 of sport="auto
> racing" (with a space).
> 
> It would be useful to have a specific tag since automobile racing,
> motocross and karting use rather different raceways in most cases.
> 
> Perhaps sport=auto_racing would be clear, and generic enough to cover
> most types? https://en.wikipedia.org/wiki/Auto_racing
> 
> Also, it looks like there are some other types of motorcycle racing,
> other than motocross (which is specifically on dirt tracks /
> raceways).
> 
> Would sport=motorcycle be good for these? It's used 7 times.

some karts do run on full sized auto racing circuits, but kart
specific tracks are generally much smaller in scale.

lots of motorcycle racing on pavement uses the same circuits
as cars. but again, sometimes motorcycles run on narrower
circuits that are unsuitable for auto racing.

i don't have a proposal here, just conveying information.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What sport=* for automobile racing?

[Richard Welty]

On 9/1/19 12:12 AM, Warin wrote:
> 
> On 31/8/19 9:49 am, Joseph Eisenberg wrote:
>> With highway=raceway, the most common tags are sport=motor,
>> sport=motocross and sport=karting (and even some sport=rc_car for
>> remote controlled model cars). These are specific types of motorsport,
>> except for "sport=motor", which can include automobiles, motorcycles
>> and go-karts, so it's not very specific. 
> 
> Reason: Some tracks accept racing from all different kinds of motor vehicles 
> e.g. trucks, cars and motorcycles. 
> 
>> There's also some uses of
>> sport=speedway which is also unclear.
> 
> Speedway is a oval dirt course that is usually used by cars and motorcycles. 

in some national contexts, sure. the definition in the US is not that
restrictive.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What sport=* for automobile racing?

[Richard Welty]

On 9/1/19 8:20 AM, Richard Welty wrote:
> On 9/1/19 12:12 AM, Warin wrote:
>>
>> On 31/8/19 9:49 am, Joseph Eisenberg wrote:

>>> There's also some uses of
>>> sport=speedway which is also unclear.
>>
>> Speedway is a oval dirt course that is usually used by cars and motorcycles. 
> 
> in some national contexts, sure. the definition in the US is not that
> restrictive.

on reflection, a better solution (i think) is to just use surface tags
that already exist. if you want query terms you could add

circuit_type={oval|road_course|drag}

and perhaps off road, although road_course+dirt might suffice.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] relation types: circuit proposal and an alternative

[Richard Welty]

a couple of months ago, i brought up the circuit proposal again,
to a profound lack of interest. it is being used, by myself and
others, because it does serve a need. as a reminder the original
proposal is here:

https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Circuit

but in the past couple of days, i've had an idea, and you all know
how dangerous that can be.

what if, instead of adding this circuit type, we instead recognized
that the route relation already exists and the purposes of the rather
specialized circuit relation could be handled simply by adding a
raceway or race_circuit subtype.

additionally, there is a need in OHM that arises for a similar route
relation variant type for horse racing tracks, which has to do with
temporal tagging of race tracks that have served both purposes in their
lifecycles, sometimes but not always at the same time.

this seems like a really clean way to get what's needed while sticking
with a relation that already exists.

the additional tags for things like start line, finish line, etc. would
be added much like the specialized tags for outher types of routes.

thoughts?
   richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relation types: circuit proposal and an alternative

[Richard Welty]

On 1/7/20 4:18 PM, marc marc wrote:
> Le 07.01.20 à 20:58, Richard Welty a écrit :
>> a profound lack of interest
>> https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Circuit
> 
> maybe it's due to the funny url for a propal
> moving it at the right place may help

so i looked over the general proposal page here

https://wiki.openstreetmap.org/wiki/Proposal

and there are no actual guidelines about what URL to use,
and while the non-relation proposals are generally in one place,
the relation proposals are often similar to the one for
the circuit relation proposal. on top of that, the "directory" for
proposals seems to me to be a poorly maintained mess.

i want to enter a proposal for my additional tags for
route relations, and i'm happy to move the circuit proposal
if i can get some clear direction. my hope would be to get
some genuine discussion going about the pros and cons of each,
then move one through. i suspect that adding some new tags to
the existing route relation will be easier than getting the
circuit relation through, but that's just a hunch.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency vehicle country-specific law

[Richard Welty]

> Am Mi., 6. März 2019 um 14:16 Uhr schrieb Marc Gemis
> mailto:marc.ge...@gmail.com>>:
> 
> On Sat, Mar 2, 2019 at 11:52 AM OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com
> > wrote:
> 
> If there was an explosion due to a gas leak and the road is blocked by
> debris, I guess they can go in the opposite direction of a one-way
> street as well.
> 
> 
from talking to Albany FD firemen, they will go the wrong way if it
facilitates getting equipment to the fire. they prefer not to, but
sometimes they have to.

but there are sometimes other considerations. when FDs respond
out of their district as part of mutual assistance, they may
not know all the local rules.

i spent some time looking at a project to build OSM based
emergency maps. i concluded we needed to do layers of
information, some of which were appropriate to host in
OSM and others which were not. there would have been a
program to conflate the data to produce an OSMAnd or similar
data file that met the department needs but avoided
dumping inappropriate data into OSM.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency vehicle country-specific law

[Richard Welty]

On 3/6/19 5:17 PM, Jarek Piórkowski wrote:
> On Wed, 6 Mar 2019 at 16:29, Richard Welty  wrote:
>> i spent some time looking at a project to build OSM based
>> emergency maps. i concluded we needed to do layers of
>> information, some of which were appropriate to host in
>> OSM and others which were not. there would have been a
>> program to conflate the data to produce an OSMAnd or similar
>> data file that met the department needs but avoided
>> dumping inappropriate data into OSM.
> 
> Out of curiosity, if you don't mind/can share - what was not
> appropriate for OSM? Internal preferences or policies ("prefer to go
> down 1st rather than 2nd even though both look the same" - if only so
> drivers don't have to make that decision every time separately) or
> something else/more?

mostly, policy things like that. a lot of the things that FDs care
about are local policy rather than local regulations. if we stick to
the classical OSM theory that we map things that are observable
(which is something that is not fully honored of course) then
local policies are something a mapper on the ground can't see
unless they interview firefighters (which i've done a bit of.)

there are other examples. for example, the Chief of the Port
Henry department in upstate NY oversees a district that
is adjacent to Lake Champlaign, so you would think he has
a big enough water source. but the RR tracks running down his
side of the lake frequently carry huge trains loaded with
light crude oil. if one derails and catches fire, he can't
get to the lake. so he's been testing water flow of the streams
feeding the lake. that's the sort of data that's you can get
that benefits the FDs, but is not ground observable  in the
usual OSM manner.

a lot of rural FDs have designated landing sites for EMS
helicopters. they're not secrets, you can go to the local
FD and ask about them. but they are generally not marked, so
again, a mapper can't just walk up to them.

in the case of the Albany NY FD, there are streets downtown
that present challenges for some equipment. this matches
roughly with your example. it ends up being things like
if we want to get this piece of equipment to this building,
we need to go the wrong way on this street.

the thing i learned from all the interviews, though,
that is most interesting, is that the firefighers know
their districts, they don't need such aids if they're
responding at home. the value comes in when a company
crosses district borders to assist. this means that
a real tablet OSM app to support emergency services
should be a regional solution to support mutual
assistance calls.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency vehicle country-specific law

[Richard Welty]

On 3/7/19 12:49 PM, OSMDoudou wrote:
> I would expect the police would first re-organize the scene to revert
> circulation.
> 
>  
> 
> If the house on fire is just a few meters in the opposite one-way
> direction, they might go directly, but technically they would break the
> law, if I read the articles correctly.
> 
>  
> 
> So, we should map what it authorized and not authorized under normal
> circumstances, otherwise we map no restriction at all (because the
> policy may always reorganize things in urgent situations).

i think OSM should stick to mapping what is legal. first responders
frequentlhy have permission to ignore the restrictions that apply
to normal motorists, but they usually have relevant policies that
probably don't belong in OSM proper and which aren't knowable
without interviewing the responders in question (and i've
interviewed a bunch while developing requirements, i have some
insight into common policies.)

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Grain Storage Centre

[Richard Welty]

On 4/5/19 11:19 AM, Cédric Mélac wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Grain_Storage_Centre
> Defintion: A large site with many silos and barns which concentrates
> crops from farms around before selling at best prices.

these are commonly called Elevators in the US. i don't know what british
usage is.

note that there are also bin sites, which don't have the market/sales
aspect but are places where bins may be found, sometimes in large
number, for storage.

in the US, elevators may be straight up commercial, or may be coops.
don't know if that is worth capturing or not.

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of Sport

[Richard Welty]

On 5/24/19 11:20 AM, Martin Koppenhoefer wrote:
> 
> 
> Am Fr., 24. Mai 2019 um 15:55 Uhr schrieb Markus
> mailto:selfishseaho...@gmail.com>>:
> 
> I personally like the definition by the European Sports Charter
> (article 2, paragraph 1a):
> 
>    "Sport" means all forms of physical activity which, through casual
> or organised participation, aim at expressing or improving physical
> fitness and mental well-being, forming social relationships or
> obtaining results in competition at all levels.
> 
> 
> 
> what about shooting or chess? Chess clearly isn't a physical activity,
> while for shooting there may be discussion.
> The council of Europe also cites snooker along with chess as sports [1],
> probably darts would fit well in this list too ;-)

i am an active participant in motor sports. does this count or not?

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] reviving hollow way

[Richard Welty]

On 2/19/18 3:20 PM, Steve Doerr wrote:
> On 19/02/2018 09:00, Philip Barnes wrote:
>
>> As a native English speaker I have never heard the term Hollow Way,
>> however reading the description it seems that this proposal is
>> describing what is called a Sunken Lane.
>
> Might need a bit more research as both are fairly obscure terms, I
> would imagine. For what it's worth, 'hollow-way' [sic] is mentioned in
> the Oxford English Dictionary, while 'sunken lane' isn't, as far as I
> can see
the concept of a sunken way or sunken road is one that historians are fairly
familiar with. i know of examples in both italy and the US. the italian ones
i've seen are older and thus much more sunken than the ones in the US.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] reviving hollow way

[Richard Welty]

On 2/19/18 6:37 PM, Martin Koppenhoefer wrote:
>
> On 19. Feb 2018, at 22:28, Richard Welty  <mailto:rwe...@averillpark.net>> wrote:
>
>> i know of examples in both italy and the US. the italian ones
>> i've seen are older and thus much more sunken than the ones in the US.
>
>
> in Italy there are also “a lot” of historic cuttings (in rock),
> predating the Roman empire.
>
> https://duckduckgo.com/?q=tagliata+etrusca&t=h_&iax=images&ia=images
>
not all in rock. we saw a deeply sunken road in packed dirt at an
Etruscan site
in Tuscany quite a few years ago.

there are sunken roads/lanes associated with a couple of battlefields
from the
American Civil War, notably the one at the Antietam battlefield. these
are generally
of historical significance because they were handy pre-existing
entrenchments
that impacted the course of the battles. 100 years of use are easily
enough to
create a road or way that deserves to be called "sunken".

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is it possible to have highway=unclassified with ref tag?

[Richard Welty]

On 5/7/18 10:35 AM, Rory McCann wrote:
> On 06/05/18 09:41, Mateusz Konieczny wrote:
>> I am pretty sure that it is entirely possible to have
>> highway=unclassified
>> with officially assigned and posted ref number, but I wanted to check
>> whatever my edit on
>> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
>> was correct.
>
> Yes it is! AFAIR the "highway=unclassified" comes from British usage,
> where "unclassified" was a road classification. Yes it sound silly. I
> think the refs in the UK aren't signposted, but roads with the
> unclassified classification (!) have "U" refs (e.g. "U123", instead of
> "A123" etc). 
by convention if a ref is unposted, many folks use unsigned_ref instead
of ref
for example, pretty much all the rural paved roads in North Carolina
have state
assigned refs, but the ordinary town roads are unposted.

i can imagine a jurisdiction which uses signed refs on generic
"unclassified" roads,
but i've never seen one. i would be reluctant to explicitly rule out the
possibility.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] åååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååå

[Richard Welty]

On 6/27/18 9:52 AM, Martin Koppenhoefer wrote:
> 2018-06-27 15:38 GMT+02:00 Mateusz Konieczny  >:
>
> Sometimes it makes sense to do not fully delete OSM elements
> representing completely
> destroyed objects.
>
> For example, completely destroyed road should not be present in
> OSM, but it may make sense
> to keep destroyed:highway=service until it is not visible on
> various aerial images to avoid remapping
> it by armchair editors.
>
>
>
> Generally I agree it can be helpful to state for a transition time
> that something is gone but still visible in common aerial imagery.
>
> What is a "completely destroyed road"? Can there still be the roadbed?
> Drainage system / remains? Much more common than something vanishing
> completely is partial removal or decay. Often, traces remain. We
> should also raise awareness in this regard, so that people consider
> their options carefully after discovering a discrepancy between the
> ground reality and our map.
>
> For a very specific use case there is natural=tree_stump which can
> often be a good choice to convert a natural=tree into, after it was
> cut. But it isn't suitable if they removed the stump as well
> (encountered this just 2 days ago).
i would tend to use the existing disused: namespace for things that are
disappearing.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Richard Welty]

normalization into SI is the sort of thing that engineers and scientists
go for, and speaking as a (computer) scientist it has some appeal.

but practically it's probably not a good idea in mapping, where i think
we should be using local units in an unambiguous manner.

if i see maxspeed=40 on a road in the US w/o units, i have no idea what
i'm looking at, it could be 40mph or it could be 25mph. the mapper who
entered the data knew what s/he was looking at but i sure don't.

richard

On 7/27/18 11:20 AM, marc marc wrote:
> I agree maybe with the exeption of case like maxspeed
>
> François voltage is a good usecase to open an issue to the whised app.
>
> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
>> My own preference is to have no (zero) units in the database, decimals 
>> where wanted (maxwidth=2.2) and unit management support in editors.
>>
>> --
>> Andrew
>> 
>> *From:* Warin <61sundow...@gmail.com>
>> *Sent:* 27 July 2018 12:27:04
>> *To:* tagging@openstreetmap.org
>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their 
>> multiples in OSM values
>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
>>> sent from a phone
>>>
 On 26. Jul 2018, at 21:26, François Lacombe  
 wrote:

 I don't want to break things but only improve them, all the best
>>> one issue with using only one unit for a tag is that they can’t always be 
>>> transformed without rounding. E.g. maxspeed=55mph cannot be converted to 
>>> kph without losing information
>>>
>>> Also, shorter notations are better readable, hence reduce the likeliness of 
>>> errors not noted.
>>>
>>> On the other hand, I agree in the example of voltage it would make it 
>>> easier for queries to use the same unit. (you still can make queries, but 
>>> they are more complicated if you have to take units into account)
>>>
>>>
>> Unfortunately not everyone uses the same units... heights are in meters, 
>> feet .. depending on where you come from or what activity you follow.
>>
>> Voltages are in volts so the same units... but multiplies are common for 
>> high voltages .. no one uses 33000 volts .. they all use 33 kv.
>> If you stipulate that all voltages have to be in kv then 115 v becomes 
>> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
>> that is not how people talk about these things.
>>
>>
>>
>> ___
>> 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


-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hiking route abandoned

[Richard Welty]

On 10/1/13 10:56 PM, Bryce Nesbitt wrote:
> The problem with disused: is the object disappears from the map. 
>
> Your alternative is to leave it "on the map" as it does in fact exist.
> Then use "access=" to clarify the status.  It might have degraded from
> "access=public" down to "access=no" or "access=permissive" depending.
>
perhaps all that's really needed in addition to access= is

   maintained=yes/no

which would probably be more accurate than disused.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wind turbines: big and small

[Richard Welty]

On 10/7/13 9:12 AM, Janko Mihelic' wrote:
>
> What if the wind turbine is on the roof of a building
> ? That would
> still be high (because we tag height from the ground, not just the
> height of the wind turbine). Actually, all small wind turbines are
> usually high .
>
> The solutions Martin suggested seem better (rotor diameter, power
> output), but are even harder to get. Landmark seems a bit like a "tag
> for renderer" solution to me, but it doesn't seem harmful.
>
> Another solution comes to mind. What if we started tagging values with
> > and 
or just something that's sort of observable like "large" and "small"

i've only really seen two general sizes with nothing in between.
large and small might be good enough for our purposes.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Richard Welty]

On 10/7/13 12:18 PM, Martin Koppenhoefer wrote:
>
> 2013/10/7 fly  >
>
> You are allowed to push your bike on every footway/pedestrian plus
> ways
> with vehicle=no. E.g. it is useless. Either you are allowed to ride
> (bicycle=yes/designated) or not (bicycle=no or vehicle=no)
>
>
>
>
> I agree that bicycle=dismount seems useless, at least as long as you
> only look at public ways in Germany (and probably in most countries),
> but there are a lot of places where you can walk but you cannot bring
> your bicycle, not even pushing. E.g. in shopping malls and on private
> squares there might be restrictions. Then again there might be further
> distinctions (e.g. "are you allowed to carry your bike"? What if it is
> foldable? ...)
>
>
it has implications for routing of bicycles. bicycle=no will mean that
it will never be used on a bicycle route. bicycle=dismount would indicate
that inclusion of the way on a bicycle route is reasonable.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Richard Welty]

On 10/7/13 1:08 PM, John F. Eldredge wrote:
> Well, it may vary by jurisdiction, but I would not be surprised if it
> were legally enforced in cases where riding the bicycle could be a
> safety hazard to pedestrians, and in some cases to the cyclist as
> well.  I remember seeing such a "cyclists must dismount" on the narrow
> footway of a bridge over the James River, in Richmond, Virginia, USA. 
> Not only was the footway narrow, but the railing between the footway
> and the river was only a little over a meter tall.  This is adequate
> for a pedestrian, but a mounted cyclist could easily fall over the
> railing and into the river. Unfortunately, I am about 600 miles from
> Richmond at the present, so I can't show a photograph.
there's a cyclists must dismount sign for the footway along the Dunn
Bridge between Albany and Rensselaer NY. i can go get a picture if
anyone wants to see one. i think there may also be one for the NY 378
bridge over the Hudson a little further north as well.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Richard Welty]

On 10/8/13 10:32 AM, fly wrote:
> In all situation we do not need bicycle=dismount.
>
> Can anyone state that in her/his country this traffic_sign is official
> and not made up by some people ?
>
well, i can't say official for sure, but the dismount signs posted on
the various
Hudson River crossings originate from the New York State Department of
Transportation, the agency that has jurisdiction over the bridges in
question.
that strikes me as being somewhat official.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Richard Welty]

> Georg Feddern  wrote:
>
> Am 07.10.2013 19:13, schrieb Richard Welty:
>
> On 10/7/13 1:08 PM, John F. Eldredge wrote:
>
> I remember seeing such a "cyclists must dismount" on the
> narrow footway of a bridge over the James River, in
> Richmond, Virginia, USA. Not only was the footway narrow,
> [...] 
>
> there's a cyclists must dismount sign for the footway along
> the Dunn Bridge between Albany and Rensselaer NY.
>
>
> well, if it is tagged as highway=footway you already have to dismount - 
> otherwise it would be tagged as highway=cycleway.
> So where is the need for a bicycle=dismount here?
>
you're making an assumption about tagging of ways that may not apply
generally.
in some parts of the US, we have true multi-use paths where pedestrians and
cyclists are considered equal users. those are frequently tagged
highway=path
with access tags to denote the types of uses that are permitted.

for the two bridges i mentioned in the Albany NY area, both are connected to
the multi-use path network along the river and in OSM they're currently
tagged

   highway=path/foot=yes/bicycle=dismount

which accurately reflects the signage and legal usage.

if we create tagging schemes where you need to know the whole footway
= dismounted cyclist scheme, then you will end up with mistagging by those
who aren't aware of the distinction. we are better off, i think, if the
tagging
maps in an obvious way to the signs we see.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Telecoms local loops connections nodes

[Richard Welty]

On 11/21/13 12:32 PM, SomeoneElse wrote:
>
> Likewise if you want to use the correct English term for what you're
> calling "Central Office" or "MDF", use "Telephone Exchange".  I've
> never heard the description "Central Office" before - presumably it's
> American only.
Exchange is in common use in the US by regular people.
CO is more commonly used by US professionals, but i don't
know if UK telecom professionals use it or not.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bitcoin and Online shops

[Richard Welty]

On 11/26/13 4:13 PM, Yves wrote:
> Placing online businesses on a world map may be more tricky than you
> think ...
yes. the concept of a geographic location is sometimes
challenging. when the business is running a web store
in the cloud and outsourcing the order fulfillment then
it's hard to say exactly where they are on the map.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] opening-hours off closed

[Richard Welty]

On 11/28/13 11:05 AM, Martin Vonwald wrote:
>
> Removed the inappropriate warning and added a hopefully neutral
> statement. If something is wrong with the diagram everyone is invited
> to a) either fix it or b) add a short note that some special/complex
> case isn't covered by the simplified diagram and one should read the
> complete syntax.
>
> Thanks to André for his contribution.
>
we really do need a defined, unambiguous syntax for
date/time specification. the current situation is a nightmare
for data consumers and severely limits the utility of the data.

i also thank André for this work. now please, can we fix the situation?

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] max{height, width}:physical was Re: How to tag max width at chicane-type bicycle barriers

[Richard Welty]

On 12/3/13 7:40 AM, Martin Koppenhoefer wrote:
>
>
> if you want to tag this on the barrier (node), it might also be an
> option to use "maxwidth:physical". This is currently not among the
> mostly used tags, but the similar maxheight:physical has some (few)
> usage, and it indicates nicely that this is about physical
> characteristics and not about a legal limit.
i was unaware of this variant, but it could be quite useful in the US,
where we will usually see signage for maximum height, but sometimes
we see signage for "maximum height - actual". the normal sign includes
some margin of safety, the "actual" sign indicates that there is no margin.

this is a situation that's well known in the hauling industry in the US.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Security Gate Post/Cabin

[Richard Welty]

On 12/8/13 10:39 AM, Philip Barnes wrote:
> Where I have worked, and industrial sites that I have visited over my
> long career, that building is always called 'the gate house'.
>
> I would suggest building=gatehouse, or gate_house, although neither had
> any previous useage :)
>
same in the US. this seems non-controversial, i should think just
start using it and add an entry for building in the wiki. i know a few
gatehouses i've mapped that i can change from building=yes to
building=gate_house right now.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Security Gate Post/Cabin

[Richard Welty]

On 12/8/13 11:14 AM, Jonathan wrote:
> Wikipedia suggests a gatehouse as a medieval construction:
> http://en.wikipedia.org/wiki/Gatehouse
>
> building=gatehouse has been used 19 times, but in what context I don't
> know.
wikipedia is sometimes slightly off the mark. gatehouse (or gate house) is
in common usage today.

if gatehouse w/o an "_" is in use, i'm happy to go with that.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] how to tag a terrace?

[Richard Welty]

On 12/13/13 9:30 AM, Martin Koppenhoefer wrote:
>
>> Am 13/dic/2013 um 12:10 schrieb Janko Mihelić :
>>
>> I think there should be a big "building=yes" polygon over the terrace and 
>> the mansion attached to it (or building=mansion or whatever). Then put a 
>> polygon over just the terrace, and tag it building:part=terrace. There are 
>> 21 of them in the database right now:
> sorry if I wasn't clear, this is about "stand alone" terraces.
>
> Actually now sth. came to my mind, what about building=observation_deck?
>
i think this good. it avoids confusion with agricultural usage of terrace.
i don't think we're tagging terraced farms yet but terrace is potentially
ambiguous by itself.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tags useful for rendering of roads in poor conditions

[Richard Welty]

On 12/31/13 11:10 AM, Fernando Trebien wrote:
>
> I've been interested in proposing a change to Carto's style (Mapnik's
> main style) to allow visual identification of unpaved roads for any
> kind of road, much like the Humanitarian style does, which bases this
> decision on values of the surface tag. The Brazilian community has
> shown interest on this many times, since lack of this feature causes
> unaware users to classify roads incorrectly. David Bannon proposes
> (below) that we use the tracktype tag for that instead, but I've never
> seen it being used for anything besides roads with highway=track
> (therefore, not a very common practice it seems). Do you think we
> should encourage its use in conjunction with unclassified, tertiary,
> secondary and primary highways?
>
i've been known to use tracktype with highways other than tracks,
generally in
conjunction with setting surface=(gravel,dirt, etc.) there are rural
parts of
the US where such classification seems appropriate to me. i'm not sure
if it's
still true, but back in the 70s Vermont had state highways surfaced with
gravel.

tracktype works well for this; if it's not common usage now, maybe the
wiki should be tweaked to suggest such usage.
> It seems to me that surface=compacted is quite similar in meaning to
> tracktype=grade1 (whereas surface=sand, surface=dirt, and others,
> could be equated with other grades but rarely with grade1,
> particularly because the "compacted" value exists) and so both tags
> could be used for the same rendering purpose. Do you agree?
>
i frequently use

highway=unclassified
tracktype=grade1
surface=gravel

in cases where the road is well maintained and able to support traffic.
many, many farm roads in the midwestern US meet this description;
they don't particularly need to be paved, but they do need to support
heavy farm equipment moving from field to field.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tags useful for rendering of roads in poor conditions

[Richard Welty]

On 12/31/13 5:54 PM, Fernando Trebien wrote:
> On Tue, Dec 31, 2013 at 7:27 PM, malenki  > wrote:
>
> I wouldn't connect surface=compacted and tracktype=grade1 per default
> since compacted roads and and roads with really paved surface (asphalt
> or cobblestones) are not unlikely to show a very different driving
> experience after some good rain.
> Of course this also depends on your definition of "compacted". :)
>
>
> This is an important point where it gets tricky to reach "global"
> agreement.
properly, we should be talking about a consistent tagging scheme that
accurately describes the road surface. the rendering isn't the business of
the tagging group. we just need to produce tagging that is clear,
consistent, and reasonably complete. it seems to me that a simple edit
to the wiki extending tracktype=grade? across road classifications
other than track accomplishes most of what we want here, along with
encouraging use of the surface tag in an appropriate manner.
attempting to somehow relate surface= to specific tracktypes seems
like a bad deal to me; i've seen gravel roads that were grade1, and
gravel roads that were way, way worse than grade1.

there are reasons why there may need to be custom rendering stylesheets
for different parts of the world. it may be as simple as local taste,
but there
can be other issues - the new highway shield rendering for the US is really
nice, but may not make it into the main Carto style sheet, so there's a
chance the highway shields will get rolled out in an openstreetmap.us style.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tags useful for rendering of roads in poor conditions

[Richard Welty]

On 1/2/14 9:49 AM, Fernando Trebien wrote:
> So, which approach is most convenient for the rendering app?
> Definitely it's using the tracktype tag, there's only 1 value to be
> ever considered.
>
i really think we should spend less time on rendering and more time
simply on accurately and concisely describing the road. i feel i need
to remind everyone that there are other data consumers besides
rendering engines. Some examples:

mkgmap which produces garmin format maps from OSM data

OsmAnd which is both a routing and a rendering engine for Android platforms

various routing engines being developed with an eye on web deployment

and of course the data might be used for intensive analysis that doesn't
produce maps or routes, but reports and statistics.

you obsess with rendering representations at the risk of coming up with
something that only meets one particular perceived need.

richard





signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to map holiday flats? New tag "tourism=holiday_flat" or extend existing "tourism=chalet"

[Richard Welty]

On 1/2/14 8:31 PM, Dave Swarthout wrote:
> I think of the word "flat" as being distinctly British. I have only
> rarely heard the word "flat" used to describe and apartment in the
> U.S. When I first glanced at the beginning of this thread I thought
> the OP was referring to flats of flowers. LOL
flat was once much more commonly used in the US.

and since OSM tends towards UK English usage, i think it's
perfectly reasonable for OSM to use the term.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - trafficability

[Richard Welty]

On 1/3/14 6:23 AM, Dan S wrote:
> Hi,
>
> It reminds me quite a lot of opening_hours
> http://wiki.openstreetmap.org/wiki/Key:opening_hours
> Would that be appropriate?
>
there are different types of trafficability issues.
here in upstate NY, we have two types of seasonal
road. most are simply unpaved roads which have
signs indicating that they are not maintained from
November through the spring; they are not closed
but they are also not plowed and no effort is made
to repair anything during that time frame. it's
travel-at-your-own-risk, and the risk is at times
quite high. i've seen similar situations in Switzerland
where the road to the pass simply ends in a snow
bank (presumably there was a sign some where, but
i didn't look for it. maybe everybody knew so they
didn't put one up.)

there are a fewer number of roads that are seasonal
and gated; they physically close in November and the
gates are not reopened until spring.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] parking conditions

[Richard Welty]

On 1/3/14 7:58 PM, One Hwang wrote:
>
> I am confused about how to apply a parking tag for the "west side."
> Although there are tags called parking:lane:right and
> parking:lane:left, I am not sure whether west should be considered
> left or right.
>
> I plan to work with a number of citizens from Newton to complete the
> parking information during a mapping party. However, there are many
> cases like Acacia Avenue, and I think the standard tags will cause
> confusion. Do you have suggestions on how we can ensure a smooth workflow?
>
left vs right is with respect to the direction of the way in OSM,
so west could be left or right. and i agree it will be confusing
to new citizen mappers.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] parking conditions

[Richard Welty]

On 1/3/14 8:10 PM, One Hwang wrote:
> Suppose I wanted to tag to show that parking is prohibited on north
> side of Street X. Should I use parking:lane:right or parking:lane:left?
that depends on what the direction of the way representing Street X is
within OSM. which means that you can't make that decision until you're
in the editor.

you should use something like Field Papers to collect the data;
that will make it easier to deal with the data entry.

richard



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tags useful for rendering of roads in poor conditions

[Richard Welty]

On 1/3/14 8:19 PM, malenki wrote:
> How else would you describe an asphalted road like this?:
> http://geoawesomeness.com/wp-content/uploads/2013/10/lidar1.jpg
>
surface=car_breaker




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access in the wiki: move psv to "by use"

[Richard Welty]

On 1/13/14 1:04 PM, Martin Koppenhoefer wrote:
> psv reads "public service vehicle", clearly a use type. "e.g. busses"
> is correct as is "i.e. busses and taxis" (but the latter might forget
> some other kind of psv). Still this clearly doesn't include any buses
> (vehicle class, usually vehicles with more than 8+1 seats) but only
> those that are in public service. cheers, Martin
we may need to spend some time on this. the turn restriction
plugin for josm uses psv, but seemingly with the implication of
emergency/service vehicles (not including buses and taxis) for
things like u-turns on motorways.

i think we need some clarity about what psv actually means.

richard





signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access in the wiki: move psv to "by use"

[Richard Welty]

On 1/13/14 2:48 PM, Martin Koppenhoefer wrote:
> 2014/1/13 Richard Welty 
>
>> we may need to spend some time on this. the turn restriction
>> plugin for josm uses psv, but seemingly with the implication of
>> emergency/service vehicles (not including buses and taxis) for
>> things like u-turns on motorways.
>>
>> i think we need some clarity about what psv actually means.
>>
>
> I started mapping in Jan 2008. By that time it was already clear that "psv"
> was taxis and buses. If we start questioning every consensus (even those
> documented on central pages of the wiki like the access-page) we can stop
> mapping now ;-)
>
>
well, sure, but maybe someone should get the josm turn restriction
plugin better documented (at least)? because misleading tagging is
resulting.

richard




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access in the wiki: move psv to "by use"

[Richard Welty]

On 1/15/14 2:24 PM, martinq wrote:
> because of the JOSM turn restriction plugin? What about changing that
>> plugin?
>
> no, the argument for depreciation was: There is no need for this
> artificial group: Grouping taxi (both "in service" as well as not in
> service) with only those buses acting as public transport. Taxi access
> and bus access are distinct things. No ambiguous, poorly understood
> (here the poor plug-in just confirms that PSV is not well-understood)
> short-cut like "psv" is needed. If taxi and bus can access, why not
> bus=* & taxi=*?
i think the best fix for the josm plugin is simply to add a checkbox
for the emergency=yes access tag to the dialog.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=yes

[Richard Welty]

On 1/23/14 1:13 PM, Bryce Nesbitt wrote:
> What might people using the tag 'emergency=yes' have meant it to mean?
> And is it a good use?
>
> It's the #2 tag in a space that has some gems (emergency=aed and
> emergency=phone for example).  But I'm mystified by the usage.  20,000
> emergency=yes highways?
>
>
emergency=yes is an access tag, you would use it, for example, for
a u-turn on a motorway where the only permissible vehicles are
engaged in emergency response, e.g.

access=no
emergency=yes

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag an imaginary oneway barrier

[Richard Welty]

On 2/3/14 6:36 PM, Bryce Nesbitt wrote:
> When this is done in the USA, the usual case seems to be an entry
> restriction on one end of the street.
> Why would anything more complicated than an entry restriction be
> required in OSM?
> Typically it is a sign reading "Do not enter" with a sub-shield that
> may read "Except bikes and buses".
>
yes, i just use turn restriction relations to indicate that you can't go
that way. it's as easy as anything involving turn restriction relations
can be.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reliable OSM routing

[Richard Welty]

On 2/9/14 3:11 PM, Tod Fitch wrote:
>
> Some very good points here. . .
>
>
> On Feb 9, 2014, at 10:47 AM, André Pirard wrote:
>
>> Hi,
>>
>> I left this unsent for some time, so it may duplicate what has already been 
>> said.
>> But it's uttermost important.
>> 
>>
>> There doesn't seem to be routing quality assurance tools, not even Osmose 
>> detecting detectable mistakes, and I've corrected quite a number of bad 
>> tagging mistakes that I found with Osmand.
> Osmand is definitely a quality assurance tool for me. I have taken to using 
> its routing facility at every opportunity. When it comes up with a route that 
> makes no sense to me I go back to look at the OSM tagging to look for clues 
> as to why the route was selected. Usually it is bad or missing tagging. In 
> the western U.S. there is still a lot of old Tiger imported data that has not 
> been corrected or added to. Sometimes it is incorrect topology, but often it 
> is simply the lack of speed information as well as the location of stop signs 
> and traffic signals that cause the routing issues.
i agree 100%. i use Osmand a lot, and regularly check to see
how it is routing in places that i know well. it has on more than
one occasion alerted me to errors in the map, like a mapper
inadvertently reversing the sense of oneway on a dual carriageway.

> Since I'm not willing to setup for generating my own OBF files it takes a 
> couple of weeks for me to see if the fixes I add make any difference.
i will at some point need to learn how to generate files for Osmand.
another thing on a very long list of things i need to learn to do.
>> Many people appear confused with the restriction rules.
>> There should be a wiki page listing exactly what tags mappers and routers 
>> must use.
> That would be very helpful.
i think a tutorial "how to map for routers" alongside a reference page would
make a good pairing.
>> AFAICS, OSM routing is not reliable. It does make useful routes on the large 
>> scale but it makes many errors when coming down to the details and one may 
>> be booked for trusting it too much.
>>
> In the business sector I was in until recently, the phrase "eating your own 
> dog food" seems to apply. That is, use your own products in your production 
> environment to be really sure they are ready for market. I strongly suggest 
> that anyone doing tagging on highways use the OSM based routing tools and 
> when the results don't match expectations find and fix the tagging problem.
>
routing in OSM is at a very early stage. best way to move it forward is
for mappers to start using it in order to smoke out the problems.
i'm very glad that i've tried to maintain some sort of OSM based
routing capability on my dashboard for the past couple of years,
initially using garmins & mkgmap output, and now with Osmand.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - All You Can Eat

[Richard Welty]

On 2/17/14 1:49 PM, Steve Doerr wrote:
> On 17/02/2014 18:04, Fernando Trebien wrote:
>
>> I still think that "opening_hours" as a subtag would be an unnecessary
>> specialization that would only be needed rarely. Can you provide an
>> example in which you would not be able to represent that information
>> in a different way? (such as using two or more geometric objects)
>
> It's quite common in the UK for a restaurant to operate as a normal, a
> la carte restaurant most of the week, and offer an all-you-can-eat
> buffet on, say, Sundays. I'm at a loss to understand why that would be
> represented as two separate geometric objects.
>
we have those in the US too. there are a number of Indian restaurants
here in the capital district of NY that offer table service for dinner and
a buffet at lunch time. i suspect that this is very common.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: tag for planetarium

[Richard Welty]

On 2/24/14 5:17 PM, Colin Smale wrote:
>  
>
> I would not call it an amenity, which is (to me, native UK English
> speaker) something for the benefit/enjoyment of society as a whole (or
> at least a large part of it). These days a planetarium is probably for
> enjoyment/entertainment (suggesting leisure=planetarium).

on the other hand, in my experience Planetariums are usually
attached to museums of one kind or another, whether science
museums or children's museums.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: tag for planetarium

[Richard Welty]

On 2/25/14 9:08 AM, Paul Johnson wrote:
> Educational as they might be, it seems that the primary use of planetariums
> from what I've seen is to get high and watch laser light shows.  I vote
> leisure=planetarium.
>
>
clearly not everyone has been there to see the busloads
of elementary school kids who are actually the main visitors
to planetariums.

the Hayden Planetarium in NYC is perhaps an exception, but it
offers a pretty significant science museum along side the
planetarium itself.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] origin of some fire_hydrant tagging

[Richard Welty]

i'm wondering if anyone can speak to where the tagging
for fire_hydrant:type came from?

i'm seeing two issues with it right now.

one is that it conflates two concepts that probably should be
separated, the physical delivery method, e.g.

fire_hydrant:type=pillar

and the water source

fire_hydrant:type=pond

the other is that pillar is not representative of any normal
english language terminology i'm aware of. in the US, it
would be a fire_plug, and there is no UK equivalent because
the style of connection to the water mains for fire fighting
is completely different there.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Pistemap proposal

[Richard Welty]

On 2/25/14 4:27 PM, Janko Mihelić wrote:
> I have a few objections about that proposal:
>
> landuse=winter_sports
> I don't like this way of confining a ski resort. First,
> landuse=winter_sports here is used to tag a ski resort. That can't be
> right, because a restaurant can be a part of a ski resort, and it isn't
> used for winter sports. Second, the areas are going to be arbitrary because
> ski resorts don't have explicit borders as far as I know.
>
>
many of the ski areas here in the northeast US work hard at coming up
with uses for their facilities during the summer. it's not good business to
let everything sit idle. so i agree on this point, landuse=winter_sports is
too confining and doesn't match up well with real world usage.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] origin of some fire_hydrant tagging

[Richard Welty]

On 2/26/14 3:30 AM, Georg Feddern wrote:
> Am 25.02.2014 17:08, schrieb Richard Welty:
>> i'm wondering if anyone can speak to where the tagging
>> for fire_hydrant:type came from?
>
> AFAIK the Germans are guilty again - and I plea myself for not-guilty.
> ;-)
> (see http://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant
> and their history)
>
> And yes - pond does not really match a hydrant 'type' - the hydrant
> type there may be still a 'pillar' or an 'underground', less a 'wall'.
>
> Is it possible, that in UK/US the 'pillar' type is the norm and the
> 'underground' type is not wide spreaded?
my understanding that the classic plug (pillar in our tagging) is
used little if at all in the UK, but it is the norm for pressurized
water system deployments in the US. underground is the norm
in the UK.

> At least the http://en.wikipedia.org/wiki/Fire_hydrant uses the term
> 'post- or pillar-type fire hydrant'
> - but I do not know who wrote that.
i'm currently tinkering with what will be come a proposal to modify
current hydrant tagging.

my thinking is to add
  fire_hydrant:water_source={main,pond,stream,standpipe}
and deprecate fire_hydrant:type=pond

then the issue is whether we want to modify fire_hydrant:type or
replace it with a different tag altogether, say fire_hydrant:delivery
if we keep type, should we replace pillar with plug or fire_plug or just
let that go.

i had a while back discussed updating tags for hydrants. i now
have a simple set that i'm using that seems to cover the cases i'm
encountering. here are colour: tags

colour already exists and in this context describes the main color
  of the hydrant (call it the barrel color)
colour:cap describes the color(s) of the caps on the hydrant if
  they differ from the body color
colour:bonnet describes the color of the top section if it differs
  from the body color (i had been using colour:top but it turns out
  that firefighters in the US call it the bonnet; since the hydrant type
  is rare or nonexistent in the UK i'd suggest going with US usage)
colour:reflective indicates the color of any reflective material applied
  to the hydrant

others of value (all prefixed with fire_hydrant:) :
capacity= 
class={AA,A,B,C}- American Water Works Association classification
   scheme, derived from capacity and may be easier to obtain
in_service={yes,no}   - this turns out to be a very real issue

the existing diameter tag remains as is, the diameter of the main
the hydrant is attached to. this measurement is commonly used
in both the US and UK.

things i haven't got tagging worked out for yet:

outlet diameters
outlet threads
number of outlets
wrench types
orientation (is the steamer connection perpendicular to the
  curb, which is common, or rotated 45 degrees, which affects
  the hookup procedure).

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] origin of some fire_hydrant tagging

[Richard Welty]

On 2/27/14 4:37 AM, Georg Feddern wrote:
> Am 26.02.2014 13:23, schrieb Richard Welty:
>
>> then the issue is whether we want to modify fire_hydrant:type or
>> replace it with a different tag altogether, say fire_hydrant:delivery
>> if we keep type, should we replace pillar with plug or fire_plug or just
>> let that go.
>
> I would keep hydrant:type - because it is a physical type/design in my
> opinion.
> With hydrant:delivery I would not assume the physical type, sorry.
>
> And I would keep type=pillar.
> With fire_plug I - and I suppose many others - would assume "something
> you can connect with or to".
> And that are all hydrants in any design, it is too generic in my opinion.
>
fire plug in US usage is pretty specific, whereas pillar is a
complete mystery in the US. since there is no UK usage as
the type is not in service there, it kind of leaves things open,
as normally OSM uses UK english as the baseline and it doesn't
help in this case.

> Regarding standpipe:
> I would understand 'standpipe' as the device you need to connect to
> underground hydrants.
> So I would not use standpipe for hydrant:source but 'riser' instead,
> may be distuingish between dry_riser or wet_riser.
>
in US usage, standpipe is common usage for systems in buildings,
we have almost no underground hydrants, so that usage is unknown
here.

http://www.flickr.com/photos/nfgusedautoparts/12813740234/

i am discussing terminology with a retired UK firefighter, i will
find out from him what standard UK usage is for standpipe/riser
systems in buildings

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] origin of some fire_hydrant tagging

[Richard Welty]

On 2/27/14 4:50 AM, Philip Barnes wrote:
> I also disagree with standpipe, in UK usage a standpipe is an emergency 
> source of water provided for residents if mains water if off for some reason.
>
>
i have done some more research and asked around, and this
is where i'm at:

standpipe is ambiguous. it is used in the US for both wet and
dry risers, and in the UK for wet & dry risers (a secondary term
riser being primary in the UK) as well as for the pipe used
to provide connectivity to underground hydrants. so i think it
should not be used at all, since you wouldn't map the standpipes
in the UK (they're mobile after all.)

so riser for the in building systems is consistent with UK usage
and the way we should go. however, it turns out that riser
terminology does not use the term hydrant (it uses the terms
outlet and inlet in the obvious way), so i will drop it from the
water source specification.

finally, i have found references to pillar as a hydrant type. i was
not insisting on it going away, merely questioning where it came
from, so now i'm ok with leaving them as is. however, there are
more specific types available, so i will propose adding dry_barrel
and wet_barrel to the allowable fire_hydrant:type tags. it's fairly
easy to distinguish between the two types; dry barrel hydrants
are the norm in climates where the ground freezes, and wet
barrel hydrants are the norm in warm climates. the nut that
operates the main valve of the dry barrel is a dead giveaway
for the hydrant type, so it's easily detectable by mappers.

how does everyone feel about these changes?

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] origin of some fire_hydrant tagging

[Richard Welty]

On 2/27/14 2:36 PM, Andreas Labres wrote:
> Richard,
>
> fire_hydrant:type should remain unchanged, as this is negotiated with local 
> fire
> departments here in Austria (as well as Germany). At least this is true for
> pillar and underground, those are most common and most important.
i now am proposing that pillar be supplemented with dry_barrel and
wet_barrel,
and that pillar itself remain unchanged.
> Then there are fixed suction points, either from a pond or from the ground 
> water
> (well). There is no ideal tagging for this available, this "pond" may be 
> adjustable.
i'm proposing separating water source out because different types of
delivery device (pillars, pipes) show up in these cases in the US, i
don't think
that the water source and the delivery device should be conflated into
one tag.
> Things like the color don't make that much sense to me, is this one
>
> 
> http://www.scardo.net/typo/fileadmin/hydrantderwoche/20121125_WeinWasser_Ai.jpg
>
> blue? or stainless steel? But everybody here recognizes this as a hydrant,
> whatever color that is.
color may be more relevant in the US.
>
> Hydrant class may make sense to you, this is what we use the diameter for 
> (most
> common are 80 and 100). Just to give you an idea how those are used (really 
> used
> by the local fire department there):
>
>http://openfiremap.org/?zoom=17&lat=48.12184&lon=16.33877
some US departments use the main diameter; others use class. there is no
direct
translation between class and diameter, nor is there a direct
translation between
pressure and class.
> Other optional parameters as you like, they don't make that much sense to us 
> here.
>
>
fundamentally i'm arguing for latitude to match local conditions.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] origin of some fire_hydrant tagging

[Richard Welty]

On 2/27/14 2:56 PM, John F. Eldredge wrote:
> Color-coding is likely used by the fire department to signify matters such as 
> how much water-flow is available.  I don't know how standardized these color 
> codes are, however.
>
>
there are standards published by the AWWA (American Water
Works Association) and the NFPA (National Fire Protection
Association) which are approximately the same. however, they
are honored by some departments but not others. barrel color
is supposed to be chrome yellow, and the bonnet and caps
are supposed to be painted to indicate flow capacity at 20psi.
details of the standards may be found here:

http://www.firehydrant.org/info/design07.html

some departments use bonnet and/or cap color to indicate
the main diameter. this is easier to do than measure flow
capacity but provides less useful information; in theory a
hydrant on an 8" main can produce 1000 GPM at 20 psi,
but in practice they sometimes produce noticeably less.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fixing wrong opening_hours automatically

[Richard Welty]

On 3/7/14 7:03 AM, Dan S wrote:
>
> I'm sorry but if it is description-like, then it is free text and
> shouldn't be auto-standardised in the manner you propose. You need to
> decide if you think it is description-like (== free text, local
> language) or formalised (==set of possible labels, british english).
>
Opening hours really needs to be parseable, it contains data that
is of value to data consumers (like routing software.) for example,
the opening_hours format gets used for turn restrictions that have
times attached and for seasonal roads. treating it as free form
would be a disaster.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=ground/dirt/earth

[Richard Welty]

On 3/13/14 12:02 PM, Georg Feddern wrote:
>
> So I would get rid of dirt, but keep 'earth' beside 'ground' as a
> useful value (smooth walking on hiking trails) .
where as for my mapping in the US, dirt is the only
one that i use, and common usage is to refer to these
roads as dirt roads by pretty much everyone.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=ground/dirt/earth

[Richard Welty]

On 3/14/14 4:54 AM, Martin Koppenhoefer wrote:
>
>> Am 13/mar/2014 um 22:31 schrieb David Bannon :
>>
>> We often describe a gravel road as a dirt road
>
>
> agreed, but would you say it has a "dirt surface"?
>
i certainly wouldn't. i use unpaved as the more generic
term, and dirt or gravel when i know for sure.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=ground/dirt/earth

[Richard Welty]

On 3/14/14 3:11 PM, Fernando Trebien wrote:
> Considering that "surface" is loosely defined (it can have any value)
> and no rules are imposed on it, I believe that ground and dirt are
> acceptable values, but not quite desirable, as their meaning is too
> low quality (too imprecise) for applications such as routing and even
> rendering of detailed surface maps. They both hardly mean something
> significantly different from "unpaved" (for most practical
> applications I can think of).
>
i generally try to combine surface={dirt|gravel} with a value for
tracktype, if that helps at all.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=ground/dirt/earth

[Richard Welty]

On 3/14/14 4:05 PM, Fernando Trebien wrote:
> Well, any information you add does help. If you could use something
> more specific than "dirt" ("gravel" is more precise, for instance), it
> would be even better. (That's my point: "dirt" is good, something more
> is specific such as "compacted", "earth", "sand" or "clay" is even
> better). 
in US usage, dirt is considered as different from gravel; i don't see the
confusion there. i'll grant that clay could be added to the list; we don't
tend to have clay surfaced roads in the northeast so much, but in large
parts of the southeast, it could make a difference.

but i seem to recall that we have had a discussion like this recently that
was ultimately unproductive. i would really would hope that we can
avoid a similarly protracted and unsuccessful discussion this time around.
i don't really understand the problem with using dirt as a value, i think
that it's pretty clear.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tags on areas containing highway=*

[Richard Welty]

On 3/20/14 6:33 AM, Peter Wendorff wrote:
> Personally I would consider routers to be buggy when they ignore
> barriers tagged on nodes of the way, while I would accept them not to do
> geometrical calculations between areas and ways.
>
absolutely they are buggy. here is one example from my own personal
mapping experience; a public road with a gate intended for access by
emergency services only:

 http://osm.org/go/Zdp4x2JHR-

i've seen a couple of features of this sort in the course of
mapping.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Issues relating to URIs and tagging

[Richard Welty]

On 4/1/14 1:01 PM, Andy Mabbett wrote:
> I'd be happy to do that; what do others think? While semantically
> correct, I think more mapper might understand "URL". 
is it a URI or a URL? if it's strictly a URL, that's fine, URL as a term is
not deprecated, it's merely a subset of URI. but if you intend to
be able operate on the URN side of the URI house, then you need
to use URI properly.

as for ref, i think that the door to the barn has been open
for a long time and it may be challenging to accomplish a
general fix. i think instead that for specific entities that use
ref (e.g., highways) you'll get farther by specifying what ref
means for the class of entity.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Richard Welty]

On 4/3/14 6:06 PM, Richard Z. wrote:
> On Thu, Apr 03, 2014 at 10:49:56PM +0100, Dave F. wrote:
>>
>> Really? Are you sure you're not just making this up?
>>
>> Show us where or I'm calling you a fibber.
> How much more stupid do you want to get if you don't use the basic
> search function.
>
> http://wiki.openstreetmap.org/wiki/Advanced_relationships
> http://wiki.openstreetmap.org/wiki/Key:layer
umm, the term only seems to appear here. google does not
find any references to it. from this i have to assume that the
term "brunnel" is something that was proposed and maybe
even standardized, but never gained traction.

i am not persuaded by the arguments for this
tagging scheme.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Richard Welty]

On 4/4/14 5:51 AM, Simone Saviolo wrote:
> Stop saying GPS. Forget even about aerial imagery. When I had no aerial
> imagery in my area, I either did not draw such features (leaving them for
> future improvements), or approximate. "The road there is about 6 meters
> wide, so I'll draw two nodes about 6 meters apart, split the waterway there
> and tag the middle piece as a culvert". It's not that hard, it's not that
> much imprecise, sure it may be improved with better measurements, but it is
> not wrong, especially it is not topologically wrong.
>
and if you are not sure about the extent of the structure or its nature
there's no harm in nipping out a short section, setting layer=1 and
skipping the other tagging (bridge=yes or whatever.) you have
accurately represented what you know and maintained correct
topology.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Richard Welty]

On 4/5/14 4:52 PM, John F. Eldredge wrote:
> You are being asked, is the word "brunnel" one you coined, or is it in use 
> already by other people?  Pointing to a page you wrote is not an answer to 
> the question.
>
>
it appears to me that brunnel is defined in the GDF (Geographic
Data File) format. but the term seems to have no real world
traction. Suggesting Richard Z made it up is inappropriate, but
suggesting the term is in widespread use would be wrong as well.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] noexit=yes on ways ?

[Richard Welty]

On 4/9/14 7:19 AM, Pieren wrote:
> On Wed, Apr 9, 2014 at 12:51 PM, Ronnie Soak
>  wrote:
>
>> There can be a way that IS connected on both ends and still is a dead end. A
>> road can end in a wall or a fence, where on the other side the road
>> continues.
>> There may be other tags there (barrier=*), but still it would be hard to
>> quickly spot the dead end side with noexit=yes tagged only on the way
>> instead of the node.
> No. In such cases, only the "barrier" tag is important. No additional
> tag required.
i would generally add an access tag as well, to the barrier node.

not all the routing engines handle this correctly at the present time,
but i'd prefer to tag correctly and expect the data consumers to
catch up.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] noexit=yes on ways ?

[Richard Welty]

On 4/9/14 8:51 AM, Ronnie Soak wrote:
> As a means to communicate an intention from one mapper to the next, it
> simply is more clear when mapped on the node than on the way. I simply
> gave an example where the end of the dead-end way can not simply be
> deduced by its geometry. Regards, chaos
i honestly don't think we need this kind of redundant
tagging when we can simply put notes to the next mapper
using a generic key, like, for example, README or fixme
or description?

what makes no_exit so special that it needs its own key
for this purpose?

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] noexit=yes on ways ?

[Richard Welty]

On 4/9/14 9:13 AM, Pieren wrote:
> On Wed, Apr 9, 2014 at 3:05 PM, Richard Welty  wrote:
>
>> what makes no_exit so special that it needs its own key
>> for this purpose?
> Once more, it's only useful for QA tools checking highway
> intersections geometry where one of the highway is nearby but not
> connected. The "noexit" tag is disabling the warning report when the
> highway is really not connected.
>
i'm hearing two stories here. this story is better than "note to the next
mapper", as the next mapper may never scroll down and see no_exit

but when do you remove the no_exit, or do you leave it forever for
the validators? the DB developer in me doesn't like redundant
information, all it does is create confusion if the data is in
conflict.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] direction=forward/backward on nodes ?

[Richard Welty]

On 4/12/14 5:57 PM, Colin Smale wrote:
>  
>
> Have to disagree here. There are plenty of real uses for reversing a
> way, and not everyone uses JOSM. 
>
> Colin 
>
> On 2014-04-12 22:43, Janko Mihelić wrote: 
>> Does anyone else think that the "reverse" tool should be removed from 
>> editors? There's no real use for it, and it only gives us problems when new 
>> mappers use it. If someone really needs it, they can download a JOSM plugin.
>>
i agree as well. i use the reverse tool, well, not all the time, but
frequently enough
that i think it definitely belongs in the editors.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] small change to turn restriction relation tagging

[Richard Welty]

i would like to add emergency (for emergency vehicles) to the list of
vehicle types for the except tag.

this doesn't seem like it should be a major or controversial issue,
but i'd like to hear any objections/suggestions

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] small change to turn restriction relation tagging

[Richard Welty]

On 4/22/14 8:03 PM, Tobias Knerr wrote:
> On 22.04.2014 23:46, Richard Welty wrote:
>> i would like to add emergency (for emergency vehicles) to the list of
>> vehicle types for the except tag.
>>
>> I don't think this would cause any problems, so I don't have any objections.
>>
>> However, I think it would be better in the long term to use the
>> "Conditional restrictions" syntax for turn restrictions, too.
>>
i see the value in the conditional restrictions, but since the actual
use case i have in mind (no u-turns where emergency vehicles are
explicitly authorized to ignore the restriction) is an exception,
using except seems like the correct way to model the situation.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] small change to turn restriction relation tagging

[Richard Welty]

On 4/23/14 10:14 AM, André Pirard wrote:
> On 2014-04-22 23:46, Richard Welty wrote :
> > i would like to add emergency (for emergency vehicles) to the list of
> > vehicle types for the except tag.
> Supposing that emergency vehicles can do almost everything (who would
> tell a fire van for example not to drive on the wrong side over some
> distance or make a forbidden turn if that's to put out a fire without
> endangering other road users), I think that routing devices should
> apply special logic for them to disregard most restrictions.  Hence,
> what should be on the map instead is restrictions that they should
> obey despite that, sort of telling them "if you disregard this, you
> won't put out your fire".
if this is the case, then it needs to be explicit in the wiki
so that routing engines can handle it.

i'm not sure that it is generally the case. i have looked it up in
New York State law and it is certainly true in this jurisdiction, but
for the US at least, it'll be state by state.

the signage in some other states in the US for restricted U-turns has
an explicit authorization posted at each U-turn. i honestly don't
have a feeling for how general the notion that emergency vehicles
can ignore all access restrictions really is.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access=public and access=yes

[Richard Welty]

On 5/11/14 5:48 AM, Martin Koppenhoefer wrote:
>
>> Am 10/mag/2014 um 19:19 schrieb bulwersator :
>>
>> Is there any difference between access=public and access=yes?
>
> I am not aware of any, seems synonymous to me in the access context, suggest 
> to normalize to yes
>
i concur.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] capital and state_capital: how are they being used in your country?

[Richard Welty]

On 5/15/14 8:57 AM, Pieren wrote:
> On Thu, May 15, 2014 at 2:23 PM, Matthijs Melissen
>  wrote:
>
>> Some more strange cases:
> We could create an additional role (e.g. "capital") when the
> "admin_centre" is not the capital (and only in this case to avoid
> unnecessary duplicates).
some definitions to keep in mind:

capital - a city serving as a seat of government

capitol - building in which a state legislature meets

these are US usage, not sure if British usage is different.

http://www.50states.com/tools/use.htm#.U3S811hdX4o

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OpenStreetMap] #5163: paths and tracks rendering indistinguishable: your opinion?

[Richard Welty]

replying to tagging, it's the only one of these lists i'm on

On 5/19/14 12:12 PM, André Pirard wrote:
> Hi,
>
> This is about OSM ticket  https://trac.openstreetmap.org/ticket/5163:
>> The rendering of highway=path and highway=track is barely
>> distinguishable.
>> For example, many huge width highway=residential continue to an extra
>> thin =track and then invisibly change to a =path.
>> Just like on my National Geographic maps, I suppose that
>> highway=track should be drawn with a distinguishable width something
>> like half that of residential highways. 
> On 2014-05-19 10:18, OpenStreetMap wrote :
>>  I don't think path and track are barely distinguishable.
> Ahem! Am I blind, is it just me or what?

there have been a number of good replies. i'll add in something i don't
think
others have addressed...

the default mapnik rendering on openstreetmap.org will never, ever be
able to
satisfy everyone. there's a reason why OSM has a strong architecture of
map database, a well defined api/data interchange format, and multiple
data consumers (renderers, indexes, routing engines, etc.)

the track and path issue you identify is a subtle one, and like others,
i suggest
experimenting with potential improvements and if you get something better
going, present it. "make this better" is kind of an open ended, what
does better
mean anyway sort of deal.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency Access

[Richard Welty]

On 6/15/14 11:07 AM, Andreas Goss wrote:
> So I got a bit of work done with the WikiProject Emergency Cleanup,
> but now I'm not really sure about emergency access.
>
> - Is there a difference between service=emergency_access,
> access=emergency and emergency=yes(on roads)?
>
i'm not familiar with service=emergency_access
emergency=yes is what we're supposed to be using in association with
access=no or access=private
access=emergency is not so far as i know standard, i used it a lot and
have been meaning to go
back and convert the ones i entered to use emergency=yes

> - What exactly is their meaning? Is it only for designated emergency
> access roads (https://de.wikipedia.org/wiki/Feuerwehrzufahrt)?
>
it's appropriate to use it for connectors for motorways that are clearly
signed no u turn.

> - Or was it meant for roads, which bascially had access=no, but
> allowed for only emergency vehicles?
>
this case is my interpretation.

you need to be a little careful about "emergency vehicles can drive
anywhere". under NY state
law, for example, emergency vehicles have carte blanch to ignore any
sort of turn or
directional restriction, but fire department officers are often wary of
actually doing this
due to the risks involved. on the other hand, they certainly will use
turn arounds like
the no-u-turn u turns on the motorways. emergency services routing is a
tricky business
that i'm still feeling my way around.
>
> The only thing I could find apart from a mention on the access=* page
> was this proposal:
> http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_vehicle_access
>
>
> I'm considering starting a proposal for something like
> access:emergency=yes/no/designated/..., because using access=* means
> you can't combine it with a different access attribute and‎
> emergency=yes says very little and is also used on other things.
the current situation of overloading of emergency= does present some issues.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency Access

[Richard Welty]

On 6/15/14 1:22 PM, André Pirard wrote:
> On 2014-06-15 17:07, Andreas Goss wrote :
>> So I got a bit of work done with the WikiProject Emergency Cleanup,
>> but now I'm not really sure about emergency access.
>>
>> - Is there a difference between service=emergency_access,
>> access=emergency and emergency=yes(on roads)?
> As I recall my readings without reviewing them,
>
>   * there is a strange situation with access=emergency because there is
> IMHO no GPS setting for emergency vehicles to follow. They would
> certainly not rely on them anyway if OSM people laugh at people who
> believe in OSM GPS and hence at themselves.
one of my goals for my Emergency Services project is a plugin for OsmAnd
that would actually use these access tags.
>  And emergency vehicles
> are prone to disregard traffic rules anyway, who would blame for
> carefully doing that people who save lives and sometimes risk their
> lives for us,
actually, at least around here, emergency vehicles are very reluctant
to ignore restrictions even though by NYS law they may legally do so;
they are very aware of the potential risks involved in ignoring them.
i base this opinion on the many discussions i have had with fire fighters
and fire chiefs over the past several years on this very topic.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic question about functional classification of highways

[Richard Welty]

On 6/17/14 5:24 AM, Philip Barnes wrote:
> The number should be tagged, and I would not expect a data consumer to use 
> maxspeed tags, they are useful for validation.
>
there are any number of reasons why a consumer might use a
maxspeed tag, the most obvious of them being a routing engine
attempting to approximate a fastest route.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic question about functional classification of highways

[Richard Welty]

On 6/17/14 8:24 AM, SomeoneElse wrote:
>
> * I've yet to see a bicycle router enforce the "(pedalling) furiously"
> implications of
> http://www.legislation.gov.uk/ukpga/Vict/10-11/89#pb3-l1g18  , for
> example!
i think there's a lot of interest in pedestrian and cycling routing,
but it still has a long way to go. we should be providing for it
because it is coming (eventually).

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "No abbreviations in names" edge case

[Richard Welty]

On 6/18/14 8:28 AM, Florian Schäfer wrote:
> What about the homepage of the city [1]? There it says that "The actual
> name comes from the fact that our town site on a strip of Cherokee land
> famous for the Oklahoma Land Run. The name stands for *Indian Exchange
> Land*".
in this case, i'd argue that the abbreviation is the name
and you could use note= or something like that to note
the origin of the name.
richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerodrome types

[Richard Welty]

On 7/6/14 1:55 PM, John F. Eldredge wrote:
> I know of at least two such in the Nashville, TN, USA. One is Nashville 
> International Airport, with passenger, air freight, and general aviation 
> usage, as well as a military compound. The other is a former military base in 
> Smyrna, TN, still containing a small military compound, but mostly now used 
> for general aviation and chartered flights.
>  
>
> On July 3, 2014 11:00:45 AM CDT, John Sturdy  wrote:
>> On Wed, Jul 2, 2014 at 9:46 PM, Janko Mihelić 
>> wrote:
>>> I don't like this way of mapping. There might be some overlaps, what
>> if one
>>> aerodrome has a military and a public part?
>> Agreed -- I know at least one that is.
>>
>> __John
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging


-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerodrome types

[Richard Welty]

no need for lots of anecdotes. it is very, very common for National Guard
and Reserve units in the US  to share airports with civilian services. i
could
name a bunch, but i don't think it's necessary, we've all seen the military
facilities while looking out the windows while our flight is taxiing.

richard


On 7/6/14 1:55 PM, John F. Eldredge wrote:
> I know of at least two such in the Nashville, TN, USA. One is Nashville 
> International Airport, with passenger, air freight, and general aviation 
> usage, as well as a military compound. The other is a former military base in 
> Smyrna, TN, still containing a small military compound, but mostly now used 
> for general aviation and chartered flights.
>  
>
> On July 3, 2014 11:00:45 AM CDT, John Sturdy  wrote:
>> On Wed, Jul 2, 2014 at 9:46 PM, Janko Mihelić 
>> wrote:
>>> I don't like this way of mapping. There might be some overlaps, what
>> if one
>>> aerodrome has a military and a public part?
>> Agreed -- I know at least one that is.

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Aerodrome types

[Richard Welty]

On 7/6/14 3:41 PM, Fernando Trebien wrote:
> How about using "aerodrome=*" to express how the aerodrome is used by
> civilians and then add "military=yes" when the airport is also used
> for military operations?
>
you could potentially broaden it a bit, with military=yes being the
generic "i have no more data" tag:

military=reserve
military=nationalguard
military=militia
military=air_force
military=army
military=navy

(in the US national guard is not automatically redundant with
militia; NY state for example has militia units that are distinct
from the guard units.)

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Distinction between amenity=restaurant and fast_food

[Richard Welty]

the common rule of thumb is counter service vs. table service. even
so, there are occasional grey areas (e.g., at Hardees you order at
the counter but they deliver to your table, still fast food in my book.)

and it produces slightly quirky results, for example the most excellent
deli Gershon's in Schenectady has table service but the most excellent
deli Maurice's in Albany has counter service. they are otherwise very
similar restaurants. it kind of makes you wish we didn't have fast_food
and instead had detailed tags, as another suggested.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Distinction between amenity=restaurant and fast_food

[Richard Welty]

On 8/3/14 12:52 PM, Andy Mabbett wrote:
> On 3 August 2014 15:43, Richard Welty  wrote:
>> the common rule of thumb is counter service vs. table service
> Citation?
it's been discussed extensively in the past and that was where
the discussion settled. sorry no direct citation other than the
mailing list archives.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Distinction between amenity=restaurant and fast_food

[Richard Welty]

On 8/3/14 4:19 PM, Tod Fitch wrote:
> On Aug 3, 2014, at 12:34 PM, Andy Mabbett wrote:
>
>> Your comment suggests that "fast food" and "restaurant" are mutually
>> exclusive; they are not.
>>
>> Google finds "about 5,110,000 results" for "fast food restaurant",
>> with quotes; the first of which is the Wikipedia article:
>>
>>https://en.wikipedia.org/wiki/Fast_food_restaurant
>>
>> We should probably tag something like:
>>
>>amenity=restaurant
>>restaurant_type=fast_food
>>cuisine=pizza
>>
> +1 on this, though I might go for restaurant:type=fast_food rather than 
> restaurant_type=fast_food.
>
> The phrase "I know it when I see it" comes to mind. 
> https://en.wikipedia.org/wiki/I_know_it_when_I_see_it 
still doesn't address the problem of fast food properly.

restaurant:service=counter|table

focuses on something that objectively verifiable, much better than "i
know it when i see it."
>
> 2. Does the establishment has a license to sell alcoholic beverages? No 
> implies fast food.
not true for european fast food franchises that sell beer.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bitcoin: Distinction of purchase through website and cash register/Point of sale

[Richard Welty]

On 8/12/14 2:55 PM, Anita Andersson wrote:
>
> One idea that got proposed was payment:online:bitcoin=yes/no +
> payment:offline:bitcoin=yes/no
> where online=purchase through website and
> where offline=cash register/Point of sale
>
why not payment:point_of_sale:bitcoin=yes/no

payment:offline doesn't seem quite right to me.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RENDER

[Richard Welty]

On 8/15/14 1:09 PM, Shawn K. Quinn wrote:
> This is just as bad as HTML 3.2's FONT tags and similar presentational
> junk. It's an excuse to add more garbage to the database, and I don't
> see the value it adds. The rendering does need to improve and be aware
> of new tags, but this doesn't help that one bit. 
it looks like a recipe for chaos to me.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] problem with bicycle=designated

[Richard Welty]

On 8/18/14 9:20 AM, Volker Schmidt wrote:
>
> So how one should tag in following situations?
>
> 1) official cycleway
>
> bicycle=designated or official
> This implies in many countries the obligation to use the cycleway if
> running parallel to a road
official is not in the wiki here:
http://wiki.openstreetmap.org/wiki/Key:access
designated is in the wiki, i suggest that it is therefore preferable.

i have seen a different interpretation of official, which indicates that
it is
for "official" vehicles. perhaps this ambiguity is another reason to
steer clear
of it.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] problem with bicycle=designated

[Richard Welty]

On 8/18/14 9:42 AM, Mateusz Konieczny wrote:
>
>
>
> 2014-08-18 15:36 GMT+02:00 Andre Engels  >:
>
> > 1) official cycleway
> highway=cycleway
>
>
> What about something that is both footway and cyleway (segregated or
> not segregated)?
>
these are common around here (upstate NY) and my preference has been to
tag like this:

highway=path
foot=yes
bicycle=yes

(or maybe designated.)

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RENDER

[Richard Welty]

On 8/20/14 8:33 AM, André Pirard wrote:
>
> Hence, the general consensus is either to tag for the renderer or not
> to tag such touristic POIs at all.
> It's strange to have to campaign for tagging !!! 
this proposal completely breaks the model of decoupling the factual
mapping database from the data consumers and their choices. there
are more data consumers than just the front page on www.openstreetmap.org
and they may be making very different rendering choices based on their
requirements.

this render tag notion, if it were to be adapted, would be ignored by a
lot of the
data consumers with good reason.

you need to get away from this notion that mappers should be able to force
data consumers to pay attention to their interests; there will always be
lots of
things in the database that don't get rendered in one place or another.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "floating" or "pontoon" bridges?

[Richard Welty]

On 9/2/14 1:12 PM, Martin Koppenhoefer wrote:
>
> 2014-09-02 17:46 GMT+02:00 Clifford Snow  >:
>
> Then again if I made a pontoon out of concrete, they'd just sink.
>
>
>
>
> While I generally agree with your agreement, this is not true, ships
> can be built out of concrete (think aircraft carriers for instance),
> and German universities even hold a regular competition who builds the
> best canoe out of (fibre)cement: http://www.betonkanu-regatta.de/
the British built two whole artificial harbors during WWII using
concrete pontoons:

http://en.wikipedia.org/wiki/Mulberry_harbour

https://www.flickr.com/photos/nfgusedautoparts/sets/72157607171004437

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Richard Welty]

On 09/20/2014 12:41 PM, fly wrote:

Am 20.09.2014 18:32, schrieb p...@trigpoint.me.uk:

  I would have gone for hall_of_residence.

Do not know if hall_of_residence is the right term.


hall_of_residence would work. i would have proposed the
shorter, less formal term residence_hall which is what you
will find in US usage.

richard


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Richard Welty]

On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
I would like to suggest making the paved key for highways (and 
probably other types of elements) official. Taginfo for paved:


http://taginfo.openstreetmap.org/keys/paved#values

The above shows that the key is already being used, but the Wiki 
doesn't describe this key, instead redirecting Key:paved to the 
article about Key:surface.





-1

duplicative

richard
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] name and brand tags

[Richard Welty]

On 09/24/2014 10:22 AM, Philip Barnes wrote:
Besides in my experience petrol stations do have a name, it may not be 
obvious until you are close to the shop. Other than supermarket petrol 
stations, the name of the petrol station will appear on your receipt, 
not the name of the oil company. Phil (trigpoint)


true, but are we better off with that in operator= than in
name= ?

richard


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] what does maxheight=none mean?

[Richard Welty]

On 10/27/14 6:45 AM, Tom Pfeifer wrote:
You are quoting me out of context, leaving the impression that I'd 
propose

to tag the bridge way, this is not the case.

I was just pointing out that tagging the way under the bridge makes
no explicit reference to the bridge itself, and can lose the implicit
proximity reference when the way is split. An explicit reference would
need a relation.

since the height restriction only applies to the segment of road directly
underneath the structure, i have always been careful to split the way
on either side, fairly close to the structure before adding the tag.

it seems like the only sensible way to do this.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] what does maxheight=none mean?

[Richard Welty]

On 10/27/14 6:17 AM, Martin Koppenhoefer wrote:


2014-10-27 11:04 GMT+01:00 moltonel 3x Combo >:


The maxheight=* tag maps the physical limitation, not the sign (which
can be absent or even wrong). Tagging maxheight=none really makes no
sense.



no, the maxheight tag maps the legal restriction (typically derived 
from a sign, in absence of a sign might be implied by other legal 
provisions). For physical restrictions use maxheight:physical (in some 
countries this is even signed). For the actual clearance height we 
could still use another tag like "height" (maybe better not, as this 
would IMO imply the height of the road, i.e. from the surface 
downwards) or more explicitly "clearance_height".
in the US, the default behavior is that the signed max height has a 
couple of inches to spare.
if there is no margin then it's considered an actual maxheight which 
naturally would map to


maxheight:actual

i have no idea what usage is in the UK

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging