Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Joseph Eisenberg]

Natural=peak must be a local high point, so it has to be at least a
few meters higher than the surrounding land. A natural=peak does not
have to be the highest point of a mountain, but it has to have some
topographical prominence. Not all spot elevations on USGS are of
peaks, some are just a visually prominent part of a ridge, and other
are saddles.

In October 2018 there was a suggestion to use the value "promontory"
for points that are not peaks, for example a prominent shoulder of a
mountain or the end of a ridge. Thus natural=promontory could work,
along with ele=* and name=* for some of these features.

Wikipedia definition:
https://en.wikipedia.org/wiki/Promontory

Link to previous discussion:
https://lists.openstreetmap.org/pipermail/tagging/2018-October/039659.html

On 3/9/19, Martijn van Exel  wrote:
> Perhaps they should be tagged not as peaks then but as a place node
> (place=locality probably)?
>
>> On Mar 8, 2019, at 10:23 AM, Mike Thompson  wrote:
>>
>>
>>
>> On Fri, Mar 8, 2019 at 6:29 AM Kevin Broderick > > wrote:
>>
>> Would https://www.openstreetmap.org/node/4992960980
>>  be an example of (or very
>> similar to) what you're talking about?
>> Yes, slightly different, but same general concept.
>>
>>
>> I've been told that one is a local reference point ("25 Short", ie. 25
>> feet short of 10k), and at least one article
>> (https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole
>> )
>> backs that up.
>> I have seen back country trip reports mention such points (at least those
>> that are high points), and they have *some* value therefore, but as I
>> suggested earlier, "point n,nnn" is to me more of a description rather
>> than a name in most cases.
>>
>> Mike
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Kevin Kenny]

On Fri, Mar 8, 2019 at 5:46 PM Phil! Gold  wrote:
> I started work last year on a better system that generates SVGs on the fly
> from OSM data, so it doesn't need the pregeneration step.  I got bogged
> down with other things before I quite finished, but it's mostly there.
It's really great hearing from you!  I had tried to message you a few
times through OSM and tried to find a working email for you, but never
heard anything back. I definitely had things I wanted to pick your
brain about!

> (There are just a few Canadian routes left to convert; I was having
> difficulty finding official specs for their signs.)

I think that between Minh and me, we have the signs for all ten Canadian
provinces, and a lot of Ontario counties. (The other provinces use a standard
'county highway' sign.)

I'll have a look at your code, but frankly, we've diverged an awful
lot at this point. I got kind of bogged down in the stored procedures,
because the requirement that the PostgreSQL filesystem be visible at
Mapnik's runtime was getting tangled up in the chroot jail on my
server, and the fact that a stock Mapnik now makes a read-only
connection to the database was also a stumbling block. (Even a trigger
firing from a read-only connection cannot update the database.) Rather
than running from forks, I wound up reworking things so that the SVG
generation happens when osmosis runs, rather than when the tile is
built, and that went a lot smoother.

I also pretty much totally reworked the stored procedures for better
readability, and to make them compatible with the GroupSymbolizer.
(Your shield clusters are gorgeous, but I found them to be a bridge
too far and decided to try out Mapnik's stock support.) Could I get
your opinion of
https://github.com/kennykb/osm-shields/blob/master/queryprocs.sql.in ?
 I think that might be a more maintainable starting point, and it also
appears to be faster - it's pretty zippy at render time.
>
> I don't think this is really documented yet, but I now support four
> different sign styles, passed as the `style` parameter to the Python
> rendering functions:
>
>  * "generic" uses a standard, generic style for every US state and county,
>disregarding their individual styles.
>  * "guide" matches the styles used on highway guide signs.  This is now
>the default, since it seems most fitting to map rendering.
>  * "sign" looks like the roadside reassurance markers.
>  * "cutout" is a modification of the "sign" style to remove dark
>background areas.  This used to be the default with my old system.

Sounds reasonable. I'm making more use of pictorial shields than I
think you were, but in some cases that's a bad idea. I'd like to have
the 'guide' style, for instance, in place of all the pictorial shields
for the NY state parkways - the NY highway shield, but white-on-green
instead of black and white, with the parkway's initials.

> Anyway, the code is here:
>
>   https://gitlab.com/asciiphil/osm-shields
>
> Hopefully at some point I'll find time to finish up my changes.  (And,
> ideally, merge in all of the extra shields you and Minh have put
> together.)

