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] 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

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=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] 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

[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

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

[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] 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

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 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

[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] 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] 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] 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] 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]

> 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] 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] åååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååååå

[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] 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] reviving hollow way

[Richard Welty]

On 2/19/18 6:37 PM, Martin Koppenhoefer wrote:
>
> On 19. Feb 2018, at 22:28, Richard Welty <rwe...@averillpark.net
> <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=h_=images=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] 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] Feature request - nascar=*

[Richard Welty]

On 11/19/17 7:07 PM, ralph.ayt...@ntlworld.com wrote:
>
> I also noticed that. In fact the example given in the proposal
> http://www.openstreetmap.org/#map=19/25.45387/-80.40864 is the
> Homestead-Miami Speedway which hosts not just Nascar but a whole range
> of different events by different companies and sponsors,(IndyCar
> Series, Sports Car Championships see
>  https://en.wikipedia.org/wiki/Homestead-Miami_Speedway). So the
> facilities at the race track would be used by all of these events and
> not just for Nascar.
>
>  
>
> They should be tagged as parts of the race track and not as the
> operator of only one single event that takes place there.
>
this is correct. NASCAR is a sanctioning body that does not directly own any
race tracks. if we wanted to tag sanctioning bodies it would need to be a
separate tagging scheme. since sanctioning body/track relationships can be
quite fluid, it's a very poor candidate for tagging in OSM.

we already have fairly functional tagging for race circuits. i could
imagine some
tweaks but i don't think we really need 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] Fire_hydrant: check_date

[Richard Welty]

On 9/12/17 6:44 PM, marc marc wrote:
> Le 12. 09. 17 à 22:52, Viking a écrit :
>> In the discussion page [0] someone says that check_date=* is a synonymous of 
>> survey:date=* in common usage. Is this correct? Should we use another tag 
>> functional_check=* ?  But I don't like to introduce a new tag.
>>
>> [0] 
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions#check_date_is_used_in_a_different_meaning_here
> I launched a discussion on the French mailing last week to know
> the exact meaning of those who use it.
> wiki said "when the object was checked and verified"
> but what is checked ? a survey to see it ?
> a survey to check the info sign on the hydrant ?
> a opendata database ?
> including or not a functional check ?
> currently, nobody known.
in the US, your better fire departments do flow tests on every hydrant
on a 3 year cycle to verify output. what the tag means should definitely be
spelled out at some level of detail.

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] Elevation in Feet as part of Peak Names

[Richard Welty]

On 9/8/17 9:34 AM, Richard Welty wrote:
> On 9/8/17 7:08 AM, ael wrote:
>> On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:
>>> User Raymo853 and I are having a friendly discussion on changeset
>>> 50470413[1]. He has been adding the elevation of mountain peaks (in feet)
>>> to the name tag. For example, he changed "Crown Point" to "Crown Point
>>> 11,463 ft."[2] While the wiki doesn't specifically address the issue of
>>> elevation as part of a peak name, it does say "Name is the name only"[3].
>>>
>>> Could we get feedback from the wider community on this?
>> +10 for elevation only in the ele tag.
>>
>> As surveying improves or plate tectonics changes, it would be ridiculous
>> to change the name rather than just the elevation.
> adding the elevation to the name tag makes life far more difficult for data
> consumers. don't do it.
to amplify my point, there is a universe of extant and potential data
consumers;
some consumers are humans looking at the map on the website, but other
consumers
are generating GPS maps or other automated things with software. adding
elevation
to the name is a symptom of tagging for the website.
we need to watch continuously for folks who are tagging in this manner, and
get across to them why it shouldn't be done this way.

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] Elevation in Feet as part of Peak Names

[Richard Welty]

On 9/8/17 7:08 AM, ael wrote:
> On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:
>> User Raymo853 and I are having a friendly discussion on changeset
>> 50470413[1]. He has been adding the elevation of mountain peaks (in feet)
>> to the name tag. For example, he changed "Crown Point" to "Crown Point
>> 11,463 ft."[2] While the wiki doesn't specifically address the issue of
>> elevation as part of a peak name, it does say "Name is the name only"[3].
>>
>> Could we get feedback from the wider community on this?
> +10 for elevation only in the ele tag.
>
> As surveying improves or plate tectonics changes, it would be ridiculous
> to change the name rather than just the elevation.
adding the elevation to the name tag makes life far more difficult for data
consumers. don't do it.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/27/17 6:59 PM, Dave Swarthout wrote:
> I can respond to tell you what seems most familiar to me, a native
> American English speaker: flow_rate in gallons/sec or per minute. Now,
> that being said, I am all in favor of avoiding the archaic system we
> still use in the U.S. and using a default flow_rate in cubic
> meters/second (or per minute) or alternatively cubic centimeters/sec
> (cc/sec). 

default to SI units is fine. local units should be permissable.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/21/17 12:58 PM, Colin Smale wrote:
>
> IIRC a Dry Riser in the UK goes from ground level UP to the higher
> floors, so AFTER the fire services's pump, and not from a water source
> up to the pump.
>
> http://www.highrisefirefighting.co.uk/dr.html
>
i think this is correct, a dry riser is not the same as a pipe for water
supply from
a pond or stream.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/20/17 4:22 PM, Moritz wrote:
> Just one more thing:
>
> Dry and wet barrel hydrants are both pillar type hydrants.
>
> What about tagging both as fire_hydrant:type=pillar
> and something like
> pillar:type=dry_barrel|wet_barrel
>
> So the people who are just interested in the type of hydrants
> (underground, wall, pillar...) can evaluate fh:type tag. When somebody
> wants to know it in more detail he can check for pillar:type.
this is basically what my old proposal did.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/18/17 4:33 PM, Moritz wrote:
>
> Hi Richard
>> in actual real world usage, however, they are called dry hydrants by
>> their
>> users (the fire departments). they are even signed as "dry hydrants" in
>> many
>> cases. there's such a sign not far from me, i can go take a picture of
>> it.
> I think it's a language issue here.
> Here in Germany these dry hydrants are called suction point (actually the 
> German word for it) with proper signs. 
normal practice in these cases is to fall back on british practice.
i have no idea what that might be.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/17/17 10:25 AM, Eric Christensen wrote:
>
> That's not really what's being discussed here.  A non-pressurized
> hydrant wouldn't be attached to a tank at all.  It would require a fire
> engine to suck the water out.  It does not look like a traditional fire
> hydrant at all.
there are always exceptions. not far from me, there's a traditional
hydrant of the type normally used with pressurized systems, but
it's sourced from a pond. the reason is that the pond is elevated, some
distance from the road, and they need to keep the barrel empty
when it's not in use for the usual reasons.

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] Fire hydrants vs suction_point

[Richard Welty]

On 8/17/17 10:30 AM, Moritz wrote:
>
> I would rely on the Collins English Dictionary in this point rather
> then on wikipedia [1]
>
>> (General Engineering) an outlet from a water main, usually consisting
>> of an upright pipe with a valve attached, from which water can be
>> tapped for fighting fires. See also fire hydrant
>
> According to this definition a dry hydrant is not a hydrant because of
> the lack of connection to the water main.
in actual real world usage, however, they are called dry hydrants by their
users (the fire departments). they are even signed as "dry hydrants" in many
cases. there's such a sign not far from me, i can go take a picture of it.

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] service=access

[Richard Welty]

not sure we need a tag at all, but i'd recommend a more general notion
such as

service=facility_access

there are, after all, access roads for things like power lines, etc.

On 8/11/17 8:34 AM, Janko Mihelić wrote:
> I'm struggling to think of another use for any highway besides access.
> Maybe a scenic highway whose use is to look at surroundings while driving.
>
> I suggest service=pipeline_access.
>
> ned, 6. kol 2017. u 18:58 Dave Swarthout  > napisao je:
>
> You're probably right Gerd. I sometimes get too enthusiastic about
> adding tags to objects. The access tag is probably completely
> unnecessary. Still, I'm curious about why other mappers decided to
> use it.
>
>
>
> On Sat, Aug 5, 2017 at 8:49 PM, Gerd Petermann
>  > wrote:
>
> Hi Dave,
>
> my understanding is that most hw=service are used to access a
> specific man_made object, so this tag
> seems to be superfluous to me. I would simply not use the
> service tag here.
>
> Gerd
> 
> Von: Dave Swarthout  >
> Gesendet: Samstag, 5. August 2017 23:02:18
> An: Tag discussion, strategy and related tools
> Betreff: [Tagging] service=access
>
> Hi,
>
> I'm working on highway tagging in Alaska and am developing a
> preset to automate the tagging of the many gravel service
> roads that are used to access the Trans-Alaska Pipeline (TAP).
> I have never used the service=access tag and there is nothing
> in the Wiki about it but it would seem to be an ideal tag to
> use in my work because those roads are being used to get close
> to the TAP, in other words, to access it. Taginfo shows about
> 600 uses of the tag and most of those appear to be for unpaved
> service roads similar to the ones I'm seeing in my work.
>
> However, seeing as no documentation of the tag exists, I'm
> wondering if any of you have used this tag or have some
> insights to offer.
>
> As always, thanks in advance.
>
> Dave
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
>
>
>
> -- 
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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] fire hydrants

