Re: [Tagging] highway = track vs. residential

[Mateusz Konieczny]

On Thu, 7 Jan 2016 15:15:00 -0700
Mike Thompson  wrote:

> I am editing in Colorado, US in a rural part of the state. I do have
> first hand knowledge of the area. It looks like someone has gone
> through and changed many ways tagged "highway = residential" to
> "highway = track."  For example:
> 
> https://www.openstreetmap.org/way/6152252#map=16/40.7825/-105.1985
> 
> Although these are gravel surfaced roads (not yet tagged that way, but
> physically that is what they are), the ones in question provide
> access to two or more homes and/or ranches.  To me these are not
> "tracks" but "residential." Before I change these back, I wanted to
> check with the community.
> 
> Also, I would like your opinion on driveways (if they are mapped at
> all). My understanding is that they (at least the part between the
> public road and the house) should be tagged highway=service,
> service=driveway, access=private and not highway=track.
> 
> Mike

Yes, highway is for tagging function, surface etc tags for quality.

Unpaved driveway is highway=service, service=driveway not highway=track
(proper surface tag and similar may be used to tag quality).

And high-quality asphalt logging road is highway=track.

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

Re: [Tagging] Elevation and height on vertical features

[Mike Thompson]

On Thu, Jan 7, 2016 at 3:40 PM, Colin Smale  wrote:

> Cliffs are never truly vertical. A bird's eye view from above will show
> that. If they are steep enough they could be modelled as a line, but in
> general we should allow for a polygon, with a high side and a low side.
>
Actually, sometimes they are "less than vertical", in other words,
overhanging, e.g. [1]

[1]
https://s-media-cache-ak0.pinimg.com/736x/9c/52/0e/9c520e8e1e327be4bc844b950544aac6.jpg
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation and height on vertical features

[Warin]

On 8/01/2016 9:56 AM, Colin Smale wrote:
Nobody will be using the raw data to fly a plane. It doesn't matter if 
we use the ele tag for the top or the bottom - as long as the height 
is given, the other value can easily be derived. What is important is 
consistency, both in its definition and it's usage. Defining it as 
sometimes the top and sometimes the bottom of a feature doesn't help.


And consistent with other mapping products/practices?

By convention maps uses blue to indicate sea, rivers and streams.
The idea is to be readily usable by using the same practice as others 
have used in the past.

 Not to set some new standard where there is no reason for it.

Grasping at straws .. the elevation of a mountain is given as its peak. 
If there is consistency within the map then the elevation of all objects 
should be their maximum height.


We will also need to standardize on a datum for elevations. The wiki 
refers to both mean sea level (which varies by country) and wgs84. The 
differences might be enough to take the wheels off your plane..


Good point there! :-)
For most it won't matter. What do international planes use as there 
reference for height? Use that - again consistency.


By maintaining some consistency with what has been done elsewhere it 
will make it easier to compare, check and confirm OSM data.



On 7 January 2016 22:50:02 CET, Warin <61sundow...@gmail.com> wrote:

On 8/01/2016 3:32 AM, Christoph Hormann wrote:

On Thursday 07 January 2016, Aaron Spaulding wrote:

Hi all, I’ve been working on generating 3D meshes based on
OSM data and I ran into a problem. Vertical features like
'natural=cliff', 'barrier=retaining_wall’ and
'waterway=waterfall' occupy two points in physical space,
but because of the 2D nature of OSM its ambiguous which
side of the feature that the ‘ele’ tag applies. 


For cliffs mapping conventions say that you should put the
line on top of the cliff in case it is not exactly vertical -
accordingly the ele tag would also refer to the top - but keep
in mind that the elevation does not have to be constant.



Consider who is going to use the map, and for what purpose.

The most critical use is for aeroplanes .. where the maximum height is
critical information!
I think for that reason alone most maps should indicate the maximum
elevation of an object.



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] Elevation and height on vertical features

[Colin Smale]

Nobody will be using the raw data to fly a plane. It doesn't matter if we use 
the ele tag for the top or the bottom - as long as the height is given, the 
other value can easily be derived. What is important is consistency, both in 
its definition and it's usage. Defining it as sometimes the top and sometimes 
the bottom of a feature doesn't help.
We will also need to standardize on a datum for elevations. The wiki refers to 
both mean sea level (which varies by country) and wgs84. The differences might 
be enough to take the wheels off your plane..