Thanks, I'll have a look!

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Bryan Housel]

Good question!
As others have said - hotels have rooms that open indoors, motels have rooms 
that open outdoors.  That’s the only difference.

I did a bit of research on this last year for 
https://github.com/osmlab/name-suggestion-index 
 because we are using this 
project to capture the recommended tagging for all the brands of the world.

Check out the hotel/motel files here if you are curious!
https://github.com/osmlab/name-suggestion-index/tree/master/brands/tourism 


For example:
Super 8 is almost always tagged as `tourism=motel`, and Travelodge is almost 
always tagged as `tourism=hotel`, even though both brands often exist in either 
kind of building.

I think this is one of those tags where it really doesn’t matter much which one 
people use.

Bryan



> On Mar 8, 2019, at 7:47 PM, Peter Dobratz  wrote:
> 
> How do you distinguish between the tourism=hotel and tourism=motel tags?
> 
> The criteria that I was imagining is that a motel is a single story building 
> where you have the ability to park you car directly outside of your room. A 
> hotel would be other types of buildings such as multi-story where most guests 
> cannot park directly outside their room.
> 
> There's the curious case of the two Motel 6 facilities directly across the 
> road from each other.  I had marked these as tourism=hotel based on the 
> building architecture, but maybe all Motel 6's should be tourism=motel?
> 
> https://www.openstreetmap.org/note/1645570 
> 
> 
> What do you think?
> 
> Thanks,
> Peter
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[OSM Volunteer stevea]

As I believe the etymology of the word "motel" (circa 1920s) is a contraction 
of "motor hotel," I believe it is fair to say that a motel is a hotel which 
caters to motorists.  That is, patrons who arrive in an automobile and wish for 
it to be immediately accessible, as in parked directly outside the room in the 
case of a single story facility, or very nearby for multiple story.

Others say hotels are "closer to an airport or business district" and while 
this is a more general criterion, (think of resort hotels where you do not 
arrive in your automobile as an exception, for example), I believe that "caters 
to motorists" is the defining difference for motels.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Joseph Eisenberg]

This was discussed at the main Tagging mailing list a couple of months ago:

Start of thread:
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041597.html
Continuation in January:
https://lists.openstreetmap.org/pipermail/tagging/2019-January/041720.html

The wiki page for Motel was updated at that time:
https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dmotel

A number of people said that the name on the sign is the main way to
distinguish a hotel vs a motel, but some thought that the easy access
to no-fee motor vehicle parking from the rooms was also a useful
distinction.


On 3/9/19, Martijn van Exel  wrote:
> I've slept in some pretty nice places that had exterior room access. I
> wouldn't call that out as the only demarcating property. To my mind it's a
> combination of location, amenities and layout / architecture.
>
> Interesting discussion!
>
> Martijn van Exel
>
>> On Mar 8, 2019, at 18:03, Tod Fitch  wrote:
>>
>> For me the difference is interior hallway to access room (hotel) vs
>> exterior access to each room (motel).
>>
>>
>>> On March 8, 2019 4:47:33 PM PST, Peter Dobratz  wrote:
>>> How do you distinguish between the tourism=hotel and tourism=motel tags?
>>>
>>> The criteria that I was imagining is that a motel is a single story
>>> building where you have the ability to park you car directly outside of
>>> your room. A hotel would be other types of buildings such as multi-story
>>> where most guests cannot park directly outside their room.
>>>
>>> There's the curious case of the two Motel 6 facilities directly across
>>> the road from each other.  I had marked these as tourism=hotel based on
>>> the building architecture, but maybe all Motel 6's should be
>>> tourism=motel?
>>>
>>> https://www.openstreetmap.org/note/1645570
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> Peter
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Martijn van Exel]

I've slept in some pretty nice places that had exterior room access. I wouldn't 
call that out as the only demarcating property. To my mind it's a combination 
of location, amenities and layout / architecture.

Interesting discussion!

Martijn van Exel

> On Mar 8, 2019, at 18:03, Tod Fitch  wrote:
> 
> For me the difference is interior hallway to access room (hotel) vs exterior 
> access to each room (motel).
> 
> 
>> On March 8, 2019 4:47:33 PM PST, Peter Dobratz  wrote:
>> How do you distinguish between the tourism=hotel and tourism=motel tags?
>> 
>> The criteria that I was imagining is that a motel is a single story building 
>> where you have the ability to park you car directly outside of your room. A 
>> hotel would be other types of buildings such as multi-story where most 
>> guests cannot park directly outside their room.
>> 
>> There's the curious case of the two Motel 6 facilities directly across the 
>> road from each other.  I had marked these as tourism=hotel based on the 
>> building architecture, but maybe all Motel 6's should be tourism=motel?
>> 
>> https://www.openstreetmap.org/note/1645570
>> 
>> What do you think?
>> 
>> Thanks,
>> Peter
>> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Tod Fitch]

For me the difference is interior hallway to access room (hotel) vs exterior 
access to each room (motel).


On March 8, 2019 4:47:33 PM PST, Peter Dobratz  wrote:
>How do you distinguish between the tourism=hotel and tourism=motel
>tags?
>
>The criteria that I was imagining is that a motel is a single story
>building where you have the ability to park you car directly outside of
>your room. A hotel would be other types of buildings such as
>multi-story
>where most guests cannot park directly outside their room.
>
>There's the curious case of the two Motel 6 facilities directly across
>the
>road from each other.  I had marked these as tourism=hotel based on the
>building architecture, but maybe all Motel 6's should be tourism=motel?
>
>https://www.openstreetmap.org/note/1645570
>
>What do you think?
>
>Thanks,
>Peter

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Ian Dees]

I think your description of motels as parking directly outside rooms is
good, but I've seen plenty of motels that had multiple stories.

Wikipedia's page on motels is good and has this definition:

"a type of hotel consisting of a single building of connected rooms whose
doors faced a parking lot and in some circumstances, a common area or a
series of small cabins with common parking"

On Fri, Mar 8, 2019 at 6:49 PM Peter Dobratz  wrote:

> How do you distinguish between the tourism=hotel and tourism=motel tags?
>
> The criteria that I was imagining is that a motel is a single story
> building where you have the ability to park you car directly outside of
> your room. A hotel would be other types of buildings such as multi-story
> where most guests cannot park directly outside their room.
>
> There's the curious case of the two Motel 6 facilities directly across the
> road from each other.  I had marked these as tourism=hotel based on the
> building architecture, but maybe all Motel 6's should be tourism=motel?
>
> https://www.openstreetmap.org/note/1645570
>
> What do you think?
>
> Thanks,
> Peter
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Kevin Broderick]

I thought the defining architectural difference was whether access to the
room was via interior hallway (hotel) or exterior walkway (motel).

On Fri, Mar 8, 2019, 19:51 Shawn K. Quinn  wrote:

> On 3/8/19 18:47, Peter Dobratz wrote:
> > How do you distinguish between the tourism=hotel and tourism=motel tags?
> >
> > The criteria that I was imagining is that a motel is a single story
> > building where you have the ability to park you car directly outside of
> > your room. A hotel would be other types of buildings such as multi-story
> > where most guests cannot park directly outside their room.
>
> Some motels have two- or even three-story buildings. For me, the
> defining difference would be that a hotel is closer to an airport or
> business district and either has limited parking or charges for parking,
> whereas motels as I know them never charge for parking, and are often
> farther away from the business districts and airports.
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.com
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] motel vs. hotel

[Shawn K. Quinn]

On 3/8/19 18:47, Peter Dobratz wrote:
> How do you distinguish between the tourism=hotel and tourism=motel tags?
> 
> The criteria that I was imagining is that a motel is a single story
> building where you have the ability to park you car directly outside of
> your room. A hotel would be other types of buildings such as multi-story
> where most guests cannot park directly outside their room.

Some motels have two- or even three-story buildings. For me, the
defining difference would be that a hotel is closer to an airport or
business district and either has limited parking or charges for parking,
whereas motels as I know them never charge for parking, and are often
farther away from the business districts and airports.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] motel vs. hotel

[Peter Dobratz]

How do you distinguish between the tourism=hotel and tourism=motel tags?

The criteria that I was imagining is that a motel is a single story
building where you have the ability to park you car directly outside of
your room. A hotel would be other types of buildings such as multi-story
where most guests cannot park directly outside their room.

There's the curious case of the two Motel 6 facilities directly across the
road from each other.  I had marked these as tourism=hotel based on the
building architecture, but maybe all Motel 6's should be tourism=motel?

https://www.openstreetmap.org/note/1645570

What do you think?

Thanks,
Peter
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Phil! Gold]

* Phil! Gold  [2019-03-08 17:44 -0500]:
>   https://gitlab.com/asciiphil/osm-shields

Oops, that's the master branch, which doesn't have the changes.  You need
to look at the svg branch:

  https://gitlab.com/asciiphil/osm-shields/traa/svg
  
-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
#if _FP_W_TYPE_SIZE < 32
#error "Here's a nickle kid.  Go buy yourself a real computer."
#endif
   -- linux/arch/sparc64/double.h
 --- --

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Phil! Gold]

* Kevin Kenny  [2019-03-08 14:25 -0500]:
> On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel  wrote:
> >
> > I agree that a local US OSM map with a *subtly* adapted rendering would be 
> > fantastic. Phil Gold did some interesting work years ago on rendering US 
> > style highway shields taking into account (sometimes crazy) route 
> > concurrency 
> > (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B
> >  - note that this is based on years-old data and probably pre-carto-switch 
> > stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more 
> > divergent from the main map style, but another great example of initiatives 
> > around custom map rendering coming out of the US community.
> 
> I've borrowed ideas (and some limited amount of code) from both of
> them in doing my experimental rendering
[snip]
> The chief roadblocks to scaleability are that the graphics are
> generated in what amounts to a batch process, taking several minutes,
[snip]
> Then there's the issue that the graphics for individual shields are
> being stored in PNG, which is rendered in a batch process that takes
> typically several minutes (so could not cope with minutely updates).

I started work last year on a better system that generates SVGs on the fly
from OSM data, so it doesn't need the pregeneration step.  I got bogged
down with other things before I quite finished, but it's mostly there.
(There are just a few Canadian routes left to convert; I was having
difficulty finding official specs for their signs.)

I don't think this is really documented yet, but I now support four
different sign styles, passed as the `style` parameter to the Python
rendering functions:

 * "generic" uses a standard, generic style for every US state and county,
   disregarding their individual styles.
 * "guide" matches the styles used on highway guide signs.  This is now
   the default, since it seems most fitting to map rendering.
 * "sign" looks like the roadside reassurance markers.
 * "cutout" is a modification of the "sign" style to remove dark
   background areas.  This used to be the default with my old system.

Anyway, the code is here:

  https://gitlab.com/asciiphil/osm-shields

Hopefully at some point I'll find time to finish up my changes.  (And,
ideally, merge in all of the extra shields you and Minh have put
together.)

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
What computers do Daleks use?  X-TERMINALS, X-TERMINALS!
 --- --

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Martijn van Exel]

Kevin — yes, I was talking about SOTM US. Please do stay tuned to this list and 
OSM US blog for announcements for community scholarships and other initiatives 
we will deploy to make it possible to have many more community members attend 
(and also present! on interesting topics like this one.)

> On Mar 8, 2019, at 12:25 PM, Kevin Kenny  wrote:
> 
> Finding the time and money to attend a conference that my employer
> doesn't sponsor is hard for me at the moment, particularly since I'm
> already committed once or twice a year to conferences on another "free
> time" (hah!) project. (Also, I presume you mean SOTM-US? An overseas
> conference would add a whole other level of complexity to my getting
> to go.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Kevin Kenny]

On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel  wrote:
>
> I agree that a local US OSM map with a *subtly* adapted rendering would be 
> fantastic. Phil Gold did some interesting work years ago on rendering US 
> style highway shields taking into account (sometimes crazy) route concurrency 
> (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B
>  - note that this is based on years-old data and probably pre-carto-switch 
> stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more 
> divergent from the main map style, but another great example of initiatives 
> around custom map rendering coming out of the US community.

I've borrowed ideas (and some limited amount of code) from both of
them in doing my experimental rendering at
https://kbk.is-a-geek.net/catskills/test4.html. It has North American
highway shields. I say 'North American' because it handles the
Canadian and a few Mexican ones, with concurrences, also.  It has a
lot more than Phil! incorporated thanks to a yeoman effort by Minh
Nguyen (sorry, Minh, no time to go hunting for Vietnamese diacritics
to spell your name correctly!)

It has scalability issues that are fixable, but imply ditching a fair
piece of the toolchain.
I'm tracking a project for it at
https://github.com/kennykb/osm-shields/projects.  I have a Kanban for
it at https://github.com/kennykb/osm-shields/projects/1.

The chief roadblocks to scaleability are that the graphics are
generated in what amounts to a batch process, taking several minutes,
triggered by the Osmosis update of the 'northamerica' export from
geofabrik.de. If the process is to scale to minutely updates and the
whole planet, it needs to do shield rendering incrementally in
response to specific updates affecting it.

The fact that osm2pgsql does not and will not ever support querying of
relations at rendering time is a headache, and so the first job will
have to be retooling everything to the table formats used by imposm3.
(This is entirely doable; it's quite a lot of very routine programming
that I've simply not had time to take on.)
https://github.com/kennykb/osm-shields/issues/13

Then there's the issue that the graphics for individual shields are
being stored in PNG, which is rendered in a batch process that takes
typically several minutes (so could not cope with minutely updates). I
have some sketches for how that could be accomplished, but again, I
keep running out of time.
https://github.com/kennykb/osm-shields/issues/5

Also, 'carto' does not have support for the GroupSymbolizer in Mapnik,
needed for highway shield rendering, so I'm still stuck with defining
the rendering in Mapnik XML. This isn't a problem for me, but others
might demand better support.

Finally, Mapnik itself would benefit from being able to render SVG's
with template parameters substituted from objects in the database. I
think that the pipeline could be implemented in a scalable fashion
without this last task, but there would be more custom code about.

I've sounded out the maintainers of various of the OSM software, and
get different assessments.
osm2pgsql - Actively hostile to supporting what I need, contend that
osm2pgsql is the wrong tool for the job.
imposm3 - Interested and helpful, and it appears that they wouldn't
actually have to do anything (imposm3 may have everything needed
'right out of the box').
Phil Gold!'s 'highway shields' project - Moribund, but I've extracted
from it what I think I need and put the code at
https://github.com/kennykb/osm-shields/
TopOSM - Again, moribund, but I have working renderings derived from
it that suit me and could serve as starting points for new
development.
Carto - Maintainers would be very interested in GroupSymbolizer support.
OSM Carto - Little interest, but that's because of the emphasis on
consistent rendering worldwide, and this is really a project specific
to North America.
Mapnik - I've not really needed to approach the Mapnik team yet - I've
been treating it as a black box.

So, it looks as if there's a path forward, but it involves a bunch
more programming than I've had time to take on. I'm very good at
programming, but my time is limited. I'm much less good at project
management, and I'm terrible at recruiting, so I've been unable so far
to form a team to tackle this. A better leader than I could probably
make significant forward progress with my technical assistance. I may
find this thrust upon me, but I hope to dodge any requests to lead
open-source development efforts while I'm still in the paid workforce.
(With luck, retirement is a couple or three years away.)

> Perhaps something for a BoF session at the next SOTM!

Finding the time and money to attend a conference that my employer
doesn't sponsor is hard for me at the moment, particularly since I'm
already committed once or twice a year to conferences on another "free
time" (hah!) project. (Also, I presume you mean SOTM-US? An overseas
conference would add a whole other level of complexity to 

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Martijn van Exel]

Perhaps they should be tagged not as peaks then but as a place node 
(place=locality probably)?

> On Mar 8, 2019, at 10:23 AM, Mike Thompson  wrote:
> 
> 
> 
> On Fri, Mar 8, 2019 at 6:29 AM Kevin Broderick  > wrote:
> 
> Would https://www.openstreetmap.org/node/4992960980 
>  be an example of (or very 
> similar to) what you're talking about? 
> Yes, slightly different, but same general concept.  
> 
> 
> I've been told that one is a local reference point ("25 Short", ie. 25 feet 
> short of 10k), and at least one article 
> (https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole
>  
> )
>  backs that up.
> I have seen back country trip reports mention such points (at least those 
> that are high points), and they have *some* value therefore, but as I 
> suggested earlier, "point n,nnn" is to me more of a description rather than a 
> name in most cases.
> 
> Mike
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Mike Thompson]

On Fri, Mar 8, 2019 at 6:29 AM Kevin Broderick 
wrote:

>
> Would https://www.openstreetmap.org/node/4992960980 be an example of (or
> very similar to) what you're talking about?
>
Yes, slightly different, but same general concept.


