Re: [Tagging] Continuous shoulder rumble strips (CSRS)

2020-12-20 Thread Seth Deegan
Those are known as rumble strips.

The wiki has traffic_calming=rumble_strip:
https://wiki.openstreetmap.org/wiki/Key:traffic_calming#Common_values

There is no page for the tag though, differentiating the types of rumble
strips there are.

For examples, I’ve seen them on:
The side of a highway (short spaces between bumps)
There are also different types/designs for these:
https://safety.fhwa.dot.gov/roadway_dept/pavement/rumble_strips/rumble_types/


Before construction zones or other approaching features (longer spaces to
warn drivers)
https://commons.m.wikimedia.org/wiki/File:North_Luzon_Expressway_Rumble_Strips.jpg#mw-jump-to-license


El El dom, dic. 20, 2020 a la(s) 10:09, Volker Schmidt 
escribió:

> Is there a tagging scheme for these bicycle  killers
> ?
> I have encountered them on freeways and other major roads that allow
> cyclists, in the western States of the USA. In theory there should be no
> problem, as the cyclist is supposed to be on the shoulder all the time, but
> in practice there are many situations where the shoulder is simply not
> usable, and so you have to cross over them and back to avoid the obstacles
> (in most cases a tyre carcass which sheds the dreaded bent-needle shaped
> tire flatteners for cyclists)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Animal trails

2020-11-30 Thread Seth Deegan
You could add a `note=*` to every element. You should probably contact the
mappers of that region and explain to them not to add them.

I agree that in this case, mapping animal tracks is *especially *necessary.
If someone isn't going to map it now, they're going to do so in the future
(as you've seen), incorrectly.

On a related idea, OSM should probably implement "Area Notes" into the API
to notify mappers how to map specific areas.

lectrician1 


On Mon, Nov 30, 2020 at 1:44 PM s8evq  wrote:

> Hello everyone,
>
> With the Belgian community, we have been in contact with Natuurpunt, our
> main national nature conservation organization. They are slowing using more
> and more OSM and recently came to us with the following remark.
>
>
> "Some mappers have added paths that are not actually real paths for
> humans, but simply flattened walking routes made by the cows. I assume that
> these are visible on aerial photographs, and in the field they may also
> look like trails. However, it is really not the intention that people
> should walk there. They change regularly and we also do not want to put
> signs 'forbidden entry' all over the area.
> We could delete them from OSM, but then of course soon later, an active
> micromapper might add them again."
>
> Most people seem to think paths made by cattle or wildlife should NOT be
> mapped at all (
> https://www.openstreetmap.org/user/Pascal%20Cuoq/diary/1). However,
> when there are micromappers around, they tend to map ALL THE THINGS. Not
> mapping these "animal trails" that you know about, means they will likely
> show up on the map as a simple highway=path, added by somebody else.
> Therefor, we would prefer to map them with a tag like highway=animal_track,
> to make sure mappers see that this thing was analyzed before and should NOT
> be mapped as a regular path. Do you have any suggestions for a tag or a
> different approach?
>
> Thanks.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

2020-11-22 Thread Seth Deegan
I agree with Dave F.

It's a duplicate.

On Sat, Nov 21, 2020 at 7:43 PM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> To me, boardwalk describes the design & appearance rather than the surface
> construction: An elevated walkway.
> Although I do admit that's mostly influenced by The Drifters song.
>
> DaveF
>
>
> On 21/11/2020 23:20, Mateusz Konieczny via Tagging wrote:
>
> Is there some value in surface=boardwalk tag?
>
> It seems to be a duplicate of surface=wood.
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

2020-11-22 Thread Seth Deegan
I recently found out about the Extremely long Amtrak route relations from
clay_c.

Your message is a bit confusing at first but I think you are proposing that
relations and super-relations should be used more-often to reduce the
complexity of processing data for data consumers?

In that case, I would support an API limit on the number of members in a
relation.
I agree that developers shouldn't have to handle this burden.

In response to DaveF's comment:

> Actually, splitting way because software can't handle it, is making the
> database more complex.


Yes, but benefits outweigh the costs.
If the editors did this automatically and still made the data
interpretable, this wouldn't be an issue.

Sorry if I misinterpreted the conversation.

On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst 
wrote:

> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
> wisely]
>
> Brian M. Sperlongano wrote:
> > It seems that we are increasingly doing things to simplify the
> > model because certain tooling can't handle the real level of
> > complexity that exists in the real world.  I'm in favor of fixing
> > the tooling rather than neutering the data.
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud.
>
> OSM optimises for the mapper, because mappers are our most valuable
> resource. That's how it's always been and that's how it should be.
>
> But that does not mean that volunteer tool authors should rewrite their
> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
> make stuff ever more complex and expect developers to automatically fall in
> line; nor that any given map has a obligation to render this 0.1%, or
> indeed, anything that the map's creator doesn't want to render.
>
> The Tongass National Forest is not "in the real world", it is an
> artificial administrative construct drawn up on some bureaucrat's desk.
> It's not an actual forest where the boundaries represent a single
> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
> several relations (with a super-relation for completeness if you insist),
> just as nothing is lost by tagging Chesapeake Bay with the series of
> letters "c","o","a","s","t","l","i","n" and "e".
>
> Richard
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-17 Thread Seth Deegan
>
> it does an OK job of this:  click the History button to get a
> recent-around-here list of 20 edits (click the Load More button for 20
> more…and again and again if you like).
>

Yes, the History button does do a good job. But I'm talking about this:

Clicking on one specific changeset will “drill down” to the specific data
> elements changed in that changeset (to the degree they can be displayed in
> a narrow column on a web page, though there are numbered “pages” you can
> scroll through for copious amounts of data).  These are grouped by data
> type (nodes, ways and relations), which in turn can have their “history”
> displayed, by “version number.”  It’s basic, workaday metadata, but it’s
> quite useful and user-friendly, requiring no more complicated skill than to
> click-navigate on a web page.


In my opinion, the current changeset viewer UI is *useless*. Giving me a
list of elements that I can't even see what tags and geometries are changed
(when clicking on each element) is of no use to me. You can't even hover
over one of the elements in the list and see it's geometry outline in the
map viewbox (would).

If the interface displayed the kind of data like
https://osmlab.github.io/osm-deep-history/ did (Yves, you're right this is
the best one), or at least OSMcha, then it would be of use.

---

> A
> contributor can obtain data from many different sources within each
> changeset. Pushing the tag to the changeset meta data invalidates it's
> limited usefulness when added to individual objects.
>

Exactly.

I've found published data (from the authority
> authorised to amend the route) are often too inaccurate, out of date or
> lacking in detail to warrant transferring to OSM.
>

I find the opposite and I mostly map cycle routes that are local and I have
personally traveled on (I live in the Chicago metropolitan area). There are
just too many sources for trail names and data from forest preserve
districts/counties, cities, regional routes, etc. that I make routes from.
I can't just remember all of the trail names I come across (I don't survey).

---

What I still don't understand is why you all are *discouraging* the use of
source=* tag (or maybe you're not?). Because it seems that it can still be
of use to some people. Why not let users know on the Wiki page that they *can
*use the tag if they might find a *specific* source helpful to other users,
but that they shouldn't tag imagery or other general sources per-element
and instead tag it on the changeset? Thank you for agreeing ael.

On Tue, Nov 17, 2020 at 6:35 AM Martin Koppenhoefer 
wrote:

>
> sent from a phone
>
> > On 17. Nov 2020, at 06:23, stevea  wrote:
> >
> > to the degree they can be displayed in a narrow column on a web page
>
>
>
> yes, this is basically broken since the redesign (maybe 2012?), the
> history view used to provide a clearer overview on the full width, and this
> is something that could come back again? Or maybe invert the screen real
> estate division between map and history table.
> Josm has a decent history view integrated (ctrl+h) which let’s you compare
> between versions, links to changesets and shows for example position
> changes of nodes.
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Seth Deegan
And of course, I have got this response before. But now that I think about
it, the limiting factors seem to be:

   1. Editors (I use iD primarily) do not allow you to easily see the
   *exact* past history of an element. Nor does osm.org really (why does it
   give a list of changed elements and map area and not even allow you to see
   what tags and elements' geography are changed!?). OSMcha only does it on a
   per-changeset basis. https://osmhv.openstreetmap.de/ does this
   perfectly.
   2. What if the source is in a changeset 2+ changesets ago? I shouldn't
   have to look back in the history to find a source.


On Mon, Nov 16, 2020 at 9:09 PM Seth Deegan  wrote:

> May I ask why not source=*? I know it's basically depreciated, but many
> times I find myself wondering where past mappers got the info for a route
> (this happened just today). I would find it very helpful. It also doesn't
> require the tagging of all of the ways.
>
> On Mon, Nov 16, 2020 at 8:45 PM Kevin Kenny 
> wrote:
>
>> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> Be careful. This is where many contributors get confused. The name of
>>> the *path* is often not the name of the *route*. A route relation can, &
>>> often does, go along paths with different names. Multiple routes can go
>>> along a path.
>>>
>>
>> To give a more concrete example, there's a rail-trail in my neighborhood
>> called the Mohawk-Hudson Bike-Hike Trail.
>> It has a relation, for several reasons that I'll discuss below.  Most of
>> its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
>> few ways, however, that have the names of highways because freeways and
>> active rail lines interrupt the rail grade, and the trail follows some
>> lightly-trafficked streets for a short distance before rejoining the
>> grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
>> Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
>> members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
>> there are two route relations: one for cycling and one for walking.)
>>
>> Large portions of the rail-trail are, in turn, used by two long-distance
>> routes: the Erie Canalway Trail and the Empire State Trail.  There are
>> separate relations for these two, and most of the members of the
>> Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
>> (That does not affect the names of the member ways. The Mohawk-Hudson
>> signage is consistent, while the signage for the other two trails is still
>> something of a work in progress, although there's a lot more of it than
>> there used to be. The naming of the member ways follows the commonest
>> signage.)
>>
>> There are a great many member ways because of changes of the
>> characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
>> surface changing from asphalt to wood on a bridge, and so on.)
>>
>>>
>> The Mohawk-Hudson relation exists (a) because not all the member ways
>> have its name (since it borrows roads for short segments) and (b) because
>> Waymarked Trails and other data consumers do better with a route relation
>> grouping all the ways, rather than trying to assemble a route from ways
>> with nothing in common other than being named alike.
>>
>>>
>>> I assume this is not prefered because a number of applications use the
>>> names in the Ways themselves and not the Route Relation, most notably
>>> osm-carto.
>>>
>>>
>>> It renders the names of the paths, not the routes.
>>>
>>>
>>> However, some benefits of doing this might be:
>>>
>>>- Takes up less space in the DB
>>>- More tags that apply to the whole coute could be added to the
>>>Relation like surface
>>><https://wiki.openstreetmap.org/wiki/Key:surface>=* and source
>>><https://wiki.openstreetmap.org/wiki/Key:source>=* (like the
>>>official map of the route).
>>>
>>>
>>> Surface has no place in a route relation as it refers diectly to the
>>> path, not the multiple relations passing along it. Similar for the source
>>> tag.
>>>
>>> DaveF
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> 73 de ke9tv/2, Kevin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Thanks,
> Seth
>


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


Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Seth Deegan
May I ask why not source=*? I know it's basically depreciated, but many
times I find myself wondering where past mappers got the info for a route
(this happened just today). I would find it very helpful. It also doesn't
require the tagging of all of the ways.

On Mon, Nov 16, 2020 at 8:45 PM Kevin Kenny  wrote:

> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> Be careful. This is where many contributors get confused. The name of the
>> *path* is often not the name of the *route*. A route relation can, & often
>> does, go along paths with different names. Multiple routes can go along a
>> path.
>>
>
> To give a more concrete example, there's a rail-trail in my neighborhood
> called the Mohawk-Hudson Bike-Hike Trail.
> It has a relation, for several reasons that I'll discuss below.  Most of
> its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
> few ways, however, that have the names of highways because freeways and
> active rail lines interrupt the rail grade, and the trail follows some
> lightly-trafficked streets for a short distance before rejoining the
> grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
> Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
> members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
> there are two route relations: one for cycling and one for walking.)
>
> Large portions of the rail-trail are, in turn, used by two long-distance
> routes: the Erie Canalway Trail and the Empire State Trail.  There are
> separate relations for these two, and most of the members of the
> Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
> (That does not affect the names of the member ways. The Mohawk-Hudson
> signage is consistent, while the signage for the other two trails is still
> something of a work in progress, although there's a lot more of it than
> there used to be. The naming of the member ways follows the commonest
> signage.)
>
> There are a great many member ways because of changes of the
> characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
> surface changing from asphalt to wood on a bridge, and so on.)
>
>>
> The Mohawk-Hudson relation exists (a) because not all the member ways have
> its name (since it borrows roads for short segments) and (b) because
> Waymarked Trails and other data consumers do better with a route relation
> grouping all the ways, rather than trying to assemble a route from ways
> with nothing in common other than being named alike.
>
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>>
>> It renders the names of the paths, not the routes.
>>
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>>=* and source
>>=* (like the official
>>map of the route).
>>
>>
>> Surface has no place in a route relation as it refers diectly to the
>> path, not the multiple relations passing along it. Similar for the source
>> tag.
>>
>> DaveF
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> 73 de ke9tv/2, Kevin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Seth Deegan
Hidde thank you for the resources. I am aware of them. Also thank you for
mentioning Osm2pgsql. I know what it is, but your comment about how it's
meant compile relational data vs. how the OSM DB isn't is very true.

Thank you for the clarification too Peter.

I guess I'm just obsessed with relational DB models.

On Mon, Nov 16, 2020 at 12:23 PM Peter Elderson  wrote:

> AFAIK, a relation is meant to represent an entity of its own, which can be
> observed and verified in the field.
> Its tags should be the tags of this entity, not the tags shared by the
> members. It's not a relational database model.
>
> If many streets are called "Polygon Alley" you tag each one with
> name=Polygon Alley. No normalization applies, just tag it.
> Best, Peter Elderson
>
>
> Op ma 16 nov. 2020 om 18:17 schreef Seth Deegan :
>
>> Honestly I think I'm just confused.
>> I guess ways *do have* official names, it's just that I keep on thinking
>> about the possible *conceptual* conflicts between two different Routes
>> under one way (this statement probably doesn't make sense).
>>
>> Also, I'm someone who loves relations and finds myself thinking about
>> putting all of the elements that share a tag under a relation constantly!
>> I guess just keeping them in their original Ways is the way to go.
>>
>> However, *if there was a way* to indicate the "primary" relation for a
>> Way, then I'd be all for it.
>> IDK. Save space wherever possible seems to be the common theme.
>> Problems with this though would be that renderers/data consumers would
>> have to go into the relation every time they want to find more tags for an
>> element.
>> There are pros and cons. I'm also aware relations aren't categories.
>>
>> Thank you for the clarification.
>>
>> On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
>> wrote:
>>
>>> Hello,
>>>
>>> Route relations 'group' together the nodes/ways/relations that form a
>>> cycling route. The nodes/ways/relations themselves should not be tagged
>>> with the name of the route, like you quoted the wiki.
>>>
>>> The name of a way should be the official name of the way, not the name
>>> of the relation(s) that way is part of. I refer to Key:name [1] which
>>> states "The names should be restricted to the name of the item in question
>>> only and should not include additional information not contained in the
>>> official name such as categories, types, descriptions, addresses, refs, or
>>> notes."
>>>
>>> So the question remains for the ways you mention that are tagged with
>>> name of the cycling route. Are those ways officially named exactly as the
>>> relation name? If not, I would classify this situation as 'tagging for the
>>> renderer' (getting the renderer to show the name of the cycling route).
>>>
>>> On the subject of rendering: there are many renderers that show cycling
>>> route relations [2]. Some of them [3] are even advanced enough to grasp the
>>> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
>>> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>>>
>>> Kind regards,
>>> *Hidde Wieringa*
>>>
>>> [1] https://wiki.openstreetmap.org/wiki/Key:name
>>> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
>>> [3] https://cycling.waymarkedtrails.org
>>> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
>>> [5]
>>> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>>>
>>>
>>> On 16-11-2020 17:17, Seth Deegan wrote:
>>>
>>> The Cycle Routes Wiki Page
>>> <https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
>>> states:
>>> "It is preferred to tag the cycle routes using relations instead of
>>> tagging the ways."
>>>
>>> If I come across a route that has the Ways already tagged with the name
>>> <https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, can I
>>> delete the name <https://wiki.openstreetmap.org/wiki/Key:name>=*s in
>>> the Ways and just create a Route Relation with the name?
>>>
>>> I assume this is not prefered because a number of applications use the
>>> names in the Ways themselves and not the Route Relation, most notably
>>> osm-carto.
>>>
>>> However, some benefits of doing this might be:
>>>
>>>- Takes up less space in the DB
>>>- 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Seth Deegan
Honestly I think I'm just confused.
I guess ways *do have* official names, it's just that I keep on thinking
about the possible *conceptual* conflicts between two different Routes
under one way (this statement probably doesn't make sense).

Also, I'm someone who loves relations and finds myself thinking about
putting all of the elements that share a tag under a relation constantly!
I guess just keeping them in their original Ways is the way to go.

However, *if there was a way* to indicate the "primary" relation for a Way,
then I'd be all for it.
IDK. Save space wherever possible seems to be the common theme.
Problems with this though would be that renderers/data consumers would have
to go into the relation every time they want to find more tags for an
element.
There are pros and cons. I'm also aware relations aren't categories.

Thank you for the clarification.

On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
wrote:

> Hello,
>
> Route relations 'group' together the nodes/ways/relations that form a
> cycling route. The nodes/ways/relations themselves should not be tagged
> with the name of the route, like you quoted the wiki.
>
> The name of a way should be the official name of the way, not the name of
> the relation(s) that way is part of. I refer to Key:name [1] which states
> "The names should be restricted to the name of the item in question only
> and should not include additional information not contained in the official
> name such as categories, types, descriptions, addresses, refs, or notes."
>
> So the question remains for the ways you mention that are tagged with name
> of the cycling route. Are those ways officially named exactly as the
> relation name? If not, I would classify this situation as 'tagging for the
> renderer' (getting the renderer to show the name of the cycling route).
>
> On the subject of rendering: there are many renderers that show cycling
> route relations [2]. Some of them [3] are even advanced enough to grasp the
> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>
> Kind regards,
> *Hidde Wieringa*
>
> [1] https://wiki.openstreetmap.org/wiki/Key:name
> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
> [3] https://cycling.waymarkedtrails.org
> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
> [5]
> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>
>
> On 16-11-2020 17:17, Seth Deegan wrote:
>
> The Cycle Routes Wiki Page
> <https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
> states:
> "It is preferred to tag the cycle routes using relations instead of
> tagging the ways."
>
> If I come across a route that has the Ways already tagged with the name
> <https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, can I
> delete the name <https://wiki.openstreetmap.org/wiki/Key:name>=*s in the
> Ways and just create a Route Relation with the name?
>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface <https://wiki.openstreetmap.org/wiki/Key:surface>
>=* and source <https://wiki.openstreetmap.org/wiki/Key:source>=* (like
>the official map of the route).
>- Ways with two or more routes wouldn't be tagged name
><https://wiki.openstreetmap.org/wiki/Key:name>=route 1 & route 2
>
> <https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3Droute_1_%26_route_2=edit=1>
>  and
>instead have their respective Relations. This could help with preferred
>routing/data usage in general.
>
>
> I would propose that *all* routes and their names should be tagged in a
> Relation and *never* the Ways, even if the Route Relation only has *one
> member*.
>
> This way data consumers know that all Routes are going to be relations.
> Also future Routes mapped that share the Way of a Route that does not have
> Relation, won't require the mapper to shift all of the data stored in the
> Way to a new Relation.
>
> Also, if Proposed features/Relation:street
> <https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street> is
> ever approved, this would help establish a consistent OSM-wide routing
> standard.
>
>
> *As for now*, I do not think that we should be deleting the name
> <https://wiki.openstreetmap.org/wiki/Key:name>=*s of Ways. However, I
> think osm-car

[Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Seth Deegan
The Cycle Routes Wiki Page
<https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
states:
"It is preferred to tag the cycle routes using relations instead of tagging
the ways."

If I come across a route that has the Ways already tagged with the name
<https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, can I delete
the name <https://wiki.openstreetmap.org/wiki/Key:name>=*s in the Ways and
just create a Route Relation with the name?

I assume this is not prefered because a number of applications use the
names in the Ways themselves and not the Route Relation, most notably
osm-carto.

However, some benefits of doing this might be:

   - Takes up less space in the DB
   - More tags that apply to the whole coute could be added to the Relation
   like surface <https://wiki.openstreetmap.org/wiki/Key:surface>=* and
   source <https://wiki.openstreetmap.org/wiki/Key:source>=* (like the
   official map of the route).
   - Ways with two or more routes wouldn't be tagged name
   <https://wiki.openstreetmap.org/wiki/Key:name>=route 1 & route 2
   
<https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3Droute_1_%26_route_2=edit=1>
and
   instead have their respective Relations. This could help with preferred
   routing/data usage in general.


I would propose that *all* routes and their names should be tagged in a
Relation and *never* the Ways, even if the Route Relation only has *one
member*.

This way data consumers know that all Routes are going to be relations.
Also future Routes mapped that share the Way of a Route that does not have
Relation, won't require the mapper to shift all of the data stored in the
Way to a new Relation.

Also, if Proposed features/Relation:street
<https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street> is
ever approved, this would help establish a consistent OSM-wide routing
standard.


*As for now*, I do not think that we should be deleting the name
<https://wiki.openstreetmap.org/wiki/Key:name>=*s of Ways. However, I think
osm-carto *should* render and *prefer* to render Relation names for Cycle
routes over the names of the Ways. The Editors should also somehow
influence users to map Relations for Cycle routes instead of naming them.


Thoughts?
Seth Deegan (lectrician1)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-11 Thread Seth Deegan
Yes, but the range in size of lakes is massive (local ones compared to the
Great Lakes in the U.S.). You wouldn’t want the names of smaller lakes
showing up at lower zoom levels like the Great Lakes should.

If one was to establish a rendering difference, they should probably do so
by computing the lake size in the (the area of the way), rather than its
tagging.

El El mié, nov. 11, 2020 a la(s) 07:31, Martin Koppenhoefer <
dieterdre...@gmail.com> escribió:

> Am Mi., 11. Nov. 2020 um 14:22 Uhr schrieb Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>> This doesn't seem like a good idea to me. The boundary between a lake and
>>> a pond may be hard to measure sometimes, but that doesn't mean it is useful.
>>>
>>>  In what way is this distinction useful?
>>
>
>
> for example you could prioritize rendering of lake names compared to pond
> names (assuming you give more importance to lakes).
>
> Cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread Seth Deegan
Thank you for the explanation Joseph Isenberg. Now I can see why that's so
hard to implement.

Also, could someone please add descriptions/organize the projects listed in
the Wiki page for Vector Tiles?
As a relative newcomer to the OSM development space, it seems that
implementing vector tiles for OSM-carto is currently the most centralized
and focused effort (though little progress) in the OSM community, yet it's
all the way down in the Server section of the article?
I'm also confused as to what the TODO section is.
The whole article is confusing at first.
https://wiki.openstreetmap.org/wiki/Vector_tiles


El El dom, nov. 8, 2020 a la(s) 11:54, Joseph Eisenberg <
joseph.eisenb...@gmail.com> escribió:

> Re: "Vector tiles could allow for instant client-side switching of map
> styles, the ability to customize the base layer, and allow users to make
> custom maps themselves"
>
> This is often claimed as a benefit of client-side vector tiles, but in
> practice it is not possible.
>
> The reason is that at mid zoom levels there is far too much data in the
> database for it all to be made available in a vector tile format so that
> the map is fully customizable.
>
> If we were to include all features on the vector tile data, the rendering
> would be too slow or would crash for many users, especially those who have
> mobile phones, or lower-powered tablets, or even current low-end laptops.
>
> Practical client-side vector tiles have to significantly simplify the data
> and remove a number of nodes and features to make the rendering practical.
> While some customization is possible (like hiding some icons and labels, or
> changing the script or language of the text labels), you are not going to
> get a custom rendering from one set of vector tiles.
>
> User pnorman and several others had been working on a demonstration which
> re-implements the current OpenStreetMap Carto style in server-side vector
> tiles (the first step), but it is quite difficult to achieve a good result
> with currently available open source tools, and there will have to be some
> compromises which worsen the cartography in some cases.
>
> I have not heard an update on this project in the past few months, so it
> may be stalled.
>
> -- Joseph Eisenberg
>
> On Sun, Nov 8, 2020 at 8:48 AM Seth Deegan  wrote:
>
>> And there should be several specialized layers: general car navigation
>>> map, sport map for hiking/cycling/skiing, transportation. All of that would
>>> be possible with vector tiles which are less computationally demanding to
>>> create.
>>
>> We already have multiple map styles.
>>
>>
>> What they mean is that the current map styles run by other providers will
>> not be necessary if we switch to vector tiles.
>>
>> Vector tiles could allow for instant client-side switching of map styles,
>> the ability to customize the base layer, and allow users to make custom
>> maps themselves (this is extremely powerful).
>>
>> This is pretty self explanatory, but I wanted to note earlier that vector
>> tiles allow for the clickability/interactivity of every element on the map.
>> Most new users who come to osm.org don't even know what the Query Tool
>> does or that it exists. It's also pretty inconvenient and slow.
>> Making everything clickable allows features to be explored with a
>> possible beautiful UI like Google Maps.
>>
>> On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>>
>>>
>>> Nov 8, 2020, 05:31 by mach...@gmail.com:
>>>
>>> I absolutely agree with Seth, OSM should switch to vector tiles ASAP.
>>>
>>> Note that OSM would not switch to vector tiles. At most one more
>>> rendering would switch
>>> to vector tiles.
>>>
>>> For OSM Carto see
>>> https://github.com/gravitystorm/openstreetmap-carto/issues/3201
>>> (not sure what is the state and what is the current blocker)
>>>
>>> (sorry if that is overly pedantic)
>>>
>>> And there should be several specialized layers: general car navigation
>>> map, sport map for hiking/cycling/skiing, transportation. All of that would
>>> be possible with vector tiles which are less computationally demanding to
>>> create.
>>>
>>> We already have multiple map styles.
>>>
>>> Their code is all on github so no need to reinvent the wheel and I think
>>> this could be easily modified for OSM purposes.
>>> https://github.com/FreemapSlovakia
>>>
>>> Is there somewhere description/summary of their softwar

Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread Seth Deegan
And there should be several specialized layers: general car navigation map,
> sport map for hiking/cycling/skiing, transportation. All of that would be
> possible with vector tiles which are less computationally demanding to
> create.

We already have multiple map styles.


What they mean is that the current map styles run by other providers will
not be necessary if we switch to vector tiles.

Vector tiles could allow for instant client-side switching of map styles,
the ability to customize the base layer, and allow users to make custom
maps themselves (this is extremely powerful).

This is pretty self explanatory, but I wanted to note earlier that vector
tiles allow for the clickability/interactivity of every element on the map.
Most new users who come to osm.org don't even know what the Query Tool does
or that it exists. It's also pretty inconvenient and slow.
Making everything clickable allows features to be explored with a possible
beautiful UI like Google Maps.

On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Nov 8, 2020, 05:31 by mach...@gmail.com:
>
> I absolutely agree with Seth, OSM should switch to vector tiles ASAP.
>
> Note that OSM would not switch to vector tiles. At most one more rendering
> would switch
> to vector tiles.
>
> For OSM Carto see
> https://github.com/gravitystorm/openstreetmap-carto/issues/3201
> (not sure what is the state and what is the current blocker)
>
> (sorry if that is overly pedantic)
>
> And there should be several specialized layers: general car navigation
> map, sport map for hiking/cycling/skiing, transportation. All of that would
> be possible with vector tiles which are less computationally demanding to
> create.
>
> We already have multiple map styles.
>
> Their code is all on github so no need to reinvent the wheel and I think
> this could be easily modified for OSM purposes.
> https://github.com/FreemapSlovakia
>
> Is there somewhere description/summary of their software stack?
>
> If there is nobody who can or is willing to do it then let's hire someone
> who can.
>
> Or let a company like Mapbox do it.
>
> If someone, anyone is willing to sponsor hosting they can propose to add
> their tiles to OSM main site (see
>
> https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers
> )
>
> Though as business of Mapbox is to offer paid hosting of OSM data it is
> dubious that they
> would put special effort into competing with themself. Even free tier of
> their products
> requires giving credit card details.
>
> I would be willing to do regular monthly donations for someone's salary if
> that makes OSM better and more attractive.
>
> I am not sure how one may donate for specific target of vector tiles
> (it is also not mentioned at https://wiki.openstreetmap.org/wiki/Donations
> ).
>
> donati...@openstreetmap.org is appearing on the page, maybe asking there
> is
> there such possibility would be useful
>
> I also fully agree with Anders. OSM needs change. There should be some
> sort of committee with a clear vision that would enforce a unified style of
> mapping.
>
> While central power may be useful and offer some benefits, it is really
> poor place for it.
>
> Either some agreement can be reached and such committee is not needed or
> they
> would make decisions where large part of community disagrees with it.
>
> Except cases where this is absolutely needed, such entity would do more
> damage
> than benefit.
>
> It is absolutely ridiculous that we have features that are mapped in 2 or
> more different ways simultaneously e.g. riverbanks or sidewalks... Who is
> supposed to use and rely on such data?
>
> Duplicate tags are mildly irritating while processing, but it is not a
> serious or main problem for
> data consumers.
>
> (and it is from person who put a lot of effort into tagging improvements,
> wikifiddling,
> deprecating some unwanted values, deduplication and validator-related work
> and has
> some experience from data consumer side)
>
>
> Martin
>
>
>
> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan
>
> I actually just found that article about OSM’s problems.
> One of the major topics mentioned, the fact that OSM acts as a database and
> not a map, and that this acts as a hinderance to the expansion and
> development of the project, is very true.
> As a result, I’ve came to think that implementing Vector tiles should be
> OSM’s #1 development priority right now. If people who find OSM realize
> that there’s a lot more data than just the raster images displayed by the
> standard tile layer, than they will be more likely to contribute and g

Re: [Tagging] Basic cartography features missing, why?

2020-11-07 Thread Seth Deegan
I actually just found that article about OSM’s problems.

One of the major topics mentioned, the fact that OSM acts as a database and
not a map, and that this acts as a hinderance to the expansion and
development of the project, is very true.

As a result, I’ve came to think that implementing Vector tiles should be
OSM’s #1 development priority right now. If people who find OSM realize
that there’s a lot more data than just the raster images displayed by the
standard tile layer, than they will be more likely to contribute and grow
the OSM community.

We’re all here complaining about computational needs required by rendering
servers, but there are some great vector tile implementations that require
way less computational needs.

Moral of the story: We need Vector tiles.

El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger 
escribió:

> This is great information, I didn't know about your project, very very
> interesting. I have recently come to understand the OSM-Carto technical
> challenges recently. I haven't given it much of a thought as a casual
> mapper for the past two years, just been a bit disappointed with how it
> looks.
>
> I am a programmer in profession though so when taking a deeper look and
> though about it I see these challenges.
>
> However, and this is a big however, I think that the face of
> openstreetmap really need to be a cartographic sound map. It's not right
> that a style seemingly designed mainly for speedy diagnosis should be
> the face of OSM. How many of our mappers are so technical that they
> understand this? And howcome did I not even know about this cartographic
> project of yours? If there are great styles out there but noone knows
> about them that's a problem.
>
> And even if we let the not-so-good-cartography be the first map we see
> on openstreetmap.org (which makes no sense), some of the other layers
> presented there should be one which focus on good cartography, and all
> that are there now have many of the same issues as the main style.
>
> I assume that many, perhaps most, casual mappers use the web editor. I'm
> really impressed with the web editor, it's great and is mostly
> user-friendly, you don't need to be a technical person to map, and that
> is how I think it should be. One thing with the web editor though is
> that unless you are technical enough to turn off caching (which
> essentially means putting the browser in development mode), you won't
> see the rendered results for a long time, even if reloading the page,
> you still get cached data. Thus it wouldn't matter if the rendering
> wasn't updated for a couple of hours or even more, the casual mapper
> won't see it anyway.
>
> I think that direct feedback is desirable of course, but compared to
> other goals I think it's less important, and one can work with the user
> interface in the web editor to mitigate this issue. Perhaps just have a
> way to probe the server so it can deliver some render status. The
> biggest problem today with the web editor regarding feedback is that to
> a casual mapper it may not be obvious that the map needs to be rendered
> at all and that can take time, and together with the web caching and
> different zoom levels it gets even more confusing. Many of us more
> experienced mappers know exactly how OSM works and renders, and we go
> blind for how a new user will experience it.
>
> One way to mitigate this could be to turn on some render info view in
> the web interface to show render status of tiles, maybe even estimated
> time left, and then a way to refresh the tiles without having to resort
> to putting the web browser in development mode with disabled cache.
>
> And now to the most important point, whether one likes it or not,
> OSM-Carto as being the face of OSM and the most commonly used style, is
> the de-facto reference and driver of features and tagging. If OSM-Carto
> doesn't support basic cartography features many mappers won't be
> motivated to tag for that, and then the cartographic styles will have
> less information than they need to make good maps. OSM-Carto due to its
> limited rendering capabilities also make casual mappers tempted to "tag
> for the renderer" just to get results, which for example can mean that
> villages are upped, and thus the cartographic style will get fed with
> incorrect information.
>
> In summary I think there are *very* strong arguments for that the main
> style shown at openstreetmap.org and the main style used for editors
> should be focused on providing great cartography (with the extension
> that it should probably present more features than a usual map,
> alternatively we need to split into several styles, all cartographic
> sound), and we must allow it to be be more computationally expensive and
> come up with smart ways to mitigate that in the tools. We can't
> stubbornly hold on to principles and use the same arguments that held up
> and worked well back in 2004, there are things that need to be revised.
> And one of 

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Seth Deegan
A gravel area tag/tagging convention is needed. One use I’ve seen is
highways in particular seem to have gravel separator between the actual
road and usually grass. Standardizing a area (a way) with just the
surface=gravel tag could work.

El El vie, nov. 6, 2020 a la(s) 12:34, Anders Torger 
escribió:

> Hello everyone, newcomer here!
>
> I've been a casual contributing mapper for a couple of years here in
> Sweden. Only since 2018 :-O, I thought it was longer, and during this
> time I've made 1700 edits mostly using iD, just started using JOSM for
> some more complex edits. Anyway, I recently tried to up my game to make
> really high quality and "complete" maps in the areas I live. I have a
> lot of local knowledge combined with very high quality government maps
> (already preloaded into the editor, not the highest resolution version,
> but enough for most aspects) together with satellite images which today
> has much better alignment than a few years ago (still government maps
> are best on that). So good reference is there too, I have all I need to
> make a good job.
>
> My areas are bit more rural, more nature. Villages, hamlets and towns.
> Nature is prominent and naming nature is important, many old names but
> still in active use by forestry, outdoor people, hunters and locals.
> When mapping these, I immediately run into basic issues that I'm
> surprised that they aren't solved already.
>
> I'm not 100% sure if this mailing list is the right venue for discussing
> these issues. OSM as a community is quite hard to grasp for a newcomer
> and I have been sent to different places, but now I'm here.
>
> Anyway, my observations (mostly using the default openstreetmap-carto
> style) :
>
> ** Tagging bays and straits as areas work great, as the renderer gets
> and idea how prominent it is and it can make proper text sizing and they
> can be seen even if zoomed out if the area is large. Lots of our lakes,
> even quite small ones have sub-naming, and with these features I can
> make really good mapping of this.
>
> ** Tagging and naming areas on ground does not seem to be developed much
> at all, unfortunately.
>
> ** There is natural=peninsula so one can tag and name an area of varying
> size, but it doesn't seem to render (unless I've made some mistake...)
>
> ** I can't make an area to name hills or slopes, which is very common
> around here (natural=hill would be nice and is more generic than slope).
> There's peak, but that's only for point for the highest peak with
> elevation, so it doesn't the purpose here.
>
> ** Valleys can only be tagged as ways, but here it would make much more
> sense to make an area, as sizes of these valleys vary a lot, and the
> renderer need to know how large this is (not just how long) to make sane
> renders.
>
> ** Due to limitations in area-based name tagging the map looks empty
> just when zoomed out a little, as names disappear almost directly, so
> despite detailed mapping and tagging the overview map is not as useful
> as it could be. While the renderer can and does make proper decisions of
> prominence for bays and strait made as areas, point-based natural names
> often yield strange and misleading maps as vastly different sized areas
> have just a point for the name and no other differentiator, there's no
> way the renderer can make an appropriate render decision as the data is
> not there.
>
> ** Support for group naming is limited. It's here very common that
> several smaller islands are named as a group, smaller ponds are named as
> a group etc, without having individual names. There are tags for that
> (group/cluster), but not rendered. The best alternative today is to make
> it a named multipolygon, but only few renderers make the expected
> result, ie one name rather than only in one subarea or duplicated in all
> areas (which looks strange as the name is often in plural form, or it
> doesn't show up at all if each subarea is small).
>
> ** Another fairly common group naming concept is when each feature has
> its own name, but the group of features have also a separate collective
> name. Maps supporting this concept will thus when you zoom out not show
> the individual names but only the group name. The group/cluster tag
> would perhaps be the way to do this, but as far as I know no current
> style supports it.
>
> ** As a minor note, I've noted there is no good tag for anonymous gravel
> yards, which there are a lot of here. Abandoned quarry is the closest,
> but still not right, as only some actually were gravel/sand pits to
> start with. Those gravel yards are often leftovers from construction
> work or forestry often even locals don't exactly know when or why they
> were made. Today they are used mainly used for parking by people being
> out in nature, but they are not maintained so they are not exactly
> parking lots either.
>
> The central issue here is about naming though, support for group naming
> and the ability to name areas on land which just