On 7 January 2016 22:50:02 CET, Warin <61sundow...@gmail.com> wrote:
>On 8/01/2016 3:32 AM, Christoph Hormann wrote:
>> On Thursday 07 January 2016, Aaron Spaulding wrote:
>>> Hi all,
>>>
>>> I’ve been working on generating 3D meshes based on OSM data and I
>ran
>>> into a problem. Vertical features like 'natural=cliff',
>>> 'barrier=retaining_wall’ and 'waterway=waterfall' occupy two points
>>> in physical space, but because of the 2D nature of OSM its ambiguous
>>> which side of the feature that the ‘ele’ tag applies.
>> For cliffs mapping conventions say that you should put the line on
>top
>> of the cliff in case it is not exactly vertical - accordingly the ele
>> tag would also refer to the top  - but keep in mind that the
>elevation
>> does not have to be constant.
>>
>
>Consider who is going to use the map, and for what purpose.
>
>The most critical use is for aeroplanes .. where the maximum height is 
>critical information!
>I think for that reason alone most maps should indicate the maximum 
>elevation of an object.
>
>___
>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] Elevation and height on vertical features

[Colin Smale]

Indeed.

On 7 January 2016 23:57:40 CET, Mike Thompson  wrote:
>On Thu, Jan 7, 2016 at 3:40 PM, Colin Smale 
>wrote:
>
>> Cliffs are never truly vertical. A bird's eye view from above will
>show
>> that. If they are steep enough they could be modelled as a line, but
>in
>> general we should allow for a polygon, with a high side and a low
>side.
>>
>Actually, sometimes they are "less than vertical", in other words,
>overhanging, e.g. [1]
>
>[1]
>https://s-media-cache-ak0.pinimg.com/736x/9c/52/0e/9c520e8e1e327be4bc844b950544aac6.jpg
>
>
>
>
>___
>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] highway = track vs. residential

[Dave Swarthout]

This is something we go round and round with in Thailand as well.
Highway=track is usually but not always a smaller, narrower way, either
paved or unpaved, that is used for agricultural or other purposes. It is
not a connector link between towns nor does it normally have residences
alongside of it. Still, you will see many cases where mappers have used
highway track to describe an unpaved road. The reason for this is probably
because they want to make such highways more obviously visible on a GPS
device.

I think you should feel free to change those cases you mentioned to
residential ways and use the appropriate surface, tracktype and access tags
as needed or desired. I agree with both you and Mateusz about driveway
tagging as well.

This
email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Jan 8, 2016 at 6:10 AM, Mateusz Konieczny 
wrote:

> On Thu, 7 Jan 2016 15:15:00 -0700
> Mike Thompson  wrote:
>
> > I am editing in Colorado, US in a rural part of the state. I do have
> > first hand knowledge of the area. It looks like someone has gone
> > through and changed many ways tagged "highway = residential" to
> > "highway = track."  For example:
> >
> > https://www.openstreetmap.org/way/6152252#map=16/40.7825/-105.1985
> >
> > Although these are gravel surfaced roads (not yet tagged that way, but
> > physically that is what they are), the ones in question provide
> > access to two or more homes and/or ranches.  To me these are not
> > "tracks" but "residential." Before I change these back, I wanted to
> > check with the community.
> >
> > Also, I would like your opinion on driveways (if they are mapped at
> > all). My understanding is that they (at least the part between the
> > public road and the house) should be tagged highway=service,
> > service=driveway, access=private and not highway=track.
> >
> > Mike
>
> Yes, highway is for tagging function, surface etc tags for quality.
>
> Unpaved driveway is highway=service, service=driveway not highway=track
> (proper surface tag and similar may be used to tag quality).
>
> And high-quality asphalt logging road is highway=track.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



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

Re: [Tagging] Elevation and height on vertical features

[Mike Thompson]

On Thu, Jan 7, 2016 at 6:30 PM, Warin <61sundow...@gmail.com> wrote:


>
> Grasping at straws .. the elevation of a mountain is given as its peak. If
> there is consistency within the map then the elevation of all objects
> should be their maximum height.
>
Sort of. By convention (in general mapping products) elevation is the
height of the ground (top of mountain top of cliff, the floor of a valley).
I have not heard anyone talk about the "elevation" of the top of a building
or the top of a tree, etc.

>
> Good point there! :-)
> For most it won't matter. What do international planes use as there
> reference for height? Use that - again consistency.
>
Having worked with aviation map data outside of OSM, they are concerned
with height of (typically man made) objects above the earth's surface (e.g.
a 50 meter high radio antenna).



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

Re: [Tagging] highway = track vs. residential

[John Willis]

Javbw
> On Jan 8, 2016, at 8:43 AM, Dave Swarthout  wrote:
> 
> hat is used for agricultural or other purposes

Question on that:

https://goo.gl/maps/Nvbmz1Z4bJp

We have a lot of public roads in Japan that, on import, were set to 
"unclassified". In rural areas - many are wrong. 

But as the roads are not residential, and not practical for through traffic, 
calling them a unclassified similarly seems wrong. They are public roads, and 
decently maintained, but very very narrow, and spiderweb between the more major 
residential and unclassified roads. I have tagged many of them as 
highway=service - as they are a rural equivalent to alleys (service=alley) - as 
they have major width limitations, parallel larger roads, and are covered with 
driveways (to greenhouses, etc) track intersections - they just happen to be 
agricultural tracks and tractor ramps, but are very similar to alleys leading 
to driveways and garages.

Eventually the fields are sold, houses built, road widened and the road turns 
into residential - and the agricultural tracks disappear under houses. A new 
residential street is born. 

I tag it this way because calling it a track or residential is misleading in my 
situation - one that doesn't exist whatsoever in California - so I am wondering 
if this situation (unbelievably spiderwebbed *rural* public roads where one is 
the "through" road and the other grid out, and then further grid out into 
farming tracks) is seemingly uncommon in other places. 

I have never seen a place with so many public, passable, routable roads in a 
rural area ever. It is like a city grid without the buildings. 

Having them render as residential or tracks is very misleading - same as 
rendering 2.5m public alley ways in Tokyo as "tracks". 

Being able to see the difference between the "easy road" the "rural alley" road 
and the "farming track" is paramount. There are tons of tracks along the river 
and up into logging cuts, I'm not talking about those - and I don't want these 
confused with them either. 

Google and Apple both have the issue, and I get routed down a road where it is 
easy to drive - but only 20km/h. Next to it is the road I should be on. This is 
because this distinction is not in their data - just "unclassified" and "2.5m 
width". It isn't residential nor track.  The duckiness of the road is lost. 


I would almost suggest service=rural or minor_rural to document this. 

Opinions? 

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

Re: [Tagging] Elevation and height on vertical features

[Christoph Hormann]

On Thursday 07 January 2016, Aaron Spaulding wrote:
> Hi all,
>
> I’ve been working on generating 3D meshes based on OSM data and I ran
> into a problem. Vertical features like 'natural=cliff',
> 'barrier=retaining_wall’ and 'waterway=waterfall' occupy two points
> in physical space, but because of the 2D nature of OSM its ambiguous
> which side of the feature that the ‘ele’ tag applies.

For cliffs mapping conventions say that you should put the line on top 
of the cliff in case it is not exactly vertical - accordingly the ele 
tag would also refer to the top  - but keep in mind that the elevation 
does not have to be constant.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Elevation and height on vertical features

[Martin Koppenhoefer]

sent from a phone

> Am 07.01.2016 um 17:14 schrieb Aaron Spaulding :
> 
> Either of these models can be used. I think option 1 makes the most sense, 
> but I’d like to know what the community consensus is.


I've always thought of ele representing the lower part, which is clear for man 
made features like buildings or obelisks (elevation of the ground, then add 
height for the highest point at that spot). Now when it comes to vertical 
elements like cliffs, where you have ground on both ends, it admittedly becomes 
ambiguous, but my suggestion would be to define to use the lower end also in 
these cases for simplicity/uniformity.


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

Re: [Tagging] Elevation and height on vertical features

[Warin]

On 8/01/2016 3:32 AM, Christoph Hormann wrote:

On Thursday 07 January 2016, Aaron Spaulding wrote:

Hi all,

I’ve been working on generating 3D meshes based on OSM data and I ran
into a problem. Vertical features like 'natural=cliff',
'barrier=retaining_wall’ and 'waterway=waterfall' occupy two points
in physical space, but because of the 2D nature of OSM its ambiguous
which side of the feature that the ‘ele’ tag applies.

For cliffs mapping conventions say that you should put the line on top
of the cliff in case it is not exactly vertical - accordingly the ele
tag would also refer to the top  - but keep in mind that the elevation
does not have to be constant.



Consider who is going to use the map, and for what purpose.

The most critical use is for aeroplanes .. where the maximum height is 
critical information!
I think for that reason alone most maps should indicate the maximum 
elevation of an object.


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

[Tagging] highway = track vs. residential

[Mike Thompson]

I am editing in Colorado, US in a rural part of the state. I do have first
hand knowledge of the area. It looks like someone has gone through and
changed many ways tagged "highway = residential" to "highway = track."  For
example:

https://www.openstreetmap.org/way/6152252#map=16/40.7825/-105.1985

Although these are gravel surfaced roads (not yet tagged that way, but
physically that is what they are), the ones in question provide access to
two or more homes and/or ranches.  To me these are not "tracks" but
"residential." Before I change these back, I wanted to check with the
community.

Also, I would like your opinion on driveways (if they are mapped at all).
My understanding is that they (at least the part between the public road
and the house) should be tagged highway=service, service=driveway,
access=private and not highway=track.

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

Re: [Tagging] highway = track vs. residential

[Tod Fitch]

My parents house is in a pretty rural part of Arizona and distinguishing 
between tracks and driveways or even residential roads can be difficult there. 
So my initial instinct was to say leave the ways in that part of Colorado as 
tracks as it can be hard to tell on the imagery.

But looking at the satellite imagery in the area you linked, they clearly look 
like unpaved residential roads and dirt driveways.

I’d leave the driveways in but change the tagging to:

highway=service
service=driveway
surface=unpaved
access=private

For the roads, clearly wider and serving multiple houses in the satellite 
imagery and with names showing in the 2015 Tiger imagery, I’d tag them as

highway=residential
surface=unpaved
name=(whatever the Tiger 2015 imagery says)

Adding the buildings the driveways lead to would be a nice touch but add to 
your work load.

Cheers,
Tod


> On Jan 7, 2016, at 2:15 PM, Mike Thompson  wrote:
> 
> I am editing in Colorado, US in a rural part of the state. I do have first 
> hand knowledge of the area. It looks like someone has gone through and 
> changed many ways tagged "highway = residential" to "highway = track."  For 
> example:
> 
> https://www.openstreetmap.org/way/6152252#map=16/40.7825/-105.1985 
> 
> 
> Although these are gravel surfaced roads (not yet tagged that way, but 
> physically that is what they are), the ones in question provide access to two 
> or more homes and/or ranches.  To me these are not "tracks" but 
> "residential." Before I change these back, I wanted to check with the 
> community.
> 
> Also, I would like your opinion on driveways (if they are mapped at all). My 
> understanding is that they (at least the part between the public road and the 
> house) should be tagged highway=service, service=driveway, access=private and 
> not highway=track. 
> 
> Mike 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation and height on vertical features

[Colin Smale]

Cliffs are never truly vertical. A bird's eye view from above will show that. 
If they are steep enough they could be modelled as a line, but in general we 
should allow for a polygon, with a high side and a low side.


On 7 January 2016 17:32:49 CET, Martin Koppenhoefer  
wrote:
>
>
>sent from a phone
>
>> Am 07.01.2016 um 17:14 schrieb Aaron Spaulding :
>> 
>> Either of these models can be used. I think option 1 makes the most
>sense, but I’d like to know what the community consensus is.
>
>
>I've always thought of ele representing the lower part, which is clear
>for man made features like buildings or obelisks (elevation of the
>ground, then add height for the highest point at that spot). Now when
>it comes to vertical elements like cliffs, where you have ground on
>both ends, it admittedly becomes ambiguous, but my suggestion would be
>to define to use the lower end also in these cases for
>simplicity/uniformity.
>
>
>cheers,
>Martin 
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging