Hi all,
a few days ago I noticed that the "wheelchair routing" page seems to be quite
out-aged.
This section
http://wiki.openstreetmap.org/wiki/Wheelchair_routing#Obstacles.2FAccessibility
states that a ramp for wheelchairs should be tagged highway=access_ramp
but this tag is rarely used and
On Thu, Jan 07, 2016 at 03:15:00PM -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
> exampl
>
> after a review by local mappers
>
> and that the wiki pages are changed accordingly.
>
> If I hear no complains I'll change the english and german page
>
> next sunday.
That's a pretty tight deadline. Wouldn't it be better to wait at least
1 or 2 weeks? Perhaps in the meantime, you could indic
Dear All,
I am sending this RFC in order to receive some feedback regarding my OSM
feature proposal for Street Parking Restrictions.
Best regards
Paul Simpson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/t
Marc Gemis wrote
>>
>> after a review by local mappers
>>
>> and that the wiki pages are changed accordingly.
>>
>> If I hear no complains I'll change the english and german page
>>
>> next sunday.
>
> That's a pretty tight deadline. Wouldn't it be better to wait at least
> 1 or 2 weeks? Perhaps i
Gerd Petermann wrote
>
> Marc Gemis wrote
>>>
>>> after a review by local mappers
>>>
>>> and that the wiki pages are changed accordingly.
>>>
>>> If I hear no complains I'll change the english and german page
>>>
>>> next sunday.
>>
>> That's a pretty tight deadline. Wouldn't it be better to wai
On Fri, Jan 8, 2016 at 9:45 AM, Gerd Petermann
wrote:
> I'd like to see that the existing highway=access_ramp
>
> are changed to the well known
>
> highway=footway
>
> wheelchair=yes
>
> in combination with
>
> incline=x%
I have a question about this. I think I can recognise an access ramp
for w
* Tod Fitch [160107 23:35]:
> 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 te
Marc Gemis wrote
> On Fri, Jan 8, 2016 at 9:45 AM, Gerd Petermann
> <
> GPetermann_muenchen@
> > wrote:
>> I'd like to see that the existing highway=access_ramp
>>
>> are changed to the well known
>>
>> highway=footway
>>
>> wheelchair=yes
>>
>> in combination with
>>
>> incline=x%
>
>
> I have
2016-01-08 10:50 GMT+01:00 Wolfgang Zenker :
> I would use highway=unclassified instead of residential as long as we
> are not inside a settlement; the implied rules like default speed limits
> tend to be different for inner-town roads and these rural roads and the
> tagging should distinguish bet
2016-01-08 10:31 GMT+01:00 Marc Gemis :
> I have a question about this. I think I can recognise an access ramp
> for wheelchair users when I see one. In general I don't know the
> incline %, but I assume that it was designed in such a way that the
> majority of wheelchair users can use it.
>
> wit
2016-01-08 10:00 GMT+01:00 Paul Simpson :
> I am sending this RFC in order to receive some feedback regarding my OSM
> feature proposal for Street Parking Restrictions.
you should provide a link...
Cheers,
Martin
___
Tagging mailing list
Tagging@open
dieterdreist wrote
> 2016-01-08 10:31 GMT+01:00 Marc Gemis <
> marc.gemis@
> >:
>
>> I have a question about this. I think I can recognise an access ramp
>> for wheelchair users when I see one. In general I don't know the
>> incline %, but I assume that it was designed in such a way that the
>>
2016-01-07 23:56 GMT+01:00 Colin Smale :
> Nobody will be using the raw data to fly a plane.
+1, and you wouldn't fly "blindly" (i.e. without sight) on a low-altitude
flight with OSM-maps anyway, the idea sounds ridiculous.
Cheers,
Martin
___
Tagging
Mike Thompson wrote:
> 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
2016-01-08 2:30 GMT+01:00 Warin <61sundow...@gmail.com>:
> 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.
>
don't confuse elevation and height. Elevation is typic
On Fri Jan 8 10:41:35 2016 GMT, Gerd Petermann wrote:
>
> Good points.
> We already have the tag ramp=* for ramps along highway=steps:
> http://wiki.openstreetmap.org/wiki/Key:ramp
> and it has a special
> ramp:wheelchair=yes
> but the typical steps are too steep for wheelchair ramps, so tho
So if all the elevations in OSM should be interpreted as WGS84, but many
(most?) of them are not, we have no way of knowing which are "right" and
which are "wrong". Even if the numerical value of ele=* is correct, we
have unreliable data.
Where do we go from here? Maybe we should encourage an exp
2016-01-08 11:41 GMT+01:00 Gerd Petermann :
> ramp:wheelchair=yes
>
good finding, why not use this together with highway=footway?
It's used more than 2300 times:
http://taginfo.osm.org/keys/ramp%3Awheelchair
but the typical steps are too steep for wheelchair ramps, so those are
> normally
> ad
Martin Koppenhoefer wrote on 2016/01/08 11:23:
2016-01-08 10:31 GMT+01:00 Marc Gemis:
[...]
with highway=access_ramp (duck tagging) I indicate that the path was
designed for wheelchair users.
Don't I loose some information with
highway=footway, wheelchair=yes, incline=up ?
Y
2016-01-08 12:11 GMT+01:00 Colin Smale :
> Where do we go from here? Maybe we should encourage an explicit reference
> to the datum used, such as ele:wgs84=* or ele:osgb=*?
>
this is what some people are already doing (not so few, but few compared to
the total number of ele-tags):
http://taginfo
2016-01-08 12:28 GMT+01:00 Tom Pfeifer :
> if trucks can use it, tag it service.
>
yes, but don't tag it wheelchair ramp then. ;-)
Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
2016-01-08 11:57 GMT+01:00 Richard Fairhurst :
> I wouldn't man the barricades against either
> =residential or =track, but the latter is best reserved for ungraded
> double-tracks and worse.
>
what's your stance on service?
Cheers,
Martin
___
Tagging
Martin Koppenhoefer wrote on 2016/01/08 11:41:
2016-01-08 10:00 GMT+01:00 Paul Simpson:
I am sending this RFC in order to receive some feedback regarding my OSM
feature proposal for Street Parking Restrictions.
you should provide a link...
https://wiki.openstreetmap.org/wiki/Proposed_fea
2016-01-08 12:47 GMT+01:00 Tom Pfeifer :
> My concern with this proposal is that inner-city roads get extremely
> fragmented
> when such tags are applied.
>
+1, around here there are disabled parking spots every few meters, plus
different parking rules (free, pay, residents, even different accor
I only looked at it briefly, but can it be combined with
http://wiki.openstreetmap.org/wiki/Key:parking:lane ?
m
On Fri, Jan 8, 2016 at 10:00 AM, Paul Simpson
wrote:
> Dear All,
>
> I am sending this RFC in order to receive some feedback regarding my OSM
> feature proposal for Street Parking Res
dieterdreist wrote:
> what's your stance on service?
Slightly difficult one, but I'd tend to concur with Florian that it's best
used for roads on private property (roughly "access-only"). When I use it I
always try and add an access and (if unpaved) surface tag - it's too
ambiguous otherwise.
che
On 8 January 2016 at 11:47, Tom Pfeifer wrote:
> an empty attempt on
> https://wiki.openstreetmap.org/wiki/Proposed_features/StreeT_Parking_Restrictions
> that a wiki admin might delete.
Deleted.
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
__
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
admittedl
On 08/01/2016 08:45, Gerd Petermann wrote:
I'd like to see that the existing highway=access_ramp
are changed to the well known
highway=footway
wheelchair=yes
in combination with
incline=x%
The explicit "wheelchair=yes" would definitely be needed with those tags
as they don't make it cl
2016-01-08 15:35 GMT+01:00 Andy Townsend :
> a steep footpath with corners that weren't negotiable by a wheelchair
> could still be tagged with an incline like that.
a steep way is never suitable for wheelchairs, at least not according to
construction standards (e.g. in Germany, 6% is the maxim
Colin Smale writes:
> So if all the elevations in OSM should be interpreted as WGS84, but many
> (most?) of them are not, we have no way of knowing which are "right" and
> which are "wrong". Even if the numerical value of ele=* is correct, we
> have unreliable data.
I have always had the impre
Florian Lohoff writes:
> public property - residential buildings
> highway=residential
> surface=gravel
>
> private property - residential buildings
> highway=service
> surface=gravel
> service=driveway
I more or less agree, from the US point of view, except that
h
On 2016-01-08 17:18, Greg Troxel wrote:
> So we just have to fix things that are wrong, and transform heights in
> other datums into WGS84 before entering them. This is exactly the same
> situation that we encounter for horizonal datums, except that people are
> even less aware of which vertical
Colin Smale writes:
> On 2016-01-08 17:18, Greg Troxel wrote:
>
>> So we just have to fix things that are wrong, and transform heights in
>> other datums into WGS84 before entering them. This is exactly the same
>> situation that we encounter for horizonal datums, except that people are
>> even
On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale wrote:
>
>
> How did all the elevation data get into OSM in the first place?
>
The elevations of peaks in the US came from the GNIS import. In turn the
GNIS elevations came from the National Elevation Dataset (NED) [1], and it
mostly uses the North Ame
Mike Thompson writes:
> On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale wrote:
>>
>> How did all the elevation data get into OSM in the first place?
>>
> The elevations of peaks in the US came from the GNIS import. In turn the
> GNIS elevations came from the National Elevation Dataset (NED) [1], a
On Fri, Jan 8, 2016 at 10:54 AM, Greg Troxel wrote:
>
> Mike Thompson writes:
>
> > On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale
> wrote:
> >>
> >> How did all the elevation data get into OSM in the first place?
> >>
> > The elevations of peaks in the US came from the GNIS import. In turn the
>
> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote:
>
> But I get it that the USGS surely publishes mountain heights
> somehow.
> I have asked, and so far I have not gotten an answer as to where I can find
> the data.
>
Is this the type of data you are looking for?
http://www.ngs.noaa.gov/c
Colin Smale wrote on 2016/01/08 17:47:
How did all the elevation data get into OSM in the first place?
> GPS is notoriously bad at determining elevation/altitude.
Beside intentionally tagged elevation such as peaks, I found a lot
of nodes in the data, that appear to come directly from
GPX track
Tod Fitch writes:
>> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote:
>>
>> But I get it that the USGS surely publishes mountain heights
>> somehow.
>> I have asked, and so far I have not gotten an answer as to where I can find
>> the data.
>>
> Is this the type of data you are looking for
That could be someone converting from feet to meters.
On Jan 8, 2016 10:32 AM, "Tom Pfeifer" wrote:
> Colin Smale wrote on 2016/01/08 17:47:
>
>> How did all the elevation data get into OSM in the first place?
>>
> > GPS is notoriously bad at determining elevation/altitude.
>
> Beside intentional
sent from a phone
> Am 08.01.2016 um 17:18 schrieb Greg Troxel :
>
> I don't think it makes sense to add datum tags and have heights in other
> datums. That just pushes the work onto the data consumer and adds
> confusion.
the advantage for the mapper is that it is quite easy, you simply rea
Martin Koppenhoefer writes:
> the advantage for the mapper is that it is quite easy, you simply read
> an elevation off a sign and add the reference height system to the
> value. (yes, you have to know what is this reference height system,
> that's why the "quite" is there). I'd also prefer to h
> On Jan 8, 2016, at 10:51 AM, Greg Troxel wrote:
>
>
> Tod Fitch writes:
>
>>> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote:
>>>
>>> But I get it that the USGS surely publishes mountain heights
>>> somehow.
>>> I have asked, and so far I have not gotten an answer as to where I can find
On Fri, Jan 8, 2016 at 12:15 PM, Martin Koppenhoefer wrote:
>
>
> FWIW, for most usages of these ele values it doesn't really matter if a
> value is 20 meters more or less, they are used to get a rough idea, not to
> be used in calculations where a meter more or less is important, i.e. this
> dis
Greg Troxel wrote:
> I more or less agree, from the US point of view, except that
> highway=residential has a meaning of something that is
> legally a road.
highway=residential in the US _largely_ has the meaning "this was imported
from TIGER feature code A41 and hasn't been changed". One import
Mike Thompson writes:
> [1] do care about the "official" elevation of mountains. I think OSM
> should - in these cases - match official government surveys where
> available.
Fully agreed that it should be right.
> The particular datum is not important, as long as it is known,
> as someone mak
Hi all,
The vote vote session for the location transition proposal is now open.
http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions
As described, location:transition=yes may enable mappers to indicate
the location of a feature is changing without using fixme or
approximative
On Fri, Jan 8, 2016 at 3:09 PM, François Lacombe
wrote:
> The vote vote session for the location transition proposal is now open.
> http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions
>
> As described, location:transition=yes may enable mappers to indicate
> the location of
Le 9 janv. 2016 12:40 AM, "Clifford Snow" a
écrit :
>
>
> On Fri, Jan 8, 2016 at 3:09 PM, François Lacombe <
fl.infosrese...@gmail.com> wrote:
>>
>> The vote vote session for the location transition proposal is now open.
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions
51 matches
Mail list logo