> I've been told that one is a local reference point ("25 Short", ie. 25
> feet short of 10k), and at least one article (
> https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole)
> backs that up.
>
I have seen back country trip reports mention such points (at least those
that are high points), and they have *some* value therefore, but as I
suggested earlier, "point n,nnn" is to me more of a description rather than
a name in most cases.

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Martijn van Exel]

I agree that a local US OSM map with a *subtly* adapted rendering would be 
fantastic. Phil Gold did some interesting work years ago on rendering US style 
highway shields taking into account (sometimes crazy) route concurrency 
(http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B
 

 - note that this is based on years-old data and probably pre-carto-switch 
stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more 
divergent from the main map style, but another great example of initiatives 
around custom map rendering coming out of the US community.

Perhaps something for a BoF session at the next SOTM!

Finally, I don’t think it’s a funding or infrastructure issue. It’s just that 
someone needs to lead it.

Martijn

> On Mar 8, 2019, at 9:27 AM, Kevin Kenny  wrote:
> 
> On Fri, Mar 8, 2019 at 10:59 AM Martijn van Exel  wrote:
>> If it’s just a shortcut to have the main OSM map display elevation in feet, 
>> that’s not right, but it indicates a need that is currently unaddressed: 
>> displaying elevation in local units on the main map.
> 
> Even as a USAian, I'm fine with SI units on the main map. If the
> USAians need a map localised to US conventional units, let the USAians
> host it.
> 
> (and openstreetmap.us miught be a perfect place to put such a thing,
> but I know, the infrastructure and funding really isn't there.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Kevin Kenny]

On Fri, Mar 8, 2019 at 10:59 AM Martijn van Exel  wrote:
> If it’s just a shortcut to have the main OSM map display elevation in feet, 
> that’s not right, but it indicates a need that is currently unaddressed: 
> displaying elevation in local units on the main map.

Even as a USAian, I'm fine with SI units on the main map. If the
USAians need a map localised to US conventional units, let the USAians
host it.

(and openstreetmap.us miught be a perfect place to put such a thing,
but I know, the infrastructure and funding really isn't there.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Martijn van Exel]

If it’s locally known as such, to my mind, it’s totally fine tagging it that 
way, even if it’s only by backcountry skiers. I would say this is common in 
OSM, I see (and appreciate) a lot of named trails that are not always 
signposted as such but locally known by those names (like 
https://www.openstreetmap.org/way/624949038 
). Local knowledge trumps most 
everything in OSM.

If it’s just a shortcut to have the main OSM map display elevation in feet, 
that’s not right, but it indicates a need that is currently unaddressed: 
displaying elevation in local units on the main map. I don’t see a ticket 
currently on the osm-carto repo that addresses this. I think it would be hard 
to get ’regional’ rendering preferences accepted however. A better / other way 
to improve on this is to change the convention for the ele tag to be more like 
maxspeed: default to meters but allow other units to be entered as ‘8801 ft’ 
for a value. Then osm-carto could pick that up more easily.

Martijn

> On Mar 8, 2019, at 6:27 AM, Kevin Broderick  wrote:
> 
> To elaborate on my previous response, now that I'm back at a computer:
> 
> Would https://www.openstreetmap.org/node/4992960980 
>  be an example of (or very 
> similar to) what you're talking about?
> 
> I've been told that one is a local reference point ("25 Short", ie. 25 feet 
> short of 10k), and at least one article 
> (https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole
>  
> )
>  backs that up. The old USGS quad does have a point elevation of 9975' on 
> that knob, but it looks to more properly be a shoulder of a larger mountain, 
> not a proper mountain on its own.
> 
> I'm not suggesting that the current tagging is correct, but in this case (and 
> I believe in some others, although I don't even have anecdotes to back that 
> up), point elevation marks on USGS maps have become the "names" for local 
> topographical features. They're a little wonky on the 
> on-the-ground-verifiability (you can easily verify that a height-of-land 
> exists there, but I don't know that there's a sign or survey marker 
> indicating "this is 9975" or "this is 25 Short"), but [some] locals who 
> travel in the vicinity will use the reference. So it seems like something 
> that may be very reasonable to map, but I don't know what the best tagging 
> scheme is. I do think that normalizing to meters loses the meaning in the 
> current tag-for-the-renderer scheme, because a '3040m' label isn't going to 
> translate well to '25 Short' or '9975' unless you happen to particularly good 
> at math.
> 
> On Fri, Mar 8, 2019 at 4:53 AM Dave Swarthout  > wrote:
> This is simply a way to get an otherwise unnamed peak to render and also, I 
> suspect, to sidestep the inconvenience of converting the elevation to meters. 
>  AFAIK, there are no peaks with the generic name "Point" on any USGS Topos. 
> In addition, placing the elevation into the name is another trick that should 
> be discouraged.
> 
> On Fri, Mar 8, 2019 at 2:38 PM Mateusz Konieczny  > wrote:
> If it is a peak then ele=XXX and noname=yes would be OK.
> 
> If it is not a peak it should not be present at all - otherwise it opens way 
> to importing
> LIDAR data into OSM (and there are datasets with resolution of 5 cm, dumping 
> it
> into OSM would be case of unverifiable data making it impossible to edit).
> 
> I opened https://www.openstreetmap.org/note/1703462 
>  to reduce chance that it will be 
> discussed 
> and forgotten.
> 
> If this is really used name - then it would be OK but my bet is that this is 
> not an actually used name.
> 
> Mar 7, 2019, 7:04 PM by miketh...@gmail.com :
> It seems that there are a couple of mappers in Colorado US (at least, perhaps 
> mapping in other areas as well) who are adding spot elevations (presumably 
> from USGS Topo maps) to OSM tagging them as 
> natural=peak
> name=Point (elevation in feet)
> 
> For example:
> https://www.openstreetmap.org/node/4601119717 
> 
> 
> What does the community think about this?
> 
> natural=peak might be ok if said spot elevation is really a local high point 
> (some are not).  The name I am less sure of. If this belongs on the map at 
> all, it should probably have an ele tag, with value in meters.
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us 
> 
> 
> 
> -- 
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at 

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Kevin Kenny]

On Fri, Mar 8, 2019 at 2:38 AM Mateusz Konieczny
 wrote:
> If it is a peak then ele=XXX and noname=yes would be OK.
>
> If it is not a peak it should not be present at all - otherwise it opens way 
> to importing
> LIDAR data into OSM (and there are datasets with resolution of 5 cm, dumping 
> it
> into OSM would be case of unverifiable data making it impossible to edit).

If it isn't a peak, it's a spot elevation of something else. Map the
thing, tag its elevation. Some things don't have names.

If there's a spot elevation that isn't associated with a thing, ignore
it. There are better sources for elevation data. But few maps show
these. In the databases, most spot elevations that aren't 'real'
natural or human features are monumented trig points and can be tagged
as such.

So Mateusz is right, mostly.  Things other than peaks have elevations,
and if there's a real thing with a spot elevation, map it!



On Fri, Mar 8, 2019 at 4:53 AM Dave Swarthout  wrote:
>
> This is simply a way to get an otherwise unnamed peak to render and also, I 
> suspect, to sidestep the inconvenience of converting the elevation to meters. 
>  AFAIK, there are no peaks with the generic name "Point" on any USGS Topos. 
> In addition, placing the elevation into the name is another trick that should 
> be discouraged.

Agreed that the practice should be discouraged - if that in fact is
what's going on.

On the other hand, in the Catskills there are multiple summits NAMED
'High Peak' and 'High Point'.  The hikers distinguish them by
decorating the names: 'Windham High Peak', 'Kaaterskill High Peak',
'Ashokan High Point', ...  Many otherwise nameless peaks in the
Adirondacks have been given names by hikers, 'Northrop Lake Mountain',
'West Lake Mountain' and so on, and as Kevin Broderick points out,
some simply are referred to by their elevation on old topo maps -
which often is quite inaccurate, but tend to remain the names of
things even after more accurate elevation determinations have been
made.

So don't assume that a 'onesy-twosey' tagging of a spot named by its
elevation is wrong unless there's an obvious mass-tagging going on -
particularly if the mapper who tagged it is responsive!

(Yes, the US has a Board of Geographic Names - but its only authority
is to dictate the names that go on official US Government maps.
Otherwise, in the US, the name of a thing is whatever people call it.
Don't expect to find authoritative answers for many names.)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Kevin Broderick]

To elaborate on my previous response, now that I'm back at a computer:

Would https://www.openstreetmap.org/node/4992960980 be an example of (or
very similar to) what you're talking about?

I've been told that one is a local reference point ("25 Short", ie. 25 feet
short of 10k), and at least one article (
https://rootsrated.com/stories/a-quick-and-dirty-guide-to-the-best-backcountry-skiing-in-jackson-hole)
backs that up. The old USGS quad does have a point elevation of 9975' on
that knob, but it looks to more properly be a shoulder of a larger
mountain, not a proper mountain on its own.

I'm not suggesting that the current tagging is correct, but in this case
(and I believe in some others, although I don't even have anecdotes to back
that up), point elevation marks on USGS maps have become the "names" for
local topographical features. They're a little wonky on the
on-the-ground-verifiability (you can easily verify that a height-of-land
exists there, but I don't know that there's a sign or survey marker
indicating "this is 9975" or "this is 25 Short"), but [some] locals who
travel in the vicinity will use the reference. So it seems like something
that may be very reasonable to map, but I don't know what the best tagging
scheme is. I do think that normalizing to meters loses the meaning in the
current tag-for-the-renderer scheme, because a '3040m' label isn't going to
translate well to '25 Short' or '9975' unless you happen to particularly
good at math.

On Fri, Mar 8, 2019 at 4:53 AM Dave Swarthout 
wrote:

> This is simply a way to get an otherwise unnamed peak to render and also,
> I suspect, to sidestep the inconvenience of converting the elevation to
> meters.  AFAIK, there are no peaks with the generic name "Point" on any
> USGS Topos. In addition, placing the elevation into the name is another
> trick that should be discouraged.
>
> On Fri, Mar 8, 2019 at 2:38 PM Mateusz Konieczny 
> wrote:
>
>> If it is a peak then ele=XXX and noname=yes would be OK.
>>
>> If it is not a peak it should not be present at all - otherwise it opens
>> way to importing
>> LIDAR data into OSM (and there are datasets with resolution of 5 cm,
>> dumping it
>> into OSM would be case of unverifiable data making it impossible to edit).
>>
>> I opened https://www.openstreetmap.org/note/1703462 to reduce chance
>> that it will be discussed
>> and forgotten.
>>
>> If this is really used name - then it would be OK but my bet is that this
>> is not an actually used name.
>>
>> Mar 7, 2019, 7:04 PM by miketh...@gmail.com:
>>
>> It seems that there are a couple of mappers in Colorado US (at least,
>> perhaps mapping in other areas as well) who are adding spot elevations
>> (presumably from USGS Topo maps) to OSM tagging them as
>> natural=peak
>> name=Point (elevation in feet)
>>
>> For example:
>> https://www.openstreetmap.org/node/4601119717
>>
>> What does the community think about this?
>>
>> natural=peak might be ok if said spot elevation is really a local high
>> point (some are not).  The name I am less sure of. If this belongs on the
>> map at all, it should probably have an ele tag, with value in meters.
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Spot elevations collected as natural=peak and name=Point (height in feet)

[Dave Swarthout]

This is simply a way to get an otherwise unnamed peak to render and also, I
suspect, to sidestep the inconvenience of converting the elevation to
meters.  AFAIK, there are no peaks with the generic name "Point" on any
USGS Topos. In addition, placing the elevation into the name is another
trick that should be discouraged.

On Fri, Mar 8, 2019 at 2:38 PM Mateusz Konieczny 
wrote:

> If it is a peak then ele=XXX and noname=yes would be OK.
>
> If it is not a peak it should not be present at all - otherwise it opens
> way to importing
> LIDAR data into OSM (and there are datasets with resolution of 5 cm,
> dumping it
> into OSM would be case of unverifiable data making it impossible to edit).
>
> I opened https://www.openstreetmap.org/note/1703462 to reduce chance that
> it will be discussed
> and forgotten.
>
> If this is really used name - then it would be OK but my bet is that this
> is not an actually used name.
>
> Mar 7, 2019, 7:04 PM by miketh...@gmail.com:
>
> It seems that there are a couple of mappers in Colorado US (at least,
> perhaps mapping in other areas as well) who are adding spot elevations
> (presumably from USGS Topo maps) to OSM tagging them as
> natural=peak
> name=Point (elevation in feet)
>
> For example:
> https://www.openstreetmap.org/node/4601119717
>
> What does the community think about this?
>
> natural=peak might be ok if said spot elevation is really a local high
> point (some are not).  The name I am less sure of. If this belongs on the
> map at all, it should probably have an ele tag, with value in meters.
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us