[Richard Welty]

in the section on the AWWA color scheme, i changed "tops" to "bonnet" as
bonnet is the
correct technical term for the "top" of a hydrant. do we want to add a
definition that makes
this clear?

On 8/4/17 3:55 PM, François Lacombe wrote:
> Hi Viking,
>
> I took some time to change a bit the proposal presentation without
> changing any of proposed points/keys
> https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions
>
> I found useful to add a values to be replaced at the bottom of the
> tagging chapter to give a better idea of what work will remain once
> the proposal accepted.
>
> I've also added a few comments on the Talk page
>
> All the best
>
> François
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com 
> @InfosReseaux 
>
> 2017-07-28 15:39 GMT+02:00 Viking  >:
>
> Hello.
> After two weeks on holiday, I'm back to discuss on fire hydrants
> proposal.
> I've updated the page [1] according to last comments about
> fire_hydrant:couplings_type and fire_hydrant:couplings_size.
> If you think it's ok, I will go on putting it on vote.
> Best regards
> Alberto
>
> [1]
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions
> 
> 
>
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> https://www.avast.com/antivirus 
>
>
> ___
> 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] amenity spamming?

[Richard Welty]

On 7/24/17 1:14 PM, Richard Welty wrote:
> On 7/24/17 1:04 PM, Tom Pfeifer wrote:
>>
>> I wonder what to do here. 
> you could contact him directly and ask him what he is trying to do, and
> attempt to gently dissuade him.
>
> if he is not amenable to reason, well, that's why we have the DWG.
following myself up. do NOT get in an edit war. that never turns out well.

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] amenity spamming?

[Richard Welty]

On 7/24/17 1:04 PM, Tom Pfeifer wrote:
> There is a user creating a large amount of strange wiki pages for
> "amenities" like
> television, microwave, washing machine, stool, seat, plant, fridge,
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dstool
>
> or tiny perishable objects like natural=flower
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dflower
>
> You find more via the page history -> username -> contribs.
>
> I wonder what to do about it, apparently he even maps some of those:
> https://www.openstreetmap.org/node/4944091271
>
> I wonder what to do here. 
you could contact him directly and ask him what he is trying to do, and
attempt to gently dissuade him.

if he is not amenable to reason, well, that's why we have the DWG.

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] fire hydrants

[Richard Welty]

On 6/15/17 10:02 AM, Viking wrote:
> About the wrench, Richard, we could create the subtag  fire_hydrant:wrench. 
> In Italy we have standard pentagonal or square wrench. What would you insert 
> in this tag? Type and size of the wrench? Something like:
> fire_hydrant:wrench=square30
> Or, like couplings, create fire_hydrant:wrench_type and 
> fire_hydrant:wrench_size?
the physical characteristic of the hydrant is the nut/bolt head, not the
wrench.

square, triangular and pentagonal seem to be the three that are out there.
i'm not sure the size is that important, the wrenches in use seem to be
adjustable.

other tagging notes while we're at it:

i have been using a few other tags in the capital district of new york.

i separate out pond because water source is really a different thing
than the type of hydrant; i've seen dry_barrel pillar hydrants used
with a pond water source. and i generally distinguish between the two
major variations of the pillar hydrant.

fire_hydrant:type=dry_barrel
  wet_barrel
  pipe


fire_hydrant:water_source=main
  pond
  stream

if a locality is using the NFPA paint scheme it's possible to discern
the class of hydrant from the color of the caps. in the US an AA hydrant
has been flow tested and shown to have a very high flow rate. A, B & C are
successively weaker hydrants. firemen have been known to ignore C hydrants
and go find better ones to hook up to.

fire_hydrant:class=AA

out of service hydrants are supposed to clearly marked, either with
a tag on the outlets, or by covering them with a bag:

in_service=yes

the colors of the bonnet (top) and caps on the outlets may or may not
convey useful information. depends entirely on the jurisdiction.

colour:bonnet=white
colour:cap=red

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] fire hydrants

[Richard Welty]

On 6/15/17 8:38 AM, Robert Koch wrote:
> Hello Richard,
>
> On 2017-06-15 01:32, Richard Welty wrote:
>> an american usage note:
>>
>> the "standard" hydrant in the US has 2 x 2.5" hose connections
>> and 1 x 4.5" pumper connection. other sizes have existed in the
>> past.
> Which coupling-type do you use? NST
> (https://en.wikipedia.org/wiki/Hose_coupling#NST)?
generally NST. the standardization effort in the US started immediately
after the catastrophic 1904 Baltimore high rise fire. companies coming
in from outside of the city found out that their equipement couldn't hook
up.
> If so one would describe this hydrant as:
> fire_hydrant:coupling_type=NST
> fire_hydrant:couplings=2.5;2.5;4.5
>
> Open: How do we reflect the unit? Millimetres won't work for the US.
> Possibilities:
> fire_hydrant:couplings=2.5";2.5";4.5"
>   OR:
> fire_hydrant:couplings=2.5;2.5;4.5
> fire_hydrant:couplings_unit=inch
the norm in OSM usually looks like

fire_hydrant:couplings=2.5in;2.5in;4.5in

but maybe spelled out (inch vs in), i'd have to check.
>> the wrench required for the bolt at the top of a dry hydrant may vary,
>> pentagonal bolts are most common but others have been used.
>> this is something that a mapper can observe, and something that
>> a fireman cares about.
> There is not yet a tag for this. In Austria a typical wrench looks like
> this: http://i.ebayimg.com/images/i/251745653405-0-1/s-l1000.jpg
> The left side is used to open the bolt at the top, while the right side
> can be used to open the cap of the hose couplings.
i'd need to do some research. there are a variety of wrench types available,
you can get an idea from the grainger website:

https://www.grainger.com/category/spanner-and-hydrant-wrenches/fire-protection/safety/ecatalog/N-kyk?okey=hydrant+wrenches=hydrant+wrenches=hydrant+wrenches=14=hydrant+wrenches=true=hydrant+wrenches

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] fire hydrants

[Richard Welty]

an american usage note:

the "standard" hydrant in the US has 2 x 2.5" hose connections
and 1 x 4.5" pumper connection. other sizes have existed in the
past.

the wrench required for the bolt at the top of a dry hydrant may vary,
pentagonal bolts are most common but others have been used.
this is something that a mapper can observe, and something that
a fireman cares about.


On 6/14/17 6:52 PM, Robert Koch wrote:
> Hello Alberto,
>
> I like your remarks and would like to work together to improve things.
>
> On 2017-06-14 19:06, Viking wrote:
>>> in OsmHydrant [1] there is already fire_hydrant:coupling_type with various 
>>> values from Storz to Barcelona
>>> (https://taginfo.openstreetmap.org/keys/fire_hydrant:coupling_type). Then 
>>> there is fire_hydrant:couplings to complement that, describing the > actual 
>>> connectors: https://taginfo.openstreetmap.org/keys/fire_hydrant%3Acouplings
>>>
>>> This implementation might not be the best for various reasons, but we could 
>>> consolidate its structure/values if needed.
>>>
>>> [1] https://www.osmhydrant.org/en/
>> It is a bad implementation: first of all because there is no reference on 
>> hydrants wiki page (and indeed I didn't know it) and consequentely there is 
>> a wide range of heterogeneous values that are almost useless for automatic 
>> data search.
>> By the way, let's try to improve these existing tags.
>> fire_hydrant:coupling_type indicates the standard (UNI, Storz,...)
>> fire_hydrant:couplings indicates the number and diameters.
>> Right?
> Right!
>> First question: is it possible that the same hydrant has different coupling 
>> types, for example Storz and UNI? I know that in Italy, where I work as 
>> fireman, this is not possible, so a single value in 
>> fire_hydrant:coupling_type is enough.
> In Austria I've only seen hydrants with one connector type (mostly Storz). S
>> Second question: how would you indicate the number of couplings? For example 
>> an hydrant with two UNI 45 mm couplings and one UNI 70 mm coupling would be:
>> fire_hydrant:coupling_type=UNI
>>
>> fire_hydrant:couplings=45;45;70
>> OR
>> fire_hydrant:couplings=2 x 45;70
>> OR...?
> So far it was really up to the contributor on OsmHydrant but the
> recommended way in this case have been so far:
> fire_hydrant:couplings=2x45/1x70
>
> Before going on, I've to explain the rationale behind using that scheme
> first. In Austria we're using character A for 110mm diameter, B for for
> 75mm and C for either 52 (or 42). In this case it looks easily readable:
> "1B/2C" or "1A/2B".
> When it comes to "2x45/1x70" I totally agree that "45;45;70" is much
> better. Back in time when doing the implementation for OsmHydrant, I
> didn't know about using the semicolon to split values, but I like it
> more than the forward slash.
>
> Coming back to the Austrian "1A/2B" I would additionally allow using
> these characters instead of diameter values as well resulting in: "A;B;B"
>
> If the proposal is accepted I'd propose migrating all values
> automatically and changing OsmHydrant. Your scheme with repeating the
> diameter is much better readable & parse-able by humans & tools.
>
> Best regards,
> Robert
>> I would prefer 45;45;70 because it's more explicit and less prone to errors.
>> The use of semicolons to separate different values is commonly accepted on 
>> the wiki.
>>
>> Alberto
>>
>>
>> ---
>> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
>> https://www.avast.com/antivirus
>>
>>
>> ___
>> 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] fire hydrants

[Richard Welty]

On 6/10/17 1:36 PM, Eric H. Christensen wrote:
> On June 10, 2017 12:23:22 PM EDT, Richard Welty <rwe...@averillpark.net> 
> wrote:
>>
>> in the US some localities paint their hydrants to reflect the diameter
>> of the main. this is not standard so you need to check with the local
>> districts.
>>
>>
>> Well, there is an NFPA color standard, IIRC, based on the flow rate of the 
>> largest diameter fitting on the hydrant. This is slightly different than the 
>> size of the main it is hooked to as a five-inch connection is going to flow 
>> more than a three-inch connection on the same sized main.
>>
>>  I've seen this used in larger municipalities; wish it was done more.
>>
in the capital district of new york, the NFPA standard is used in only
one case
that i've found, one of the 3 districts in North Greenbush.

by comparison, color coding based on water main diameter is used in Troy
and in the town of bethehem. further complicating matters is the fact
that while
the Troy scheme is wildly non-standard and unique, the Bethlehem scheme is
somewhat resembles the NFPA scheme (e.g. red bonnet and caps indicate
a small diameter main in Bethlehem and indicate flow rate under 500 GPM
in North Greenbush.)

other parts of the capital district are off in their own places. Albany,
Colonie and
Guilderland schemes are based on asethetics rather than any functional
scheme.

the short version is that there is useful information conveyed by color
schemes
- sometimes - but research may be needed to find out what that
information is.

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] fire hydrants

[Richard Welty]

On 6/9/17 5:18 PM, Marc Gemis wrote:
> o, I forgot to include the link to the picture.
> BTW for fire hydrants of the pillar type, it can in indicated on them
> as well, see [2] There is a BH100 on it, so the diameter of the
> underground pipe is 100 in this case
in the US some localities paint their hydrants to reflect the diameter
of the main. this is not standard so you need to check with the local
districts.

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] Mapping time zones as geometries (relations)

[Richard Welty]

On 3/6/17 11:21 AM, Paul Johnson wrote:
> On Mar 5, 2017 18:30, "Frederik Ramm"  > wrote:
>
> Hi,
>
>I would like to start a discussion about the mapping of time zones.
>
>
> What do you think?
>
>
> I'm generally opposed to mapping timezones in OpenStreetMap unless the
> tzdata maintainers are 100% on board.  Since timezones are a royal
> pain to keep track of, often changing 100+ times a year, on as little
> as a few hours notice in some cases.
>
i agree. this a perfect example of something that belongs in its own
database or
shape file, available to be overlaid on the map when it's wanted.

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] Mapping freeway stub ends?

[Richard Welty]

On 3/1/17 6:54 AM, Volker Schmidt wrote:
> The original example
> https://www.google.com/maps/@40.8190845,-76.8530417,857m/data=!3m1!1e3?hl=en-US
> 
> is now a set of ways that can be used as non-freeway highways. I would
> most likely tag them as either service or track with surface and
> tracktype tags. Important to check on the ground the access rights and
> add exact width, surface and smoothness tags.
> In addition I would tag them in addition with
> abandoned:highway=motorway if they were ever used as freeways (which
> seem not to be the case). I would not use the construction tag as this
> would mean that this is part of a freeway under construction.
the disused namespace makes a lot of sense for this kind of in between
circumstance. there are a few things in the Albany NY area that fall in
this category, like the stub ends of the Dunn Bridge which are there, and
have to be maintained because they're part of a heavily used bridge, but
are supposed to connect to a highway that will never be constructed.

https://osm.org/go/ZdrEu0QBY--

note that i just noticed the tagging was less than ideal, and tweaked it,
so the rendering may reflect the older tagging for a little bit.

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] Potential proposal for more detail in old_ref=*?

[Richard Welty]

On 2/27/17 4:58 PM, yo paseopor wrote:
>
> OK, with new tags, with new values, with new behaviour, but not
> outside OSM data because if there would be another "accident" or
> unafortunate facts the information will be inside OSM and other can
> start another render with these information. 
>
if we do our backups properly, then data will not be lost again. the
goal is for
backups to be in a number of places, separate from the main server, and
tested
so we are sure they're good.
> Think about Wikipedia: is wikipedia divided in kinds of information?
> All are at the same system, You have some portals but all the
> information is at the same place (for this reason an image in
> wikipedia is uploaded to commons).
> Historic information is so important...that I think all has to be at
> the same place (data). Renders is other thing, you can make whatever
> you want, featuring the information you want to. 
>
>
> so from my point of view, keeping the historic data in its own
> place is
> part of
> trying to keep OSM peace. did we have some problems? yes. are they
> correctable?
> yes. i think some lessons have been learned, but our takeaway is very
> different
> from yours.
>
>
> I don't know what is your takeaway. I'm a user, I'm a mapper, I'm a
> man who loves the history and I want that all my possible future work
> and the others won't be lost, and will be accessible...forever.
> Because that is about history. So more information, more historical
> information about refs would be interesting in OSM with the correct
> keys and values.
>
>
in the past many OSM users have expressed hostility to trying to load up all
this historic data in OSM. none of them have spoken up so far; hopefully
they
will do so and express their concerns & objections in an appropriate manner
(tagging is not always a friendly list, but this discussion has been
friendly so
far and hopefully it stays that way.)

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] Potential proposal for more detail in old_ref=*?

[Richard Welty]

just to insure that the correct facts are out there:

OHM was in a position where a new hosting arrangement needed to be worked
out, when a major server crash occurred. so we were literally twisting
in the wind
until those issues were resolved. there is no real external support for
the project
so we couldn't just go out and rent a server or VM somewhere.

the previous backup arrangements were inadequate, and files were truncated.
so i think 6-9 months worth of data (maybe 12 months) was lost. i'm in the
process of assessing what work i need to personally redo, but it doesn't
look
all that bad. i am working with Rob Warren on setting up a stronger backup
plan - but even if we'd had a stronger backup plan, the need to rehost OHM
would still have been an issue.

there are some advantages to a separate OHM.

a large part of the community thinks OSM should only be about current
data. if we started seriously doing the things we want to do in OSM, it
would
be pretty controversial with a potential risk of an edit war.

OHM can be a playpen for experimentation. i wish to work on a schema for
relations so that i can describe the movements of troop units in campaigns
and battles. again, if i started doing this in OSM, i imagine that the
unhappiness
would be extensive, and given the other goals of OSM, it's not really a good
place to play.

there is a need for need for tagging extensions for historical mapping.
this is
a tricky one. historical mapping needs some temporal language for which
current OSM tagging is completely inadequate. and given how the tagging
discussion goes some times, i think the tagging list is the completely wrong
place for such discussions - but if we are trying to keep historic data
in OSM,
this is where we would have to have it.

so from my point of view, keeping the historic data in its own place is
part of
trying to keep OSM peace. did we have some problems? yes. are they
correctable?
yes. i think some lessons have been learned, but our takeaway is very
different
from yours.

On 2/27/17 4:03 PM, yo paseopor wrote:
> Humanity is so curious. We make a mistake, we "receive" the
> consequences and we don't learn anything, and promote the same mistake.
>
> OHM was a good project...but had a bad choice: data outside OSM. Then
> the project had slept...and the information is , nowadays...lost?
> Well, the project woke up...but now...where is the "old" information
> of the same project?
> Compare it with http://histosm.org . Why this map is more complete
> than the other? Because all the info is IN OSM.
>
> Ok , it would be one situation, is not the normality...
> Think about http://parking.openstreetmap.de ...oh, isn't working? Oh,
> Did we lose the information? Well, you can use
> http://bit.ly/parkingosm because the data was inside OSM so you can
> make another render to show the information.
>
> So I think the right place for information is OSM's database. Then who
> wants can use data to make a render of that data.
> History is real and specific in a lot of things. So these things that
> one day existed or had that property should be in OSM. How...I don't
> know the best way, but it is important to make the information
> accesible to everyone, and in a easy way without the risk of losing
> information.
>
> Salut i història (Health and History)
> yopaseopor
> PD: I support this proposal or similars
>
>
> ___
> 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] Potential proposal for more detail in old_ref=*?

[Richard Welty]

On 2/27/17 2:46 PM, Albert Pundt wrote:
> The old_ref=* key seems to be used a lot for any previous designation
> of a road, even decades before. Often a road will have had different
> designations over the years. For example, I-676 in Philadelphia was
> initially designated I-80S from 1957 to 1958, followed by I-895 from
> 1958 to 1960, I-76 from 1960 to 1974, and today I-676 since 1974.
> There's no good way that I know of to represent all this.
>
> Though previous designations aren't useful for most users, it can
> still come in handy to map this data if someone wants to use OSM data
> to track a former route, for example.
>
> Ideally, a more detailed tag for I-676 would be something like this:
>
> old_ref=1957-1958 I 80S;1958-1960 I 895;1960-1974 I 76
>
> Would anyone else support such a proposal, or think it to be useful?
>
i don't think we want this data in OSM. OHM is coming back online thanks
to hard work by Rob Warren, and i think it's a more appropriate place for
this sort of data. i'm putting some old route information in the Albany NY
area into OHM rather than OSM.

if you must do this in OSM, i recommend using route relations with
start_date and end_date set rather than trying to overload the ways.
that's my solution in OHM when describing reroutes of signed highways.
you probably also want to put the keys in the right namespace so the
data won't inadvertantly be rendered in the "standard" OSM renderings.

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] Notary Office

[Richard Welty]

On 2/7/17 2:21 PM, Colin Smale wrote:
>
> On 2017-02-07 18:56, Richard Welty wrote:
>
>> office=notary just seems wrong to me, they're
>> rarely standalone in my experience.
>>
> Richard, in Europe they are almost always standalone, by definition.
> They need to be independent and impartial "by law". They have a
> protected role in many transactions including real estate and probate.
> "office=notary" would make perfect sense here.
>
which is fine for europe if that's the case. in the US, you go to your
bank or your lawyer's office if you want something notarized.

clearly there is no one size fits all tagging for this.

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] Notary Office

[Richard Welty]

On 2/7/17 12:13 PM, Martin Koppenhoefer wrote:
>
> yes, I can understand your frustration because apparently the makers
> of JOSM have hijacked the notaries and the numbers of "their" tag are
> now growing quite fast, due to the prevalence of JOSM. ;-)
>
> Please, take a step back and look at both tags, without insisting on
> the "first come first served" rule, are there really good arguments to
> tag notaries as subclass of lawyers? Why is a different "main tag"
> worse (in other words, say the same with one tag rather than 2, do not
> require "exotic" subtags like lawyer=* to be looked at)?
thing is, notaries may be found at banks, at lawyer's offices and many
other places in the US. office=notary just seems wrong to me, they're
rarely standalone in my experience.

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] 'ongoing' U-turn restriction

[Richard Welty]

On 12/8/16 9:34 AM, Greg Troxel wrote:
> Also, for what it's worth, in massachusetts.us, we have two kinds of
> solid yellow (center) lines.  One can pass with care give a single line,
> but may not cross the line or pass if double.
many states post explicit "no passing" signs at the beginning of sections
of road with solid yellow lines.

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] railway=rail vs. railway=subway

[Richard Welty]

On 11/23/16 9:09 AM, Greg Troxel wrote:
>
> One of the tricky things, as Bill Ricker points out downthread, is
> Boston's Green line. This is fundamentally light rail. Sometimes it
> runs in tunnels. Sometimes it runs in a fenced-off median but does
> have level crossings. These are controlled by stoplights (for both
> train and cars), rather than train-priority crossing gates. And
> sometimes it runs on tracks in the street where cars also drive. 
even more so, the MBTA considers the Green line a subway even though
it's mostly above ground. i found this remarkably confusing when i took
it into BU for a meeting a month or so back.

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] Tagging of Country Names

[Richard Welty]

On 11/5/16 10:58 AM, Martin Koppenhoefer wrote:
>
> interesting case, because it is an example that "official languages"
> can be set on sub-country level as well (many states have defined
> English as their official language).
> It could also be argued that English is the defacto official language
> in the USA, even if there is no law that states this, because all
> legislation and jurisdiction (?) takes place in English (I am not sure
> about this, maybe Native American Reservations etc. have different
> languages?).
i'm sure the tribes probably regard their own languages as "official". given
the peculiar status of the reservations (sovereign except for when congress
decides they're not) i can't say i really know how that issue resolves.
(it also
makes admin boundaries nasty - are they separate nations or aren't they?)

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] test track tagging (vs highway=raceway)

[Richard Welty]

On 11/2/16 2:34 AM, Tijmen Stam wrote:
>
> To add in, at  we
> have a nice collection of circuits, from northeast to southwest:
> * The RDW (state office for road traffic) test track, marked mainly as
> highway=service but some raceway
> * A cart track (marked as raceway) with associated dirt track (not
> marked other than with land use)
> * The ANWB (driver's club, say AAA) driver's training track (not for a
> driver's permit but for anti-slip training etc), most marked as raceway
> * A seemingly commercial (or non-profit) race track, marked on their
> site as "for events, tv-productions and races", all actual track
> marked as raceway, but the small connecting bits as service, with a
> dirt track only marked by landuse
my normal race track tagging rule of thumb is to use highway=raceway for
"hot"
areas (places where race cars are expected to be at speed), which
includes the
pit lane, and then use highway=service for low speed access roads.

racing karts is real racing, so i use highway=raceway for kart tracks.

and i think that dirt courses that have some sort of permanent status and
are used for competition are deserving of highway=raceway 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] Tagging of Country Names

[Richard Welty]

On 10/25/16 2:44 PM, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> Il giorno 25 ott 2016, alle ore 17:02, Sven Geggus 
>>  ha scritto:
>>
>> So I propose a correction of all country names to names into official 
>> langages of
>> the respective countries only and to remove all english names.
>
> how are you going to determine the official language, and are you aware that 
> there are areas where on the ground a different language than the "official" 
> one is used?
consider Belgium, with two distinctly different language groupings, both
representing a sizeable portion of the population. and consider Switzerland
where a number of different languages are spoken in different parts of the
country. and this is just western europe...

"the language spoken in a country" in more than one case does not have one
correct answer.

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] test track tagging (vs highway=raceway)

[Richard Welty]

i don't have a particular proposal in mind for this, just looking for input.

there are various tracks in the world that are not used for racing, but
for testing only. major auto manufacturers have their own tracks, and
independent organizations do too (for example, the US publication
Consumer Reports has converted an old drag racing complex in CT into
their own private test facility. likewise i believe there is a small private
test facility on the grounds of the old Brooklands oval in the UK.)

what kind of tagging do folks think is appropriate for these?

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] Proposal for motor racetracks

[Richard Welty]

On 10/17/16 4:04 PM, Lorenzo Mastrogiacomi wrote:
> leisure=sports_centre is a feasible alternative, but motor sports are
> not mentioned in its actual definition and I'm not sure that an
> extension of its meaning would be appreciated by all.
> The numbers also show that only about a quarter of users preferred this
> tag over others that seem less suitable.
>
> Is in english "sports centre/center" an expression normally used also
> for race tracks?
in the US, not really. but i can't speak to UK usage which is our normal
guideline in OSM.

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] Proposal for motor racetracks

[Richard Welty]

On 10/17/16 2:09 PM, Lorenzo Mastrogiacomi wrote:
> Il giorno lun, 17/10/2016 alle 14.39 +0200, althio ha scritto: 
>> Hi,
>>
>> I added a comment in the wiki discussion [Please see documented and
>> already in use tag Tag:highway=raceway].
>>
>> -- althio
>>
>>
> Sorry but this comment makes me wonder if I completely failed my
> explanation or you have not read the proposal at all.
> As you can see I mentioned highway=raceway many times and the aim of the
> proposal is not to replace it, indeed it is "part of the schema".
> As an easy example: an highway=raceway is inside a leisure=racetrack
> area like a leisure=pitch is inside a leisure=sports_centre area
i don't really see where this proposal adds anything as an alternative to
using leisure=sports_centre with sport=motor, which is what i am currently
doing. i'm not at all convinced that this extra tag is really necessary.

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] [OSM-talk] non-temporary usage of highway=road

[Richard Welty]

On 9/27/16 2:12 PM, Kevin Kenny wrote:
> On Tue, Sep 27, 2016 at 1:56 PM, Andy Townsend  > wrote:
>
> I'd suggest talking to the users concerned - the easiest way is
> via a changeset discussion comment.  If they're unsure what road
> category to use, you can point at other nearby examples in the
> imagery and say "I'd map that as residential" or similar.
>
>
> Of course, there's the never ending discussion of whether most rural
> roads in the US are tertiary, residential, unclassified or service.
> Our classification system is untidy at best. (I generally don't even
> try to get those distinctions right - there is no 'right'.) But I
> don't call them 'road' - I didn't even know such a thing existed until
> I saw this thread.
i find it useful if i see something new in aerial imagery and am not
sure how to tag it.
i only use it when i'm local, and make it a point to go survey the road
on the ground
to fix up the tagging.

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] Galleries versus art shops

[Richard Welty]

On 2/8/16 8:39 PM, Martin Koppenhoefer wrote:
>
> 2016-02-09 0:20 GMT+01:00 Matthijs Melissen  >:
>
> What do you think, would it make sense to try to keep both shop=art
> and tourism=gallery?
>
>
>
> I'm for keeping both, but would prefer a less ambiguous tag for the
> latter, e.g. amenity=contemporary_art_gallery
>
some galleries sell and others do not. i am thinking that there should be
an art tag that applies to all types of art galleries, supplemented by
shop=art
for the ones that sell.

of course, the galleries that don't sell the displayed art usually have
gift shops
full of art like items.

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] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 9:51 AM, David Earl wrote:
>
>
> On Wed, 11 Nov 2015 at 14:01 Richard Welty <rwe...@averillpark.net
> <mailto:rwe...@averillpark.net>> wrote:
>
> it's an inevitable consequence of serializing a complex data
> structure.
> we either find ways to deal with it or else we accept limits on what
> we can accomplish.
>
>
> Or we change the way we do it.
>
> For example, emitting the relations first would help somewhat.
this simply replaces energy expended in the consumer with energy
expended in the producer. this is not necessarily bad, but it is a
significant architectural design decision.

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] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 7:37 AM, David Earl wrote:
> I can see the attraction of this, but I do always worry about gross
> lack of backward compatibility being a huge barrier to adoption. If
> you have to scramble to keep up with changes like this whenever they
> happen, you aren't going to be keen to be a consumer of OSM data when
> it's only peripheral to what you're trying to do. I hear all the
> arguments about being able to move forward and so on, but if you can't
> keep the customers, there's no point.
>
> Also relations are a massively bigger burden on a consumer. Every time
> you get one you've got to do a look up in a potentially HUGE mass of
> other data, so it probably has to be done via a database rather than
> in memory. Getting the information you need becomes orders of
> magnitude slower for every object.
>
it's an inevitable consequence of serializing a complex data structure.
we either find ways to deal with it or else we accept limits on what
we can accomplish.

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] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 12:01 PM, Colin Smale wrote:
>
>   
>
> I would assume that there are many, many more consumers than producers...
>
>
in terms of distinct applications, yes. in terms of network connections,
there is
a 1-to-1 relationship. the work is the same, it's a question of
placement at the
back end or the front end.

and while there is a bit of work involved, it's not huge (unless the
consumer is
asking for a lot of data). i wrote code for my ghost tracks leaflet
widget to convert
the results of an overpass query into displayable GeoJSON, so i'm at
least a little
familiar with the work we're discussing. it's not that hard a piece of
code to write.

so there are also two kinds of work here - the work to write the code,
which many
are able to do (and copies of it are around to crib from) and the actual
conversion
work during the operation of the app/consumer/whatever the scale of which is
directly related to the volume of data being processed.

and if we try to push that work back into the server, we run some risks
in terms
of overloading the servers, not because one instance is a lot of work
but because
a lot of simultaneous instances can be a lot of work.

like i say this is a serious architectural decision, not to be made lightly.

so is the objection writing the code, or the placement of the work? we
can provide
libraries for developers of data consumers, if the former is the issue.

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] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/8/15 5:00 AM, Dave Swarthout wrote:
> Sorry to keep working this side topic but I want to add this
> information FYI. I just came across this interesting article that
> talks about the difficulty of editing relations in JOSM. Even though
> we're talking about routes in this thread I think it's still relevant
> to our recent discussions:
>
> http://sk53-osm.blogspot.com/2015/10/irish-vice-counties-creation-of.html
> ; and especially the section headed "Technical Aspects (OSM)". 
>
> In that section the author, sk53, says, "Creating a whole set of
> boundaries encompassing one country and part of another is not a light
> undertaking on OSM. It is fiddly work, and involves manipulating
> objects with many dependencies. In practice I find it somewhat
> reminiscent of software migration projects: mainly mundane but you
> need to keep your wits about you.
>
> Contrary to what some believe, none of the OSM editors can prevent
> damage to other objects in this process. Mapping boundaries on this
> scale inevitably involves relations, and relations are not
> semantically clean objects at the level of the OSM data model."
>
> I certainly agree with that assessment.
>
i have done a lot of work with admin boundaries in upstate NY and i find it
critical to have a well planned workflow when handling this situation.
otherwise
there are lots of things that are easy to forget.

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] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/7/15 6:02 PM, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> Am 07.11.2015 um 22:31 schrieb Richard Fairhurst :
>>
>> To do it properly and
>> lessen the chance of multiple relations being accidentally created for the
>> same route (as continues to happen with NCN routes in the UK and elsewhere),
>> it will need either a new API search method or a dependency on Overpass.
>
> Are multiple relations for (pieces of) the same route really a big problem? 
> We could have multiple relations until they meet and then merge them.
>
>
for the very long Interstate and US highways, in the US we usually
create a super relation and then have per-state relations. otherwise
you get into relations that you can barely if at all load into an editor.

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] Proposal: Sunset ref=* on ways in, favor of relations

[Richard Welty]

On 11/6/15 5:01 PM, Paul Johnson  wrote:

> > Stop rendering this key and instead render the relations

>> >
>> > Is there *any* map style that does this at the moment?
>> >
> I believe Toby had a working mapnik-based renderer doing this on osm.us at
> one point, though i'm not sure what became of this.
>
it was never on osm.us so far as i know. the demo is still up here:

http://bl.ocks.org/ToeBee/raw/6119134/#13/42.6276/-73.8955

Phil Gold did a lot of work on this, but he's been busy with other things
and i haven't heard of any work on this in a while. i got a lot of the NYS
county route shields up and running.

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] New proposal: Obligatory tagging of oneway on motorway_link

[Richard Welty]

On 9/13/15 5:38 PM, Paul Norman wrote:
> On 9/10/2015 5:20 AM, Joachim wrote:
>
>> Tools to help enforcing the obligatory usage:
>> [...]
>> - No routing over undefined oneways
> The chances of anyone implementing this in their routing engine are
> approximately zero.
quite. there are sections of motorway_link highways along the taconic
parkway
in NY which are two way and so lack oneway tags. now it's not that hard
to go through
and fix it, but i'm reasonably sure this is not the only place where
this situation
exists.

if you impose a restriction like this, then routing will be broken for
some not yet
identified set of links for an unknown period of time. nobody is going
to do that.

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] waterway=derelict_canal

[Richard Welty]

On 8/26/15 8:55 AM, Andy Townsend wrote:
 On 26/08/2015 13:44, Dave F. wrote:
 On 25/08/2015 23:20, Paul Norman wrote:
 On 8/24/2015 3:35 PM, Andy Townsend wrote:
 That's not so bad in lua, but imagine writing ... and not
 disused=yes into every cartocss rule! 

 Fortunately, we will not have to do that in OpenStreetMap Carto, as
 we will not be supporting the style of tagging where one tag says
 what something is, then another tag saying it's not really that, but
 used to be, or will be. We do not want to encourage the use of
 disused=yes, abandoned=yes, or similar tags.

 Sub tags give *extra* data about an entity.

 A pub that's closed down it's still recognisable as a pub.

 Not by someone who wants a beer, it can't!
we have a disused namespace for this sort of thing. it relieves the carto
developers of having to check disused=yes; the data is in the db but
it doesn't mess with the default rendering.

if people want to render disused pubs, the data is there and they can
use it. of course if the pub is torn down then it should move to OHM
if it's of genuine historic significance.

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] Describe explicitly that values of highway tag do not imply anything about road quality (except highway=motorway and highway=motorway_link)

[Richard Welty]

On 8/12/15 8:35 AM, John Willis wrote:
 I agree that highway=* can't imply quality globally, but it is documented 
 country by country how to tag certain types of roads, especially when there 
 are enough types of roads to need all the definitions of highway=*. Japan's 
 tagging page defines all the values and relates them to their region's 
 system, from motorway through path. I imagine each country or region has a 
 how-to guide as well to translate local conditions into basic highway=* 
 types. 

 Perhaps mentioning after this addition that a mapper should refer to their 
 local tagging documentation in the wiki for a region, or ask a nearby mapper 
 for pointers if they have a question. 

the highway= tag already has problems with severe overloading of meaning
in many countries. overloading quality on top of all the other issues
does not
seem like a winning plan 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] landuse=military

[Richard Welty]

On 7/24/15 4:07 AM, Martin Koppenhoefer wrote:

 sent from a phone

 Am 23.07.2015 um 23:50 schrieb Richard Welty rwe...@averillpark.net:

 i'm not at all persuaded that this is an appropriate use of
 landuse=military.

 I agree that landuse=military seems a bit strange for a holiday resort for 
 civilian employees and service staff off duty for recreation. 
 Are there military like access restrictions/security controls to enter that 
 area? Any particular signs?

there is a gate on the entry road which checks id, but then there are
gates for access to most any
on park resort at WDW with similar checks of guest credentials.

a bunch of this traffic occurred as i was returning from/recovering from
the land of the rodent; sorry for not
replying quicker. i'll bundle a few comments here:

the wiki definition for landuse=military is very broad:

For land areas owned/used by the military for whatever purpose

so the usage is correct if we strictly follow the wiki, but it still
seems odd.
we could tweak the wiki language, for example:

... directly used by the military for basing of troops and equipment,
manufacturing,
training and testing of arms, equipment and munitions.

or we could add this tag or something like it:

military=resort

i didn't see military=manufacturing in the taginfo list, but we probably
should
add that in any case; the US DoD operates a number of facilities that
make stuff.

i am told that the US DoD operates 4 such resorts; i don't know about
the defense
establishments of any other countries.

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] landuse=military

[Richard Welty]

On 7/26/15 7:23 PM, Warin wrote:
 On 27/07/2015 4:04 AM, Richard Welty wrote:

 The word and above .. if applied logically would mean all of those things 
 need to be present for the tag landuse=military to be correct. 
 Substituting and/or would allow the mapper to use the tag for any, some or 
 all of those things. 
i don't think it parses quite that way, but it would force both troops
and equipment,
so ok.


in another message, it's suggested that this should be an access tag on
leisure=resort. i think this is likely the right way to go. i see that
access=military has been discussed in the past (for roads) and dismissed,
or i would suggest that.
 or we could add this tag or something like it:

 military=resort

 i didn't see military=manufacturing in the taginfo list, but we probably
 should
 add that in any case; the US DoD operates a number of facilities that
 make stuff.

 There are a number of commercial firms that make military items .. would 
 these too be tagged this way? 

my intent is that it would only apply to manufacturing facilities
operated directly by the DoD such as the Watervliet Arsenal
(which is where my wife works.) a Boeing aircraft plant, for example,
can reasonably be switched back and forth between military and
civilian aircraft construction.

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] landuse=military

[Richard Welty]

so this past week, i was at Disneyworld with my family. as it happens,
my wife is a civilian employee of the department of defense, so we
stayed at shades of green, a resort at Disney leased by the DoD for
use by service members, retirees and civilian employees.

for some reason, in OSM it has a boundary which is tagged landuse=military
there are no military vehicles, facilities, or weapons at the site, just
off duty service members visiting the land of the giant rodent.

https://www.openstreetmap.org/#map=17/28.40196/-81.59220

i'm not at all persuaded that this is an appropriate use of
landuse=military.

anyone have an opinion?

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] Concrete kerbs in highway

[Richard Welty]

On 6/25/15 11:52 AM, Clifford Snow wrote:

 On Thu, Jun 25, 2015 at 8:44 AM, Martin Koppenhoefer
 dieterdre...@gmail.com mailto:dieterdre...@gmail.com wrote:


 but this would only work on a road with no crossings (or all
 crossing on both roads at the same spot)...


 Marin,
 I must be a little slow this morning, please elaborate. 

the issue, i think is that frequently there are highways that have raised
concrete barriers, but with frequent gaps. you end up needing to model
this one way or another. there is not really an easy way out.

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] README tag with editor support

[Richard Welty]

this is a summary of previous discussion on newbies  talk-us

we have an ongoing, persistent problem with armchair mappers
correcting the map to match out of date aerial imagery. i just
had to repair the map in Rensselaer, NY; the street named
Broadway was reconfigured in late 2012, and bing imagery is
out of date. a couple of months ago someone realigned my
edits to match the out of date bing imagery. others can and
have described similar situations.

i have started using the unofficial tag README whenever i
make edits that differ from current bing imagery; i usually
place the date of the note in ISO format at the beginning
of the text. for example, here is the note i placed on the
road in Rensselaer:

2013-01-15 - reconfiguration of road not yet fully reflected in aerial
imagery. do not conform this road to current imagery.

this has mostly worked, but in this specific case the armchair
mapper chose not to read the note, or read it and dismissed it.

so i have two things in mind here:

1) formalize the README tag as a way to caution future mappers

2) request editor support, when someone goes to change a
README tagged entity, it would be nice if editors would popup
a dialog saying something along the lines of

Warning: read the following before making any changes to this
object README text follows

other suggestions that have been made have included trying to
make the dates on which imagery was collected more obvious,
adding warnings when edits are newer than available imagery
(or newer than the imagery layer currently being displayed),
and pressing to get more current imagery into place.

does anyone have any thoughts on how to approach this?

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 a Driver and Vehicle Licensing Agency (US:DMV)

[Richard Welty]

On 6/9/15 5:48 PM, John Eldredge wrote:

 The department that issues drivers' licenses varies from state to
 state.  The rules dividing regular drivers' licenses from specialized
 licenses, such as restricted licenses for minors, commercial licenses
 (needed to drive a vehicle for hire, and/or various large vehicles),
 and motorcycle licenses, vary from state to state. Some states have
 the same department handle both vehicle licenses and drivers'
 licenses, some don't.

and the states have reciprocity agreements to recognize
each other's licenses. the map of reciprocity agreements
is complete, but there was a time when it wasn't.

as near as i can tell, many/most Canadian provinces have
agreements with the various states 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] [OSM-talk] OSM is a right mess

[Richard Welty]

On 6/4/15 11:53 AM, AYTOUN RALPH wrote:
 The oneway=yes, oneway=no conundrum.. put yourself in the position
 where you are looking at a road ahead of you. It is only wide enough
 for one vehicle but has passing bays along it's length. It is not wide
 enough to be a conventional twoway road so can it be tagged twoway?
 That would give the impression that cars can progress along it in
 opposite directions at the same timethat would be incorrect. But
 neither direction has the right of way and it is up to driver
 discretion and politeness as to who will reverse back to the passing
 bay. So oneway=no but twoway is not necessary yes.
i've used

lanes=1

and omitted oneway in these cases

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] housenumber on node and area

[Richard Welty]

On 5/28/15 8:44 PM, pmailkeey . wrote:
 Do explain

first problem - where google points

do you have any idea how many things are wrong with that statement?

the two big ones:

1) we must not depend on anything google does

2) google doesn't even reliably get it right

so handwaving where google points is simply wrong. way wrong.

richard
 On 29 May 2015 at 01:39, Richard Welty rwe...@averillpark.net
 mailto:rwe...@averillpark.net wrote:

 On 5/28/15 8:26 PM, pmailkeey . wrote:



 Postcodes don't have addresses!

 Where Google points, given that postcode, for a geographic address

 Bigstone Meadow
 Tutshill
 Nr Chepstow
 Gloucestershire 
 England

 ummm, i think you have quite a bit to learn about geocoding.


-- 
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] housenumber on node and area

[Richard Welty]

On 5/28/15 8:26 PM, pmailkeey . wrote:



 Postcodes don't have addresses!

 Where Google points, given that postcode, for a geographic address

 Bigstone Meadow
 Tutshill
 Nr Chepstow
 Gloucestershire 
 England

ummm, i think you have quite a bit to learn about geocoding.

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] housenumber on node and area

[Richard Welty]

On 5/26/15 6:56 PM, pmailkeey . wrote:

 Building addresses shouldn't be on nodes. Named entrances can be - on
 ent/exit nodes. 

if building addresses shouldn't be on nodes, what are we to make of
the address interpolation feature?

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] Wiki: Key:level: proposed rewrite

[Richard Welty]

On 5/25/15 1:20 PM, John Eldredge wrote:
 The level key is intended for OSM internal use, to tell routing and
 rendering software what connects to what. For indoor mapping, it would
 make sense to also have a way to name floors, which needs to allow for
 both numeric and non-numeric floor names. I have been in buildings
 that have more than one named floor. For example, one parking garage
 that I sometimes use has levels named Basement, Ground (ground level
 on one side of the building), 1 (ground level on the opposite side of
 the building), 2, 3, 4, and 5.
quick example from downtown albany - the old Omni office building
has B (basement), L (lobby), 1 through 12, P1  P2 (penthouse 1  2)

the level key is very much internal and if indoor mapping ever is going
to go anywhere, some provision for the names is important.

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] relation type for raceways

[Richard Welty]

On 3/18/15 2:20 PM, Werner Hoch wrote:

 There is type=circuit

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

 example (Monaco) http://www.openstreetmap.org/relation/148194 It is
 used about 60 times in OSM.
that's not bad. i'd probably want to add some other roles,
perhaps paddock  false_grid (or their UK equivalents as
i'm not sure if they use the same terms.) anyone know why this
proposal hasn't gone forward?

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] relation type for raceways

[Richard Welty]

as i go forward mapping raceways in north america, one of the
issues is modeling multi configuration courses such as Watkins
Glen and Lime Rock.

one solution is to use route relations, and add a new
route type,

route=raceway

in this model, i would use forward and backward roles where
necessary. right now the best example of this i have is of
my model of the Thompson road courses over the years at
Thompson Speedway in Connecticut, which is in OHM. some
sections of the raceway were used in different directions in
different variations of the course, hence the need for
forward  backward.

also, it would be useful to have ref tags or some equivalent
id tag on the relations to facilitate querying, e.g. WGI1 for
the first Glen circuit, WGI2 for the second, and perhaps suffixes
for the multiple configurations of WGI4 (WGI4.Short, WGI4.Long,
WGI4.Short.InnerLoop, WGI4.Long.InnerLoop or something like
that.)

this isn't really a formal proposal right now, i'm just looking for
input/suggestions on how to approach this, and to see if anyone
has thought about this and maybe has better ideas.

thanks,
   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] Blatant tagging for the renderer: bridges abandoned railways

[Richard Welty]

On 3/9/15 4:58 PM, Bryce Nesbitt wrote:

 The broader point is intact.

 When making sense of abandoned bridges and oddly rounded buildings in
 various places, it is super helpful
 to see the context of the prior railroad grade.  It helps in mapping
 from the air and on the ground.

 A given railway grade may (and often does) exist as razed, abandoned,
 disused, and reused (e.g. highway=residential or highway=service,
 leisure=park) along it's length.  So how can we represent the former
 way, and the current use of each bit,
 in a rational way?

it's probably worthwhile to consider OpenHistoricalMap as a resource for
recording information about spatial entities that no longer exist in the
modern
world. this relieves us of the argument about representing them in OSM.

i am now in the opening phase of a campaign to describe old auto racing
venues in OHM; in some cases they are related to existing physical entities
(e.g., the first and second Watkins Glen Grand Prix courses used public
roads
of the time, most of which still exist. likewise, many airport courses
have been
used over the years and are no longer; but the airports frequently still
exist.
these things go in OHM because while the physical entities still exist, the
racing usage is long gone.)

the issue of how to relate OHM objects to OSM objects is an open question;
right now i am not attempting to provide links from OHM entities to OSM
entities and instead am depending on a leaflet application to use OSM as a
basemap to provide context.

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 restrictions for shoulder lanes?

[Richard Welty]

On 2/3/15 6:14 AM, Colin Smale wrote:


Same as for normal vehicles, but ignoring the access tag and any 
restrictions




but you've declared that access=no applies both to obstructed
routes (bollards, guardrails, etc) and unobstructed routes.

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] Access restrictions for shoulder lanes?

[Richard Welty]

On 2/3/15 4:36 AM, Colin Smale wrote:


Then they are access=no (with foot=yes or whatever as appropriate) or 
barrier=boulder. The way is blocked both for emergency services and 
mere mortals. No need for access=emergency.

then how do you create a routing engine for use by emergency vehicles?
think it through, please, think it through.

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] Lifecycle concepts, REMOVED

[Richard Welty]

On 1/28/15 8:09 AM, SomeoneElse wrote:

On 28/01/2015 13:05, Richard Welty wrote:


i changed them to highway:unbuilt, rather than deleting them so
that they would stop rendering and wouldn't get added back in later.



I guess that that makes sense here in a fix the mapper kind of way 
(I've certainly done similar things), but generally I wouldn't have 
thought that things that were once proposed but are now never going to 
be built belonged in OSM at all.

i wouldn't either, it's a measure taken to end what otherwise
might turn into something that looks like an edit war.

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] Lifecycle concepts, REMOVED

[Richard Welty]

On 1/28/15 7:51 AM, Tom Pfeifer wrote:

maybe fiction: and an explanation in the note tag.

back in the 1960s, there were a bunch of proposals for motorways
in the Albany, NY area that were never built (for good reason). a mapper
added those as proposed maybe two years ago, which wasn't good
because the default mapnik stylesheet renders them.

i changed them to highway:unbuilt, rather than deleting them so
that they would stop rendering and wouldn't get added back in later.

some sort of generic tagging for such situations would be nice.

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] Lifecycle concepts, REMOVED

[Richard Welty]

On 1/28/15 7:08 AM, Martin Koppenhoefer wrote:

I just stumbled over this in the wiki:
http://wiki.openstreetmap.org/wiki/Lifecycle_prefix

*removed:*

  * (features that do not exist anymore or never existed but are
commonly seen on other sources)


I propose to remove the part or never existed but are commonly seen 
on other sources, because this has nothing to do with removed. If 
people want to tag easter eggs or errors from other maps in the OSM db 
they should use a distinct tag for it.




+1

--
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] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

On 1/24/15 11:20 AM, Никита wrote:
ltivalue tags, there easier way to avoid problem: avoid multiple 
values in /value /part of key=value.


 i suggest learning to deal with it.
Are you an idiot? I mean really.

ok, i'm done here.

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] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

On 1/24/15 10:58 AM, Nelson A. de Oliveira wrote:

On Sat, Jan 24, 2015 at 11:36 AM, Никита acr...@gmail.com wrote:

reduced cpu load for database because there no need to compute smart regexes

You know that it's always a trade-off, right?
While the CPU usage *could* be lowered, disk usage/IO and network
traffic could increase.
There is no magic with your approach.

furthermore, there is no reason to assume that the computation is
being done on the same system; in fact, it is unlikely that any regex
computation is being done on the DB server.

i find the case for this unconvincing, it seems mostly motivated by
an intense dislike for regular expressions. but the regex has been
a standard technique for decades; i suggest learning to deal with
it.

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] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

i've removed prior discussion so that this can stand on its own.

i admit that the distinction between keys and values is a bit
blurry; it would be a fallacy to claim that data goes only in
values because that's obviously not completely true.

however, i will assert that for key space to be useful it needs
to be managed; pushing to much arbitrary data into the key
space reduces its utility.

from this point of view, having colour in key space makes sense
but having the actual names of colours as subkeys seems to me
to be overloading too much data value into the key side. for
every parsing problem you simplify on the value side by flipping
data into subkeys, you create additional complexity when data
consumers must navigate key space.

what we're doing now is not necessarily ideal, the fact that
we're having this discussion shows this. however, moving
a bunch of data data into key space to avoid semicolons
does not strike me as an improvement.

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] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

On 1/23/15 10:13 AM, jgpacker wrote:
I don't understand the insistence in using regexes as some kind of 
argument against semicolon lists.


A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT regexes.

Me and other developers in this thread (Imagic, Friedrich, David, 
Dmitry, Marc) are trying to tell you semicolons are not a problem.



+1

