Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

[Jonathon Rossi]

Apologies for bringing dedicated reserved parking into the thread since
that is the only experience or interpretation I had. I think parking is a
worthwhile tag and I'd use emergency=parking for that, but let's get back
to your topic since it sounds more complex.

On Tue, Oct 27, 2020 at 6:34 PM Nüssli Christian (SRZ) <
christian.nues...@zuerich.ch> wrote:

> I wanted to ask you if there's a correct mapping of fire service areas.
> That's areas in fire protection guidelines that will be reserved for
> emergency vehicles.I found quite a few that are tagged as landuse=military
> which is in my opinion – the incorrect way.


How are they reserved for emergency vehicles?

On Wed, Oct 28, 2020 at 10:13 PM Martin Koppenhoefer 
wrote:

> these areas are usually not access=no, there will be no parking / stopping
> signs, but otherwise these are "normal" areas where other activities (like
> walking, playing with a ball, etc.) will take place. Think of it as part of
> the building regulation picture. The precise requirements may also depend
> on the vehicles and equipment that is used by the local fire station.
>

Or are they just areas with a useful normal purpose but have been designed
to allow emergency personnel to perform their job better? I saw the photo
of a sign which translates to "fire service installation area", do you have
any photos of these areas so we can better understand what they look like
(or did I miss that)?

For us in Australia emergency services basically use anywhere they like,
even if that means blocking a road, but it appears from the video you
linked that Germany has very narrow streets and so these areas are
important because the streets don't have enough space? If there is a sign
declaring a "fire service area" how do you know the extent of that area?

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

Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

[Jonathon Rossi]

On Wed, Oct 28, 2020 at 12:02 PM Graeme Fitzpatrick 
wrote:

> On Wed, 28 Oct 2020 at 09:43, Supaplex  wrote:
>
>> How about *"emergency = rescue_area"* (very rarely in use)? I agree that
>> landuse should not be used in this case, but we have "emergency" for this.
>>
>  As I say, I've never looked at it, but would emergency=clear_area work?
>

I've seen "ambulance only" and "no parking emergency vehicle only" painted
on the ground in shopping centre car parks near entrances and in front of
large buildings here in Australia. I assume the intent for this tag isn't
just firies?

We've got emergency=landing_site for helicopters, maybe just
emergency=parking?

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

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

[Jonathon Rossi]

On Mon, Aug 24, 2020 at 2:22 PM Andrew Harvey 
wrote:

> On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi  wrote:
>
>> On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey 
>> wrote:
>>
>>> In OSMCha you can create a Filter, and in the Filter creation screen set
>>> a polygon area you're interested in monitoring
>>>
>>
>> Andrew, how do you specify a polygon, always wanted to do that but I
>> thought OSMCha only supports a bbox?
>>
>
> [...] So at the top you should see a map with a button in the top right.
> Click that button and trace your polygon on the map.
>

Thanks. I've always read the text next to the map ("Filter changesets whose
bbox intersect with a location boundary.") as meaning the map helps you
define a bbox. i.e. it wouldn't keep and filter using the polygon, just
uses it to work out a bbox to contain the polygon. Is that text misleading?

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

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

[Jonathon Rossi]

On Mon, Aug 24, 2020 at 12:10 PM Andrew Harvey 
wrote:

> In OSMCha you can create a Filter, and in the Filter creation screen set a
> polygon area you're interested in monitoring
>

Andrew, how do you specify a polygon, always wanted to do that but I
thought OSMCha only supports a bbox?

You can also get an RSS feed for this if you use an RSS reader, otherwise
> maybe an RSS to email service could work
>

RSS feed and RSS to email service (Feedrabbit is a side project of mine) is
exactly what I do.

I monitor the whole greater Sydney region and south coast and yes it does
> take time, but I think it's worth it for the errors you catch. There are a
> few others who also review with OSMCha, but we don't have a good way to
> distribute the work to avoid duplication and minimize one's slipping
> through the gaps.
>

I don't follow an area anywhere near that big here but I definitely find
errors, often with new mappers and sometimes from the organised mapping
teams. OSMCha works okay, but something that keeps track of the changesets
to review and other states while you are waiting on fixes would help.

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

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

[Jonathon Rossi]

On Wed, Aug 19, 2020 at 9:28 AM Graeme Fitzpatrick 
wrote:

> On Wed, 19 Aug 2020 at 05:51, Colin Smale  wrote:
>
>>
>>
>> On the other hand using the "1-5" notation to indicate a range is pretty
>>> well understood in the UK at least. What it is missing is the
>>> "interpolation" value (even, odd, all).
>>> So let us sort this mess out by defining:
>>> 1) that a hyphen indicates a range
>>>
>> Are there any other scenarios for hyphenated addresses?
>>
> As Andrew mentioned earlier, out here it is very common to have an address
> like 1-5 which means that one property is built across 3 blocks, so it's
> official address is "1 to 5", with no interpolation. Even numbers are on
> the other side of the road, so nobody is going to be looking here for 2 & 4.
>

Agreed. It is really common in Australian rural areas that the address
number range is actually allocated to a single lot, not one per lot.
Australia Post several decades ago allocated street numbers to every lot in
the country that previously only had a lot number, lot numbers are now only
acceptable until the street number is allocated by council. When this
allocation occurred the street numbers were allocated for every 10 metres
(left odd, right even, with other rules to determine the starting point),
so if your lot started 1500m from the start of the street on the right side
and had 500m of street frontage they'd have allocated your street number as
150-198. Australia Post expects that the street number range be used rather
than just the first number no matter where your driveway is. It sounds like
this is all defined in Rural Addressing in AS4819:2011, but the QLD
Government link below has a short explanation similar to what I've said.

https://www.qld.gov.au/environment/land/title/addressing/how-determined
https://auspost.com.au/content/dam/auspost_corp/media/documents/australia-post-addressing-standards-1999.pdf

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

Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

[Jonathon Rossi]

On Sun, May 31, 2020 at 5:17 PM Daniel Westergren  wrote:

> Should we close the discussion in this mailing list, continue in a smaller
> format and then report back the concluding suggestions for confirmation
> before implementing? Or is there still enough interest to keep the entire
> discussion here?
>

I'm happy to follow along the conversation on the mailing list to hear all
views without strongly participating; right now my views are already
covered by others.

Most importantly I'd like an outcome that results in wiki pages that we
don't just ignore because they contradict each other, that sort of tagging
just makes everyone's life hard. This tagging problem seems to always get
dropped into the too hard basket.

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

Re: [Tagging] Proposal of new tag for technicality of trails for running

[Jonathon Rossi]

Hi,

Fellow trail runner (& MTB rider) here.

Obviously there isn't a concrete proposal with any proposed tags, however
this sounds very subjective (if not using existing observable tagging) and
I think a runner's skill will determine the technicality a lot more than
the trail itself. For example, I love bombing down steep, loose and rocky
single track whereas others I run with can't do the same.

I think the existing tags cover your examples, I've responded below, you'd
have to provide a photo example of a trail that you don't think you can
adequately map using existing tags for anyone to provide more detail.

> Some factors to determine values: stability/softness of surface
Does surface=* not already provide enough here? dirt, gravel, etc? Maybe we
need another value for something you don't think fits?

> obstacles (rocks, roots etc.)
smoothness=* would be the best tag here, it describes something verifiable
and for all trail users.

> running rhythm (short ups/downs, sharp turns etc.) and attention required.
Short sections and sharp turns are defined by the trail geometry already.
If a trail has steep uphill and downhill sections, I'd split that section
out and tag it with incline=*. The trail router could roughly calculate
elevation gain with an average incline for a segment.

On Tue, May 19, 2020 at 12:47 AM Daniel Westergren  wrote:

> Hi there,
>
> I would like to discuss the possibility of a new tag, trail_technicality,
> to be used on ways with highway=path.
>
> One way this can be used is aid in finding trails to run on and to get
> suggested routes with tools like Trail Router (www.trailrouter.com),
> Komoot (www.komoot.com) or Open Route Service (
> https://maps.openrouteservice.org/).
>
> *What tags are already available?*
> *sac_scale *is the obvious choice to determine trail difficulty. But it's
> geared towards mountain trails and I doubt it's being used much outside of
> mountain trails.
>
> *mtb:scale* is closer to what I'm proposing, but geared towards
> single-trail technicality for MTB, not for running (or hiking).
>
> Then there's *surface*, *width*, *trail_visibility*, *smoothness *(for
> wheeled vehicles) that can all be used to determine what kind of path it
> is, but they don't really tell anything about the technicality of
> single-trails.
>
> *How to use the tag?*
> It would only be used for single-trails, that is in ways with
> highway=path. I don't have a set suggestion of values, but I'm thinking
> something similar to mtb:scale, basically with runnability as the
> determining factor. It would obviously leave room for subjective judgement,
> just like smoothness and trail_visibility. But with image examples and
> clear factors describing each value it would still give a lot of useful
> information to route planners and renderers.
>
> Some factors to determine values: stability/softness of surface, obstacles
> (rocks, roots etc.), running rhythm (short ups/downs, sharp turns etc.) and
> attention required.
>
> *Use-cases*
> As mentioned, trail_technicality could be used together with other values
> in route planners and renderers, to suggest routes based on user preference
> (technical trails <-> road running), but also to roughly estimate running
> time (in addition to elevation/slopes).
>
>
> What do you think?
>
> /Daniel Westergren
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

[Jonathon Rossi]

On Wed, Apr 22, 2020 at 6:54 PM Andrew Harvey 
wrote:

> I've been using mtb:scale:imba on any kind of trail where signage at the
> site notes an IMBA rating
>
Same here. If a land manager has signed an IMBA rating I'll tag it. These
ratings are generally relative to other trails in the same bike park/area
(not just based on the guidelines), so it is of lesser value to make these
up just for a single trail, use other specific physical tags (surface, etc)
for observations.

> The Trail Difficulty Rating System shall be used for bikeparks, this
applies for instance to North Shore [from wiki page history]
Either referring to the trails in Canada (
https://en.wikipedia.org/wiki/North_Shore_(Greater_Vancouver)), or the
style of trails that originated in this area. Either way, it didn't add
anything useful to the description so good that it is gone.

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Jonathon Rossi]

On Sun, Apr 5, 2020 at 5:49 PM Andrew Harvey 
wrote:

> [...]
>

> bicycle= as an access tag should refer to any class of bicycles by
> default. Today I was walking a track which had a no bicycles sign, meaning
> all types of bikes are disallowed. Conversely bicycle=yes just means that
> bicycles are legally/physically allowed, it does not indicate suitability
> by a specific type of bicycle. I don't think I've ever seen signage which
> says no mountain bikes but you can use a road bike, or vice versa. If there
> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
> etc. You could have a path which is clearly a mountain bike track but
> officially bicycles are not allowed. So based on this we can't use these
> kinds of access tags to define the type of path they must be kept
> independent.
>

Agreed, land managers don't define different access by type of bicycle,
because at the end of the day what is a MTB, I had a MTB without suspension
when I was a kid so it's not suspension, a MTB is just an advertised
bicycle with heaps of features which has continued to change heaps in the
last 15 years with technology, even today the range of features and price
is amazing; eMTB is another category that is different per region/country
whether land managers treat them as a bicycle or motorbike based on their
power output.

In my experience of riders I've met, the trails you can successfully ride
are much more determined by your skills and ability than the bicycle you
are on.

Not all mountain bike tracks are mtb=designated. Many paths are built for
> and used mostly by mountain bikes, key giveaways are jumps, corner banks
> and other technical features, but not officially signposted or marked for
> use by mountain bikes. Conversely the track could be signposted for use by
> mountain bikes but not actually be a mountain bike track, eg. it could be
> highway=track which is not a mountain bike track, but indicated as a way
> for use by mountain bikes so mtb=designated.
>
> So I'm proposing the access tags bicycle= refer to any/all bicycles. mtb=
> become an access tag (mtb=designated for signposted mountain bike).
> path=mtb become a tag to say the path on the ground here is designed=mostly
> used for mountain biking.
>

Around here 5 years ago there were few MTB trails actually signposted, they
had existed for many years but only as the parks got more use had land
managers spent money to signpost the trails. When would I use
mtb=designated when land managers just signpost for
bicycle=yes,foot=yes,horse=no?

I feel this is better than a new highway=singletrack tag since renderers,
> routers, etc can still interpret the path without making changes. If we
> move to a new tag, these tracks will disappear from routers and maps
> overnight.
>

Agreed, it wouldn't just disappear from renderers but it breaks the long
time documented scheme. My suggestion was playing devil's advocate because
I am still not sure what we can't do with the current tags.

All other tags like surface, smoothness, mtb:scale, route=mtb still apply.
> leisure=track would still apply to short loop tracks like a BMX pump track
> or a velodrome, but not to longer A to B tracks.
>
> Thoughts? I can help work on the wiki proposal for these tag changes (mtb=
> as an access tag and path=mtb) but keen to hear feedback here first.
>

*Summary:*
- When would/could I use the proposed mtb= access tag if land managers only
define bicycle=, and what is a MTB (as mentioned above)?
- Your proposed path=mtb would be a specialisation of highway=path (like
service=parking_aisle) which seems odd and against highway=path being a
non-specific path? Objectively how would I know what is a MTB path, many
signposted IMBA green trails don't have berms and rollovers? What does this
tag provide that just adding mtb:scale=* doesn't already? I think general
purpose routers should ignore highway=path if they don't want to understand
path grading, the same can be said for highway=track. Personally I've only
added mtb:scale:imba=* here from signposted trails, just never thought
adding mtb:scale=* was helping anyone so didn't put in the effort, but
could now.

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Jonathon Rossi]

On Sat, Apr 4, 2020 at 1:30 AM Volker Schmidt  wrote:

> We do  not need a new highway tag value "singletrack".
>
Was only making a suggestion to kick the discussion around to what we are
actually mapping, because I dislike leisure=track and highway=cycleway.

I independently read the Wikipedia article,
>
You read more than me, I just know singletrack from walking, running,
riding and building them.

and had come to the conclusion that a singletrack is clearly
> highway=path; surface=unpaved; width=*; mtb:scale=*; mtb:scale:uphill=*;
> mtb:scale:downhill=* and any other tag form the wiki page Mountain biking
> 
>
Yep agreed, that is what I've been using for years as documented on the
wiki. Singletrack is so varied that the highway=path definition of "A
non-specific path" does actually do a good job at describing it. Every now
and then I find some highway=path that should be highway=track but it
usually was added nearly a decade ago so people are doing better today.

It does not need foot=yes and bicycle=yes, as this is implicit.
> A highway=path is, according the wiki, a "singletrack" ("If a path is wide
> enough for 4-wheel-vehicles (wider than 2 m), and it is not legally
> signposted or otherwise only allowed for pedestrians, cyclists or
> horseriders, it is often better tagged as a highway
> =track
>  or highway
> =service
> ")
> It is not different from any mountain trail here. There is no preference
> for MTBs according Wikipedia. It is shared with hikers.
>
Agreed, I made no indication it was different in Australia, just that no
one calls them cycleways (or cycle paths) here, also fairly rare to have
MTB-only trails on public land here too.

And the doubletrack shown on the same page is identical with any
> run-of-the-mill forest road here in Europe, which we usually tag as
> highway=track. And unfortunately I would call this specific one a
> single-track forest road. :-(
>
Yep, highway=track for that one. Oh, but there are two tracks from left and
right tyres :|

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Jonathon Rossi]

>
> I think using highway=singletrack could be a good complement to
> highway=track, then we can use standard access (default foot=yes, horse=no,
> bicycle=yes, motorcycle=no) and surface tagging like we do for
> highway=track. highway=path can continue to be the catch all for "a
> non-specific path".
>

I'd also use [highway=singletrack bicycle=no] to "fix" tagging currently
using highway=path for specific singletrack in protected national parks
where MTBs are not permitted, where foot=yes is the only allowed access.
This compliments [highway=track bicycle=no] in the same parks where only
rangers are allowed to use the fire roads.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Jonathon Rossi]

I too think leisure=track would be even more misleading. I think
singletrack should continue to be a highway=* value. I've never heard
someone call singletrack a cycleway here in Brisbane Australia, and I
always think of commuting when I think of cycleway.

- Recreation is just one use of these trails, new trails are often built to
break up bushland for easier hazard reduction burning, it is a highway I
don't think it belongs under leisure=*
- Lots of singletrack are more cross country and less technical with few
features allowing much easier access to a range of activities from
bushwalking to MTB, little problem riding a cheap road bike (those without
skinny tyres) on many of these
- Some trails are "built" and signed for MTB recreational use, other trails
are just natural without signs but are still known as singletrack
- Sometimes unbuilt trails are created by erosion, wallabies or just
walking/running/riding the same line. Land managers usually don't want
people blazing their own trails but often don't actively "close" these
unsanctioned trails, they are still singletrack, wallabies have fun too :)
- Bushland can have both dirt and asphalt fire roads (many tracks up to
water reservoirs are paved), we've got highway=track to represent fire
roads/double track
- We've got highway=steps and highway=corridor specialisations
- I've never used highway=cycleway for singletrack, always highway=path
because there is nothing better, when I look at the cycleway=* key all I
see is something completely unrelated, all the values and sub-keys aren't
relevant to singletrack.

I think using highway=singletrack could be a good complement to
highway=track, then we can use standard access (default foot=yes, horse=no,
bicycle=yes, motorcycle=no) and surface tagging like we do for
highway=track. highway=path can continue to be the catch all for "a
non-specific path".

Wikipedia has a good description if what I said didn't make enough sense:
https://en.wikipedia.org/wiki/Single_track_(mountain_biking)

On Fri, Apr 3, 2020 at 11:00 PM Joseph Eisenberg 
wrote:

> I think using leisure=track for a mountain bike path is even more
> misleading than highway=cycleway.
>
> A feature with leisure=track is usually an oval racing track for
> runners, track cyclists, or similar sports. This tag is simply not
> used for mountain bike paths;
>
> http://overpass-turbo.eu/s/Sjk - only 89 ways (including loops, like
> mtb pump tracks)
>
> By contrast, highway=cycleway + mtb=designated has been used 558
> times: http://overpass-turbo.eu/s/Sjl
>
> Clearly many mappers consider highway=cycleway an appropriate tag for
> a designated mountain bike path.
>
> However, it's true that highway=path is used more commonly with
> mtb=yes and mtb=designated: http://overpass-turbo.eu/s/Sjo - over
> 13,000 occurences.
>
> Unfortuately only a little over half of those ways have a surface=*
> tag - adding those tags would be more productive than arguing about
> whether to use highway=cycleway or highway=path. (See
> http://overpass-turbo.eu/s/Sjp)
>
> -- Joseph Eisenberg
>
> On 4/3/20, Andrew Harvey  wrote:
> > On Fri, 3 Apr 2020 at 21:16, Marc M.  wrote:
> >
> >> the first page does not show any sign suggesting that
> >> it is also a pedestrian area
> >> imho "It could be" is not enough to add foot=yes
> >>
> >
> > Oh of course, my take is by default routers should assume a designated
> > mountain bike track is discouraged for pedestrians but legally allowed.
> > Although where signage exists to indicate otherwise it should be tagged
> > explicitly with foot=yes/no.
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] URL tracking parameters

[Jonathon Rossi]

On Wed, Feb 26, 2020 at 12:22 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> I added explicit
> "**It means that tracking parameters (mc_id, utm_*, fbclid etc) should be
> removed"
> in
> https://wiki.openstreetmap.org/w/index.php?title=Key:website=1962111=1941669
>

Thanks. Let's hope a few people see it.

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

Re: [Tagging] URL tracking parameters

[Jonathon Rossi]

On Tue, Feb 25, 2020 at 8:40 PM Victor/tuxayo  wrote:

>
> On 20-02-25 04:36, Jonathon Rossi wrote:
>  > Does OSM have a position on these tracking parameters, WT.mc_id, utm_*,
>  > fbclid, etc? I couldn't find anything on the wiki.
>
> https://wiki.openstreetmap.org/wiki/Key:website
>
> It's implied in the following best practice:
>
> > Use as short a URL as possible. Choose simple URLs over complex URLs if
> they basically point to the same content. For example, use
> https://bahn.de/ instead of https://www.bahn.de/p/view/index.shtml, as
> both will get you to the front page. Websites are frequently redesigned, so
> strive for the most "robust" URL that works.
>

Thanks. I did think that statement would apply here, but it just didn't
have as strong of a wording. I do wonder if some contributors don't realise
that these parameters are not necessary to function, and that they should
actually remove them.

On Tue, Feb 25, 2020 at 9:22 PM Frederik Ramm  wrote:

> Ok ok you're right.
>
> The URL does contain a tracking token but it does not exclusively track
> OSM usage.
>
> I have overreacted because I have in the past dealt with advertisers who
> had added an OSM-specific "campaign" ID the the links which was clearly
> out of line, and suspected the same here.
>

I had used this Hilton one as an example because it just happened and the
tracking parameters were so widespread, I too hadn't noticed their own web
site adds those. There are also a lot of *utm_source=ig_profile_share* ones
which individual contributors have probably added without realising wasn't
part of the website URL.

There are however ones which would have been done intentionally,
*utm_source=OpenStreetMap* and *utm_source=mapsme*.

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

[Tagging] URL tracking parameters

[Jonathon Rossi]

Hi,

Ignoring they've just added an incorrect "website:" key when there is
already a "website" one, Hilton Hotels appear to be adding URLs with
WT.mc_id parameters to all their web site links.

Does OSM have a position on these tracking parameters, WT.mc_id, utm_*,
fbclid, etc? I couldn't find anything on the wiki.

https://www.openstreetmap.org/changeset/81403812

https://taginfo.openstreetmap.org/search?q=WT.mc_id#values
https://taginfo.openstreetmap.org/search?q=utm_source#values
https://taginfo.openstreetmap.org/search?q=fbclid#values

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

Re: [Tagging] (Un)removable Bollards

[Jonathon Rossi]

On Tue, Feb 18, 2020 at 5:02 PM Martin Koppenhoefer 
wrote:

> > Il giorno 18 feb 2020, alle ore 03:05, Jonathon Rossi <
> j...@jonorossi.com> ha scritto:
> >
> > I can't think of a bollard here where the general public can remove/fold
> it, otherwise what does it achieve?
>
> I have seen many removable bollards, both in Germany and Italy, which
> weren’t locked at all. Typically you may not drive there even if you
> physically could remove them, similar to a sign which doesn’t physically
> prevent you from driving somewhere.
>

Thanks. Thinking about that scenario now, I have actually seen a bollard
here (Australia) that folded without a lock for delivery access to a
commercial area and there was a sign a bit like a commercial loading zone.

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

Re: [Tagging] (Un)removable Bollards

[Jonathon Rossi]

On Tue, Feb 18, 2020 at 7:49 AM Joseph Eisenberg 
wrote:

> > “ I would interpret "removable" as: the end user can remove it, but has
> to accept a time delay”
>
> Are there such bollards? I can’t imagine that bollards are ever removable
> by the general public, though you can probably request that the bollard be
> removed several days in advance for a special event or construction project.
>

Car parking I used to have a few years ago in the city was off street in
front of the building, each parking bay had a foldable bollard with a lock
built in but the key wasn't available to the general public.

I can't think of a bollard here where the general public can remove/fold
it, otherwise what does it achieve?

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

Re: [Tagging] Billboard or something else

[Jonathon Rossi]

On Wed, Oct 30, 2019 at 11:19 PM Martin Koppenhoefer 
wrote:

> > Il giorno 30 ott 2019, alle ore 13:09, Jonathon Rossi <
> j...@jonorossi.com> ha scritto:
> >
> > I didn't say these signs had to display messages that must be obeyed
> just that they often do.
>
> what I meant was that we might want to distinguish between those that show
> information and those that show traffic signs to which you must obey.
>

Okay, might be useful, but how does a mapper know what a road authority
will do with a variable message sign? If it has only been observed with
travel time messages and other informational messages, then how do you
verify it won't be used for more in the 1% of cases, and does it actually
matter?

I'd be inclined to have all big matrix panels tagged
traffic_sign=variable_message, with Variable Speed Limit Signs and Lane Use
Signals different traffic sign types, maybe traffic_sign=variable_speed and
traffic_sign=lane_control (I've not checked taginfo to see what people are
already using) which would allow navigation apps to notify a driver about a
variable speed limit zone (or does that belong on the highway?), however
this is getting out of scope of Graeme's original question.

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

Re: [Tagging] Billboard or something else

[Jonathon Rossi]

On Wed, Oct 30, 2019 at 9:35 PM Martin Koppenhoefer 
wrote:

> Am Mi., 30. Okt. 2019 um 12:23 Uhr schrieb Jonathon Rossi <
> j...@jonorossi.com>:
>
>> +1 for traffic_sign=variable_message
>>
>> In many jurisdictions road users must obey messages on these signs,
>> including speed reductions (e.g. caused by weather), closed lanes (e.g.
>> crash), and closed motorway exits/detours.
>>
>
> of course these would all be clearly traffic signs, but signs like the one
> on the picture around here never show speed limits or access restrictions,
> they only show information (e.g. they might indicate that a road, bridge,
> exit etc. is closed, but as an pre-announcement, not as the actual access
> restriction which you will find at the spot where it applies), typically
> they show the current travel times to common points, or warn about
> accidents ahead, or say something general like "fasten your seatbelts", "we
> wish you a good drive" etc.
>

I didn't say these signs had to display messages that must be obeyed just
that they often do. There are plenty of painted advisory traffic/road
signs, e.g. letting you know there is an upcoming sharp corner, a ford,
that wildlife frequently cross an area, that the road gets narrow, and I'd
call all of these a traffic sign.

Wikipedia has: "Traffic signs or road signs are signs erected at the side
of or above roads to give instructions or provide information to road users"

OSM Wiki has: "Traffic signs give instructions or provide information to
road users. Some signs are only relevant at the place where they're mounted
(like e.g. a stop sign - called point-related signs from now on), while
others affect a section of the road (like e.g. a "no overtaking" sign -
called section-related signs)."

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

Re: [Tagging] Billboard or something else

[Jonathon Rossi]

On Wed, Oct 30, 2019 at 8:01 PM Warin <61sundow...@gmail.com> wrote:

> The sign can display various messages - so variable message fits.
>
> Traffic sign also fits - the travelling time to another place reflects the
> traffic density, and vehicle crashes are traffic warnings ..
>
> I think traffic_sign=variable_message is good for the feature you report.
>

+1 for traffic_sign=variable_message

In many jurisdictions road users must obey messages on these signs,
including speed reductions (e.g. caused by weather), closed lanes (e.g.
crash), and closed motorway exits/detours. Similar to these pixel based
Variable Message Signs, there are what is usually referred to as a
Changeable Message Sign which has a fixed set of messages (2-4) where
narrow sections will rotate to display a message, usually used for closing
rural roads without power, a solar panel will drive the sections to rotate
into place.

VMS are often used to display travel time messages so they do something
useful until there is a higher priority message for motorists.

In the Intelligent Transport Systems (ITS) industry there are also a bunch
of others specialised electronic signs, including Variable Speed Limit
signs (dynamic speed with the option of a flashing annulus/red circle, used
either pole mounted on either side of the road or on a gantry above lanes,
also used in school zones), and Lane Use/Control Signals (displaying the
permitted usage of a lane usually mounted above the lane, i.e. open,
closed, or indicating you need to merge, on motorways especially with tidal
flow/reversible lanes).

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

Re: [Tagging] Public Transport Timetables

[Jonathon Rossi]

I've been following along the few threads to better understand this topic,
however I'm still feeling that mapping complex timetables is a bit like
mapping the full menu of a cafe or restaurant, or the room options at a
hotel. These things vary whenever the service business chooses and it is
close to impossible to keep it up to date.

In Brisbane Australia, some PT timetables vary often especially with public
holidays (local, state or federal), school holidays (which differ between
schools) and especially with special events (sporting, concerts, etc).
Sometimes timetables get more trips sometimes less, it can be quite
variable throughout the year and not something that can be 100% codified
into timetable rules, and obviously not known too far in advance.

I appreciate that timetables are very useful for consumers of maps, and
understand that in some cities timetables can be reverse engineered by
being somewhat observable (I would think copying a full timetable off a
sign would classify as an import), however are we concerned that this adds
a massive burden to maintain this data in OSM and it is very likely to
always be out of date? If it is always going to be out of date will any app
developer even integrate this data into their app when they can use GTFS
feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of
either application been consulted?

Having this data embedded in the OSM tags also forces apps to reduce their
map cache duration to try to get more updated timetables.

I'm not very experienced with PT in OSM, but I'd have thought improving the
tags for mapping objects to GTFS feeds, including the GTFS endpoints and
license info as tags, and maybe then adding the ability to discover the
GTFS Realtime extension would be the way to go. I think this would give
much more power to app developers. It does overlap a little with
Transitland, but obviously OSM wouldn't be polling or hosting the feeds,
that would be up to an application developer.

Happy to hear any feedback if I've missed the point of this.

On Tue, Nov 6, 2018 at 2:07 AM Jo  wrote:

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started creating
> a new one. It differs in rather important ways from your proposal, so I
> preferred not modifying your wiki page. I also think it's important to
> decouple the (voting for a) full timetable solution from the solution where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured out yet is
> how to differ weekdays that fall in school holiday periods from "normal"
> weekdays. So work in progress.
>
> Polyglot
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Feature Proposal - RFC - Research station

[Jonathon Rossi]

Here in Queensland Australia, our Department of Agriculture and Fisheries
run many research stations

obviously doing primary industries based research. Some universities do
perform research there, but they are government owned and run stations.

I recently started mapping a local one
 which is in a urban area.
Wikipedia's definition of a research station isn't so strong about them
being located in a remote area.

The local one I linked to above isn't self sufficient and people don't live
there, however they recently installed a fancy research solar array. From
your definition it doesn't sound like this one would qualify, as many
others on the DAF list probably don't either, but I would think the chosen
tag name applies.

Is your proposal that this tag applies to my example?

Thanks

On Wed, Oct 24, 2018 at 6:20 PM Bren Barnes  wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/Research_station
>
> A *research station* is an amenity that is built for the purpose of
> conducting scientific research. Research stations are often located in
> remote areas of the world, such as in the polar regions or oceans. Due to
> their remote nature they are usually self-sufficient campuses, generating
> their power requirements from non-grid sources and having food supplies for
> long seasons. The stations are staffed by both research scientists and
> operational staff who live and work on base 24/7
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] mast / tower / communication_tower (again)

[Jonathon Rossi]

On Tue, Oct 9, 2018 at 5:34 PM Lionel Giard  wrote:

> The problem i see with that "multipurpose" value is that it give no
> information and could be misused for other tower:type (like
> defensive;observation) which should not be rendered as communication_tower.
> Thus i would propose to render the "communication_tower" based on the
> height > 250 m (arbitrary value for example) when in combination with
> tower:type=communication (even when others tower:type are mentioned like in
> your example : "tower:type=communication;observation"). I don't know if it
> is feasible for the renderer to identify the presence of only one value in
> the tag ? Otherwise i suppose it would need to put all alternative
> available... :s
>

Rather than trying to make up information (in the renderer) based on a
tower type or arbitrary height, wouldn't it be better to just indicate if
the tower is useful as a navigation aid and seen from a distance? Towers on
a mountain might not reach the arbitrary height but are still one of these
big towers because the surrounding area is much lower?

My first thought was some sort of "landmark=yes" tag, there is already a
"denotation=landmark" tag for trees, however it appears like there might
have been a landmark tag in the past that was deprecated, and I realise
that it would be a stupid tag because you'd have to tag everything.

My next thought was to apply "tourism=viewpoint", however that assumes
public access to enter the tower. The Eiffel Tower is tagged
"tourism=attraction" and "tower:type=communication;observation". Could
tourism=attraction be a good option, it indicates something for tourists
(or locals) to go and check out a bit like tourism=viewpoint even if you
can only see it from the ground and can't go inside?

Regarding mast vs tower, I've generally tagged buildings as towers (i.e.
you can enter them even if just a staircase) and non-buildings as a mast
(including a free standing metal or concrete pole with comms equipment
mounted atop). I don't really mind, but a clear definition is definitely
needed because I was unsure until I looked around at a heap of examples and
just went with the building/non-building distinction.

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

Re: [Tagging] Stormwater outlet into stream

[Jonathon Rossi]

Thanks everyone. Apologies in advance for the long reply.

@Graeme I see you tagged the node with
man_made=drain_outlet+substance=rainwater. In your example it makes sense
to map the underground pipe because you know exactly where it is, but I'd
hate for these to start rendering in the future and bits of incomplete
pipes (a few metres long) start showing up drawing over streets.

The wiki for man_made=pipeline
<https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline> says it is
meant for "major" pipelines, which these aren't really apply:

By using pipeline are we abusing that tag? Dictionary.com's definition of
pipeline also indicates that a network of pipes isn't a pipeline. I too
don't view the reticulated water network of pipes a pipeline, however there
would generally be a pipeline going from a water treatment plant to a water
reservoir/storage tank; and in the same way the network of sewerage drains
aren't a pipeline, but you could have a pressurised or gravity pipeline to
move sewage to a treatment plant.

Mark's suggestion to use man_made=sewer didn't sound right to me because I
always view sewers as for wastewater which must go to a treatment plant
before entering waterways. Dictionary.com seems to agree, the values for
manhole=* <https://wiki.openstreetmap.org/wiki/Key:manhole> also agree, this
OSM tagging proposal also agrees
<https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_Schema>,
however Wikipedia seems to indicate some people refer to stormwater drains
as sewers too, this might be a location thing because I found some
indication that some cities have a combined waste and rain water drain
(these obviously won't directly connect to a waterway).
substance=rainwater;sewage works though.

There is 158 uses of man_made=storm_drain (99% of them on nodes), and most
in North Lakes (just north of Brisbane, Australia), however they've used
that tag rather than manhole=drain. It isn't exactly wrong that they used
that tag on the surface grate because the drain is technically there too,
just as it is at the outlet. (Off topic: but that residential estate is so
well mapped; every tree, lightpole, drain, kerb, driveway, bit of grass all
mapped, looks so great rendered!
https://www.openstreetmap.org/#map=18/-27.21343/153.02634).

I think there is no need to use man_made=drain_outlet because the outlet is
just part of the drain (the smaller ones generally have no extra concrete
to hold earth back), so just use man_made=drain on the node or map a way
(which can join to the waterway=*), however I'd use manhole=drain for
grates on the road surface because they also act as manholes providing
access into the drain. I know some of the large stormwater drains also have
barriers  inside to prevent humans entering, they could be mapped as nodes
on the way too.

I've mapped pump stations for the reticulated water network before (because
they are usually small buildings or fenced off equipment on the surface)
but not the underground pipes, I do see value in mapping the pipelines
especially when they are visible (e.g. passing next to a bridge over a
creek) but wouldn't map the underground network around streets as you'd
have no idea where it went.

If I went with man_made=drain, at what point would one of those drains be
big enough to be a man_made=pipeline? Is a big drain flowing into a big
river (e.g. Brisbane River) that you could stand up inside a pipeline?
Maybe yes, maybe no.

Is a pipeline for delivering a substance, while a drain for taking a
substance away? Is that a distinction that even needs to be made?

On Thu, Sep 20, 2018 at 8:04 AM Graeme Fitzpatrick 
wrote:

>
> Thanks Tijmin & Andrew - name deleted! :-) Thought it should have
> something to explain the open space between 2 houses:
> https://www.google.com/maps/@-28.0775238,153.4261968,3a,75y,192.84h,72.02t/data=!3m6!1e1!3m4!1spFpy3s9A1cXKkiPow16w2Q!2e0!7i13312!8i6656,
> but having now read the "No name" policy can see that's wrong. Have also
> changed the node & pipeline details.
>
> On Wed, 19 Sep 2018 at 17:34, Jonathon Rossi  wrote:
>
>> I don't quite understand the way extending to the north in your example
>> tagged just man_made=yes and surface=grass, is that the underground pipe
>> joining to the rest of the network?
>>
>
> That's it - there's a surface drain & manholes on the street, with the
> visible pipe going into the lake, so I marked the pipeline in back to the
> street. As above, I've ow changed the tagging so that the pipeline is
> marked through the easement, with an outlet at the lake edge.
>
>
>> Thinking about how this would apply to other waterways I've mapped, I
>> currently map the streams or drains that pass under roads which rainwater
>> passes through like below, these are quite similar but with a completely
>> different tagging scheme.
>>
>> wat

Re: [Tagging] Stormwater outlet into stream

[Jonathon Rossi]

Thanks Graeme.


> I did this:
> https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664
> for one stormwater drain nearby.
>

I don't quite understand the way extending to the north in your example
tagged just man_made=yes and surface=grass, is that the underground pipe
joining to the rest of the network?

Would that work for your purposes?
>

Regarding the node on the end, yes I think it should work. I always viewed
man_made=pipeline for legit big pressurised pipelines but I can't see any
harm using it for stormwater drains especially that some get really big.

man_made=pipeline
location=underground
substance=rainwater

The wiki page says man_made=pipeline shouldn't be applied to nodes but
there are already nearly 4000 so that can change, or if I have a decent
idea which way the underground pipes go (easy for the big ones) just map a
short way.

Thinking about how this would apply to other waterways I've mapped, I
currently map the streams or drains that pass under roads which rainwater
passes through like below, these are quite similar but with a completely
different tagging scheme.

waterway=drain or stream
tunnel=culvert
layer=-1

Do we use waterway=* where it is a naturally occurring stream but humans
earthfilled the location with a concrete culvert and put a road over the
top but that is still part of the earth's waterways of the creek system.
Can't be true because waterway=drain is for man made waterways.

This tagging also appears valid for a big stormwater drain where you can
walk into it:

waterway=drain
tunnel=flooded
location=underground
(https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded)

Unfortunately it doesn't render in any way, so there's nothing showing on
> the map to indicate that there's anything there, until you go into edit
> mode :-(
>

I'm not too worried about rendering. In the past I've left a note on the
first node because these drain outlets usually can't be seen from aerial
imagery and many times the creek directly where it pours doesn't even look
like a creek from aerial imagery, so the intention was to capture the
information to ensure armchair mappers don't "fix" the creek.

As usual each time I post on the mailing list it opens a can of worms and I
learn too much about all the different possible tags :).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Stormwater outlet into stream

[Jonathon Rossi]

I've come across the desire to map a stormwater outlet at the beginning of
a stream a few times now and have failed to find an appropriate tag to
place on the node. These outlets are pretty common in residential areas
where the stormwater pipes underneath the roads (obviously unmapped) direct
their water to the lower streets and eventually enter naturally forming
creeks that existed before the residential estate was even built.

Is there something that is already commonly used that I've been unable to
find?

I've seen manhole=drain on the wiki, but that is the opposite end where
surface water enters the stormwater system.

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