competent languages provide simple mechanisms for splitting
strings on single characters. sometimes the function is even
called split

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] correct access tagging for tourist attraction

[Richard Welty]

we were using the old skobbler app to get us to the biltmore estate in
Ashville, NC today, and an issue came up with access tagging. specifically,
there are multiple roads that can access biltmore but only one official 
entrance.
the current tagging in OSM labels all the roads as private, with the 
result that

an OSM based GPS app can't distinguish what the correct roads to use
actually are. we ended up at the wrong entrance.

i'm pondering how to tag to distinguish between the preferred private and
the ones that aren't supposed to be used. any suggestions?

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] custom road ref shields

[Richard Welty]

On 11/28/14 2:26 PM, Paul Johnson wrote:


On Thu, Nov 27, 2014 at 10:11 PM, johnw jo...@mac.com 
mailto:jo...@mac.com wrote:


That looks really good. Some graphic designers need to remake the
shields for icon size (bigger lettering, details ignored), but the
system of putting on the roads looks great. 



amItheOnlyOneHere.png that thinks, in the vast majority of cases, 
using the sign type you'd actually see on the highway is useful, 
particularly for unusual cases?  For example, the Oklahoma Turnpike 
Authority shields are really that hard to read when you're on the 
highway, so it's good to know you're only expecting a symbol as 
something recognizable in either case. 
http://bl.ocks.org/ToeBee/raw/6119134/#16/36.0448/-95.7380



i'll argue also that it's a rendering choice, and different rendering
engine designers may choose differently. right now, what Phil did
is basically for demo purposes. there had been talk about maybe
deploying it on openstreetmap.us as a us centered version of
OSM, but that hasn't happened (and it's been a while).

what it demonstrates quite effectively is that we have all the tagging
we need for shields right now; we don't need a new tagging
proposal, just a lot of hard work building out the relations and
tagging them properly.

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] custom road ref shields

[Richard Welty]

i think this has kind of wandered off topic for tagging, as no new
tagging needs to be developed...

On 11/28/14 6:39 PM, Paul Johnson wrote:
Kind of thought this was settled already, even in the strange cases of 
states with multiple highway networks (Oklahoma, Texas, Missouri, to 
name three).


On Fri, Nov 28, 2014 at 4:06 PM, Clifford Snow 
cliff...@snowandsnow.us mailto:cliff...@snowandsnow.us wrote:


I've been trying to understand the issues that keep us from having
Pictural Route Shields. The issue is on github [1] but as best as
I can understand, it gets down to how we (US) tag routes. From
talking to Paul Norman we need to fix the tagging problems before
we can get pictural route shields.


well, there's also a need to actually get the route shield code into place
on whatever rendering engine is deemed appropriate.


Toby has a working demo [2] up on the openstreetmap us servers.

yes; this is a demo of Phil's solution. i have help a bit with shield 
configuration
files for NYS and tagging of NYS routes. the links i posted the other 
day are

to this demo server.


According to Toby, the US Interstate routes are in good shape. We
probably need to work on State and US routes. Not having done much
route relationships, except to break a few, I can't offer much
support. However with Martijn Exel help using Maproulette we could
go after broken relationships.

a lot of US and state routes are done. in NYS coverage is pretty good; 
there are
some state routes missing, and county routes are mostly done on the east 
side

of the state.


I propose we ask for pictural shields on interstate routes while
working on completing the US and State routes.


there are a couple of elements to consider here. in addition to
building relations, there are these other elements:

providing appropriate base svg files for shields that don't currently
have them. i don't know how many of these are yet to be developed

providing configuration files that guide the pre population of the
route shields of various types (i did a bit of this for NYS county
routes a year or so back).

as i understand it, the demo is based on mapnik styles pre
carto, and some work would need to be done to move it to carto.

what standard do we want to set for deploying shields? the demo
displays shields when relations are set up and displays the old style
oval ref element otherwise. so there's no technical reason why we
can't look at alternate, incremental approaches. i think that knowing
that your shields will show up as soon as you build relations could
be a powerful motivator.

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] custom road ref shields

[Richard Welty]

On 11/27/14 10:39 AM, Tod Fitch wrote:

If I recall correctly from a discussion on the Talk-us list a while back, the 
preferred way in the US is now to specify the shield in a route relation. I did 
not follow the discussion fully but my impression is that the tagging allowed 
for custom specification of the shield. It looks like 
https://wiki.openstreetmap.org/wiki/Interstate_Highway_relations shows the 
route relation tagging with symbol=* specifying a url to the shield symbol svg.


actually, specifying the shield with a URL for an svg file was an older
approach.

the approach that Phil Gold uses in his demo is a little different;
the shield is not specified in the tagging. it does require route relations.
the ref and network tags on the relation are used as indices to tables
in the shield render to pick out what shield should be used. for example,
for NY 2, the route relation has tags

network=US:NY
ref=2

and those values are used to select the shield to be rendered.
for county routes, the network tagging is extended like this:

network=US:NY:Rensselaer
ref=130

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] custom road ref shields

[Richard Welty]

On 11/27/14 6:48 PM, johnw wrote:
I think having it on the relation is a great idea, especially since 
adding the tags to all the road segments sounds like an insane amount 
of tagging . Is this something that we should ask Phil to create a 
formal proposal page for the tags, so we can start adding symbol key 
values to relations? I think the hard thing is to actually get things 
tagged.



the basic scheme doesn't require anything new or unusual in
route relation tagging, just care and consistency.


The only suggestion I have is that we make it able to handle two or 
three - as putting the ref in a symbol is good, but we should be able 
to add a second one as well, to cover different situations where the 
relation is part of an even larger system (like the California scenic 
highway system, or similar.) - or would that just be another single 
icon applied to a different relation (or super-relation) that shares 
some of the segments, and they just both get their single symbol 
rendered? In some cases the symbol rendered would not need to use the 
ref from the road.

well, multiple relations are handled decently in Phil's system.

here is an example from Albany  Rensselaer NY:

http://bl.ocks.org/ToeBee/raw/6119134/#14/42.6351/-73.7394

where you can see interstate shields, US highway shields,
NY state highway shields, and county route shields (the
blue pentagonal shields). note the primary of US 9  US 20;
there is a relation for each of those highways and Phil's code
handles the case well.

more specialized shields are handled as well; here is
an example of a NY State parkway system shield on
the Taconic State Parkway:

http://bl.ocks.org/ToeBee/raw/6119134/#15/42.2525/-73.6169

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] path vs footway

[Richard Welty]

On 11/4/14 5:33 AM, Tom Pfeifer wrote:

A tag is not useless just because one particular renderer does not
evaluate it. There might be other renderer and data consumer that
are interested in this tag.

+1

we are not tagging for one specific renderer, we are tagging for the
potential suite of data consumers which includes renderers,
routers, and things things that haven't been thought of yet.

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 Digest, Vol 62, Issue 14

[Richard Welty]

On 11/4/14 5:19 PM, Warin wrote:


 I've not seen any rendering specfically for horses. Here in Australia 
there are a number of horse trails .. one over 5,000km long. Not 
enough demand for horse maps thus no rendering?

there are limits to what you're going to see in the standard
mapnik style on the main website. there are simply too many
tags and too many things to render, and no one map is going
to please everyone.  folks with specific requirements frequently
deploy their own maps (opencyclemap, openfiremap, etc.)
there's no reason why openbridlemap.org couldn't exist.

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] Default maxspeed unit on waterways

[Richard Welty]

On 10/29/14 10:47 AM, Malcolm Herring wrote:

On 29/10/2014 14:12, Ilpo Järvinen wrote:
I don't know about other countries, but here in Finland the water 
maxspeed

signage is in km/h although knot is used for almost everything else.


In UK waterways, both MPH and knots are used. Usually MPH on canals 
and knots on rivers, though even this can depend on who the navigation 
authority is and how far back in history their statutes were written.

i understand where this is coming from, but i think we need
to stick to a single units default for a given tag, and those should
probably be in SI units. it's not exactly killing me to have to add
mph when i tag maxspeed 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] 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 molto...@gmail.com 
mailto:molto...@gmail.com:


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

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

[Richard Welty]

On 10/27/14 12:02 AM, Peter Miller wrote:


Without a way of tagging the fact that we know that the bridge has 
regulation clearance and also knowing who surveyed it and when the 
data was added we can't know what we need to do to complete the 
mapping to allow the routing of high vehicles.



there is value to knowing the date of the survey. maxheight changes usually
happen when a road is resurfaced; over time maxheight gets lower and lower
until they decide to tear the road up completely and redo it from scratch.

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