Re: [Tagging] fixme -- by a specific date

[Bill Ricker]

On Mon, Nov 28, 2016 at 1:14 PM, Martijn van Exel  wrote:

> What I am after is a higher fidelity solution that also goes beyond
> 'seasonality'. What do you think?


​your proposal for a alarm-time on a fixme - for which a small bit of
programming could cause a Note to appear when due, and maybe drop an email
to the author of the fixme too ? - seems appropriate if the closure is
sufficiently indefinite ​that it needs to be ground-checked (or at least
press-release checked) that it has reopened on schedule (rather than being
late as construction often is). I can see that this is usually going to be
preferable to a change self-reverting on schedule !

​And i see access :
conditional =*
includes sunrise-sunset or vice versa . ( I wonder if the nearby parkways
are so tagged. Hmm. No.  note #799410 added. Since i only use that parkway
as a rushhour bypass in the summer, I'm not certain so won't armchair it
wrong! )​

Is there a gap betwixt fixme-with-alarm, seasonal=*, and access
:conditional
=* ​for which we
​_would_ want temporary closure to revert without a fresh survey and data
upload and without a fresh download to the renderer/router ?
​If so, we need to define the difference betwixt them.​
If not, your proposal just needs syntax (and proposals for tools to suport).


-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Key:visibility

[markus schnalke]

[2016-11-28 20:50] Paul Desgranges 
>
> Visibility and readability are not the same, [...]

They also suggest different meanings, at least to me. When I
first read you message about visibility of public clocks, I
thought it would indicate from which directions or places it
would be visible, not the distance from where it is readable.


> -visibility=house : visible from the distance of one house (or
>  building), the device is targeted mostly for pedestrians, or bikers
> -visibility=street : visible from the  distance of one street, the
>  device is targeted up to passers-by into vehicles going slowly
> -visibility=area : visible from all the area, the device is targeted
>  up to passers-by into vehicles going fast
> 
> If somebody wants to make a better wordings, I would be glad

This is just like the smoothness=* case. Instead of having values
like ``excellent'', ``bad'' or ``horrible'', we now learned that
it is better to tag for what cases some smoothness is okay. The
same here: You'll always need the explanations above if you use
the values ``house'', ``street'' and ``area'', but you can get
rid of them if you just use the explanations themselves:

- visibility=for_walkers
- visibility=for_slow_cars
- visibility=for_fast_cars

(I see bikers in the same case as slow cars if they are in
motion. Thus we should better not use the too flexible biker
term.)


I have to come back to my initial statement: The term
``readability'' would be the better one for this meaning,
as ``visible for fast cars'' is really something else as
``readable for fast cars''.

I'm no native English speaker, but I think it has to be
``visible from'' and ``readable for''. Thus, consequently,
the visibility should be specified with a distance and not
with the kind of moving vehicle, which brings us back to
the naming problem. ... These are indicators that there is
something clumsy about the current system. Before we extend
it, we should better double-check its sanity.


meillo

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

Re: [Tagging] fixme -- by a specific date

[John Willis]

Javbw
> On 29 Nov 2016, at 4:29 AM, Tod Fitch  wrote:
> 
> A number of state highway routes through the Sierra Nevada are closed in 
> winter. The rub is, the real closure is from first significant snowfall until 
> it either melts or they bring in the rotary plows in spring.  This varies 
> wildly from year to year

Same here in Japan. There *so many* mountain pass roads that close in winter  - 
the areas are not used for skiing so they close in winter or they have been 
bypassed by tunneled roads. 

Most of the main mountain roads have "road stations" (service areas on 
non-motorway roads) with big wooden topographical maps with little wood signs 
saying "open" or "closed" - which varies from road to road in the region. 

The old snowman ascii character (now a rendered emoji ☃ ) was put on the roads 
in navigational maps to warn that the road would be closed in winter. 

http://www.openstreetmap.org/#map=12/36.1872/137.6005

The 158 (the windey bypassed section) and 24 (into Kamikochi) closes in the 
winter. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Key:visibility

[Paul Desgranges]

I just wanted to extend the meaning of 'visibility' so that it does not 
match only the 'clocks' but more things and for example 'advertising' 
devices.


As a matter of fact, I find as well that "house"/"street"/"area" are not 
very well understandable values for "visibility", but its was the 
existing values, and I did n't want to change them, maybe just precise 
their scope.


I think we should remove the distance in meters, because 5m, 20m, or any 
other distances won't fit to all needs. It is more to get the average 
scope, rather than an exact distance.


Visibility and readability are not the same, things are first visible, 
then when you get closer same things become readable. But as tag is 
called 'visibility' we should only speak about visibility and forget 
about readability here.


Then I make another proposal

*visibility=** is used for publicly visible devices or features to 
evaluate the scope of their visibility


-visibility=house : visible from the distance of one house (or 
building), the device is targeted mostly for pedestrians, or bikers
-visibility=street : visible from the  distance of one street, the 
device is targeted up to passers-by into vehicles going slowly
-visibility=area : visible from all the area, the device is targeted up 
to passers-by into vehicles going fast


If somebody wants to make a better wordings, I would be glad

Thank you


On 28/11/2016 14:37, Martin Koppenhoefer wrote:



sent from a phone

Il giorno 28 nov 2016, alle ore 12:40, Colin Smale 
> ha scritto:


Do you mean visibility, or would legibility be better here? Maybe I 
can see a clock from 100m away, but it is not actually useful until 
it becomes legible at 20m.


You use the word "readable" (=legible) yourself.




+1 for text, less pertinent for things like an inflatable sculpture or 
similar, also the values seem off from what I'd expect by reading 
their names.
"house" doesn't seem to be a good name in general, as it refers to a 
residential building, the least place where I'd expect advertisements 
to be mapped. I'd call it "indoor" or "building" and would expect it 
to mean something like 20m. 5 m is really nothing. Similarly, 20m is 
very few for the "street" scope, I'd expect this to be something like 
50-150m, while area could be up to one or a few kilometers (if placed 
on a high building, and e.g. illuminated or light emitting at night ).



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

Re: [Tagging] fixme -- by a specific date

[Tod Fitch]

> On Nov 28, 2016, at 10:14 AM, Martijn van Exel  wrote:
> 
> Bill, 
> 
> The seasonal tag[1] already exists for very general 'seasonal availability' 
> of features.  This works for a very rough approximation of actual 
> availability which may be enough for some use cases. This could (should?) be 
> used as a fallback. What I am after is a higher fidelity solution that also 
> goes beyond 'seasonality'. What do you think?
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:seasonal 
> 
> 
> Martijn van Exel
> http://mvexel.github.io/ 
> On Mon, Nov 28, 2016 at 11:01 AM, Bill Ricker  > wrote:
> 
> 
> On Mon, Nov 28, 2016 at 12:52 PM, Martijn van Exel  > wrote:
> Hi, 
> 
> When mapping seasonal closures here in Utah[1] I realized I am still missing 
> a solid way to mark a road as closed for the season and then have some level 
> of confidence that someone will look at it in the spring and 'reopen' it. 
> More generally for someone to map a feature and somehow tag it as needing 
> another look by a certain date. 
>  
> ​Seems to me that seasonal roads should have some sort of seasonal 
> availability tag, similar to how a park gate might have dawn-to-dusk 
> availability, so that a router (possibly using a Lambertus Garmin map) to get 
> the right answer even if the download was not since the latest state change. 
> (Yes, there are some parkways through parks that are usable through routes in 
> daylight.)

A number of state highway routes through the Sierra Nevada are closed in 
winter. The rub is, the real closure is from first significant snowfall until 
it either melts or they bring in the rotary plows in spring.  This varies 
wildly from year to year. And with the current drought, there have been times 
when normally closed highways have remained open nearly all winter. The best 
source of status on this is the CalTrans website.

More local to where I currently am, there are county highways that are low on 
the plowing priority list and can be closed for significant amount of time 
until resources are available to clear the road. In the case I am thinking of, 
the county maintains a status page listing all closures and the reason for the 
closure.

Seems like there ought to be a way to tag the road with a link to the 
authoritative source for the status.

It would be nice if there were a standard set of APIs that those different 
authoritative sources had in common: Then it might be possible to add tagging 
that would allow a router to check the status. But at the moment all I am aware 
of is stuff designed to be read by a human not parsed by a machine.



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

Re: [Tagging] fixme -- by a specific date

[Michał Brzozowski]

remonty.openstreetmap.pl/remonty does exactly that for Poland. It's used
mainly by paid mappers from Yanosik who get info from their app. IIRC it
issues a note whenever an opening is due.

Michał

28.11.2016 18:54 "Martijn van Exel"  napisał(a):

> Hi,
>
> When mapping seasonal closures here in Utah[1] I realized I am still
> missing a solid way to mark a road as closed for the season and then have
> some level of confidence that someone will look at it in the spring and
> 'reopen' it. More generally for someone to map a feature and somehow tag it
> as needing another look by a certain date.
>
> I added a discussion section to the wiki[2] for the fixme tag where I
> propose adding the fixme:by qualifier to indicate the (approximate) date by
> which a mapper should look at the feature again.
>
> There should be more use cases for this. I can think of proposed or
> under-construction features for which you may know a projected start /
> finish date. Or semi-permanent features that you know will disappear at
> some point. I know HOT has interest in this kind of 'lifecycle' tagging as
> well.
>
> Martijn van Exel
> http://mvexel.github.io/
>
> [1] A lot of fairly major roads close here for the winter, typically
> between November and May: http://udottraffic.utah.gov/
> CLALertViewer.aspx?CLType=3
> [2] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:fixme#
> Revisit_by_a_certain_date
>
> ___
> 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] fixme -- by a specific date

[Martijn van Exel]

Bill,

The seasonal tag[1] already exists for very general 'seasonal availability'
of features.  This works for a very rough approximation of actual
availability which may be enough for some use cases. This could (should?)
be used as a fallback. What I am after is a higher fidelity solution that
also goes beyond 'seasonality'. What do you think?

[1] https://wiki.openstreetmap.org/wiki/Key:seasonal

Martijn van Exel
http://mvexel.github.io/

On Mon, Nov 28, 2016 at 11:01 AM, Bill Ricker  wrote:

>
>
> On Mon, Nov 28, 2016 at 12:52 PM, Martijn van Exel  wrote:
>
>> Hi,
>>
>> When mapping seasonal closures here in Utah[1] I realized I am still
>> missing a solid way to mark a road as closed for the season and then have
>> some level of confidence that someone will look at it in the spring and
>> 'reopen' it. More generally for someone to map a feature and somehow tag it
>> as needing another look by a certain date.
>>
>
> ​Seems to me that seasonal roads should have some sort of seasonal
> availability tag, similar to how a park gate might have dawn-to-dusk
> availability, so that a router (possibly using a Lambertus Garmin map) to
> get the right answer even if the download was not since the latest state
> change. (Yes, there are some parkways through parks that are usable through
> routes in daylight.)
>
>
>
> --
> Bill Ricker
> bill.n1...@gmail.com
> https://www.linkedin.com/in/n1vux
>
> ___
> 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] fixme -- by a specific date

[Martijn van Exel]

See https://www.openstreetmap.org/changeset/44013342 for a tagging example.

Martijn van Exel
http://mvexel.github.io/

On Mon, Nov 28, 2016 at 10:52 AM, Martijn van Exel  wrote:

> Hi,
>
> When mapping seasonal closures here in Utah[1] I realized I am still
> missing a solid way to mark a road as closed for the season and then have
> some level of confidence that someone will look at it in the spring and
> 'reopen' it. More generally for someone to map a feature and somehow tag it
> as needing another look by a certain date.
>
> I added a discussion section to the wiki[2] for the fixme tag where I
> propose adding the fixme:by qualifier to indicate the (approximate) date by
> which a mapper should look at the feature again.
>
> There should be more use cases for this. I can think of proposed or
> under-construction features for which you may know a projected start /
> finish date. Or semi-permanent features that you know will disappear at
> some point. I know HOT has interest in this kind of 'lifecycle' tagging as
> well.
>
> Martijn van Exel
> http://mvexel.github.io/
>
> [1] A lot of fairly major roads close here for the winter, typically
> between November and May: http://udottraffic.utah.gov/
> CLALertViewer.aspx?CLType=3
> [2] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:fixme#
> Revisit_by_a_certain_date
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] fixme -- by a specific date

[Bill Ricker]

On Mon, Nov 28, 2016 at 12:52 PM, Martijn van Exel  wrote:

> Hi,
>
> When mapping seasonal closures here in Utah[1] I realized I am still
> missing a solid way to mark a road as closed for the season and then have
> some level of confidence that someone will look at it in the spring and
> 'reopen' it. More generally for someone to map a feature and somehow tag it
> as needing another look by a certain date.
>

​Seems to me that seasonal roads should have some sort of seasonal
availability tag, similar to how a park gate might have dawn-to-dusk
availability, so that a router (possibly using a Lambertus Garmin map) to
get the right answer even if the download was not since the latest state
change. (Yes, there are some parkways through parks that are usable through
routes in daylight.)



-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] fixme -- by a specific date

[Martijn van Exel]

Hi,

When mapping seasonal closures here in Utah[1] I realized I am still
missing a solid way to mark a road as closed for the season and then have
some level of confidence that someone will look at it in the spring and
'reopen' it. More generally for someone to map a feature and somehow tag it
as needing another look by a certain date.

I added a discussion section to the wiki[2] for the fixme tag where I
propose adding the fixme:by qualifier to indicate the (approximate) date by
which a mapper should look at the feature again.

There should be more use cases for this. I can think of proposed or
under-construction features for which you may know a projected start /
finish date. Or semi-permanent features that you know will disappear at
some point. I know HOT has interest in this kind of 'lifecycle' tagging as
well.

Martijn van Exel
http://mvexel.github.io/

[1] A lot of fairly major roads close here for the winter, typically
between November and May:
http://udottraffic.utah.gov/CLALertViewer.aspx?CLType=3
[2]
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Key:fixme#Revisit_by_a_certain_date
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=primary/secondary/tertiary - tag according to quality or usage?

[Martin Koppenhoefer]

2016-11-28 13:39 GMT+01:00 Michael Tsang :

> There are some highways which the quality isn't up to the usage, resulting
> in
> congestion. Those highways connects high-quality motorway/trunk/primary
> highways together for long distance traffic, but they only have a single
> lane
> per direction, with lots of traffic lights, junctions, driveways, etc.,
> resulting in slow traffic. Because the absence of roads of proper quality,
> those
> low quality roads become bottlenecks in the whole network.
>


it's more a problem of the highway network in that area than of the OSM
tagging though. Regularly congested roads with lots of traffic actually
indicate a high importance of that road, IMHO (while situations where this
is due to some event in the area are exceptions, e.g. roads around a
stadion where you only have congestion in case of a match or other event,
or after an accident, construction work, etc.).



>
> A while ago, I tagged them all with highway=tertiary, consistent with the
> quality of highways around the region, disregarding the actual kinds of
> traffic
> on the highway, and someone retagged them as highway=primary reflecting the
> actual usage for long-distance inter-town traffic,
>
>

road "quality" has several parameters and can already be tagged (lanes,
surface, maxspeed as an indirect indicator), highway is about the road grid
hierarchy. What you'd need for very good routing results (and ETA
calculations) is the actual current traffic speed on the individual
segments, something we can't tag in OSM anyway.

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

Re: [Tagging] Feature Proposal - RFC - flight route

[Aun Johnsen]

> On Nov 28, 2016, at 11:36, tagging-requ...@openstreetmap.org wrote:
> 
> Hi all,
> 
> As said, no need to draw paths as way in OSM : they can be drawed by any
> customized render engine when start and stop point are known.
> +1 to make relation with airports as only members.
> 
> 
> 2016-11-28 13:24 GMT+01:00 Aun Johnsen :
> 
>> A duration tag would be needed to calculate travel time. This way, a
>> transport routing could take air travel into account, without introducing
>> unverifiable data and flightpaths into the database.
>> 
> 
> I respectably disagree : how would a routing engine do to route pedestrian
> on roads where only motor vehicle speed/travel time is known ?
> Speed and so time depend on the aircraft you use to go down a specific
> geographic path.
> 
> This data should not be added to OSM.
> It is a routing engine parameter actually.
> 
> All the best
> 
> François
Any single route is defined in tables with an expected travel time (which does 
not always include taxi time on the grund), so for instance, it would be 
expected that a flight between two airports have a determined time consume. 
Further, you need to do checkin at a certain time before scheduled departure, 
and retrieval of luggage have an expected time, as well as a minimum time for 
connections. This way, the router will only need to know end-points of the 
route, but it need to be able to link up against departure times. Since each 
airline most likely have multiple services (with different ID number) between 
the same two airports, the data is more likely to be a table, best stored in a 
separate database, but with end-points linked to OSM-objects. The air-route 
relation is far from an ideal solution, only a work-around for not needing the 
routing engine to check multiple databases.

A pedestrian routing engine would use average walking speed as a base for 
travel speed instead of signed motor vehicle speed, and if intelligent enough 
allow to combine with public transportation.

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

Re: [Tagging] Key:visibility

[Martin Koppenhoefer]

sent from a phone

> Il giorno 28 nov 2016, alle ore 12:40, Colin Smale  ha 
> scritto:
> 
> Do you mean visibility, or would legibility be better here? Maybe I can see a 
> clock from 100m away, but it is not actually useful until it becomes legible 
> at 20m.
> 
> You use the word "readable" (=legible) yourself.
> 


+1 for text, less pertinent for things like an inflatable sculpture or similar, 
also the values seem off from what I'd expect by reading their names.
"house" doesn't seem to be a good name in general, as it refers to a 
residential building, the least place where I'd expect advertisements to be 
mapped. I'd call it "indoor" or "building" and would expect it to mean 
something like 20m. 5 m is really nothing. Similarly, 20m is very few for the 
"street" scope, I'd expect this to be something like 50-150m, while area could 
be up to one or a few kilometers (if placed on a high building, and e.g. 
illuminated or light emitting at night ).


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

Re: [Tagging] highway=primary/secondary/tertiary - tag according to quality or usage?

[Greg Troxel]

Michael Tsang  writes:

> There are some highways which the quality isn't up to the usage, resulting in 
> congestion. Those highways connects high-quality motorway/trunk/primary 
> highways together for long distance traffic, but they only have a single lane 
> per direction, with lots of traffic lights, junctions, driveways, etc., 
> resulting in slow traffic. Because the absence of roads of proper quality, 
> those 
> low quality roads become bottlenecks in the whole network.
>
> A while ago, I tagged them all with highway=tertiary, consistent with the 
> quality of highways around the region, disregarding the actual kinds of 
> traffic 
> on the highway, and someone retagged them as highway=primary reflecting the 
> actual usage for long-distance inter-town traffic, and send a message to me 
> about that.

First, primary/secondary/tertiary is a UK notion.  In the US, we have
more or less used that for US highway, state highway, and other
important road between towns.

Overall, I think if people really care about which tag is used, then
other than arguing about formal road networks, that's a clue that
routing or rendering is being done based on just the type, rather than
the other attributes.

If it is one lane in each direction, then tag the lanes value.  If there
are stop signs ro lights, tag them.   Then, a router can make routes
that correspond to the physical experience of driving.

Also, one lane in each direction is pretty normal for long-distance
roads that really are primary, at least around me (US, outside of
cities, not Interstates).Most highway=secondary are only one lane
each way.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=primary/secondary/tertiary - tag according to quality or usage?

[Philip Barnes]

On Mon Nov 28 12:39:44 2016 GMT, Michael Tsang wrote:
> Dear all,
> 
> There are some highways which the quality isn't up to the usage, resulting in 
> congestion. Those highways connects high-quality motorway/trunk/primary 
> highways together for long distance traffic, but they only have a single lane 
> per direction, with lots of traffic lights, junctions, driveways, etc., 
> resulting in slow traffic. Because the absence of roads of proper quality, 
> those 
> low quality roads become bottlenecks in the whole network.
> 
> A while ago, I tagged them all with highway=tertiary, consistent with the 
> quality of highways around the region, disregarding the actual kinds of 
> traffic 
> on the highway, and someone retagged them as highway=primary reflecting the 
> actual usage for long-distance inter-town traffic, and send a message to me 
> about that.
> 
> What's the correct tag then?
> 
It depends on the country, road classifications should be documented in the 
wiki for that country.

Phil (trigpoint)
 ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - flight route

[François Lacombe]

2016-11-28 13:39 GMT+01:00 Michael Tsang :

> Sorry, aren't aeroplane routes, like bus routes, use fixed stop positions
> and
> platforms every departure?
>
>
IMHO certainly not.
Already took the same flight (same number) at two different gates
nevertheless in the same terminal at two different dates.

Using airports and terminal is enough, gates can change often (numbers,
position, shape...)

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

[Tagging] highway=primary/secondary/tertiary - tag according to quality or usage?

[Michael Tsang]

Dear all,

There are some highways which the quality isn't up to the usage, resulting in 
congestion. Those highways connects high-quality motorway/trunk/primary 
highways together for long distance traffic, but they only have a single lane 
per direction, with lots of traffic lights, junctions, driveways, etc., 
resulting in slow traffic. Because the absence of roads of proper quality, 
those 
low quality roads become bottlenecks in the whole network.

A while ago, I tagged them all with highway=tertiary, consistent with the 
quality of highways around the region, disregarding the actual kinds of traffic 
on the highway, and someone retagged them as highway=primary reflecting the 
actual usage for long-distance inter-town traffic, and send a message to me 
about that.

What's the correct tag then?

Michael
-- 
Sent from KMail

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

Re: [Tagging] Feature Proposal - RFC - flight route

[Michael Tsang]

On Monday 28 November 2016 12:47:41 Tom Pfeifer wrote:
> 
> Platforms, a.k.a. Gates, can already be mapped. Which flight they serve
> changes every day, this is neither mappable nor verifyable nor maintainable.

Sorry, aren't aeroplane routes, like bus routes, use fixed stop positions and 
platforms every departure?

Besides aeroplane routes, there are also helicopter routes where they 
definitely use fixed stop positions and platforms.

Michael
-- 
Sent from KMail

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

Re: [Tagging] Feature Proposal - RFC - flight route

[François Lacombe]

Hi all,

As said, no need to draw paths as way in OSM : they can be drawed by any
customized render engine when start and stop point are known.
+1 to make relation with airports as only members.


2016-11-28 13:24 GMT+01:00 Aun Johnsen :

> A duration tag would be needed to calculate travel time. This way, a
> transport routing could take air travel into account, without introducing
> unverifiable data and flightpaths into the database.
>

I respectably disagree : how would a routing engine do to route pedestrian
on roads where only motor vehicle speed/travel time is known ?
Speed and so time depend on the aircraft you use to go down a specific
geographic path.

This data should not be added to OSM.
It is a routing engine parameter actually.

All the best

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

Re: [Tagging] Feature Proposal - RFC - flight route

[Aun Johnsen]

> On Nov 28, 2016, at 10:00, tagging-requ...@openstreetmap.org wrote:
> 
> On 28.11.2016 11:27, Michael Tsang wrote:
>> The consensus is that the flight path should not be mapped, but we are
>> interested the airport (Stop positions and platforms) where the flight
>> serves.
> 
> Platforms, a.k.a. Gates, can already be mapped. Which flight they serve 
> changes every day, this is neither mappable nor verifyable nor maintainable.
> 
> tom
> 
Best option is to map routes as Terminal endpoints (in almost all cases, 
terminal remains the same over long periods, and are verifiable), with no 
itinerary members. A duration tag would be needed to calculate travel time. 
This way, a transport routing could take air travel into account, without 
introducing unverifiable data and flightpaths into the database. PS, flight 
paths are not as fixed as bus lanes, and the actual route of the plane varies 
with weather forecasts, traffic density, traffic priority, type of aircraft in 
service, and much more.

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

Re: [Tagging] Feature Proposal - RFC - flight route

[Tom Pfeifer]

On 28.11.2016 11:27, Michael Tsang wrote:

The consensus is that the flight path should not be mapped, but we are
interested the airport (Stop positions and platforms) where the flight
serves.


Platforms, a.k.a. Gates, can already be mapped. Which flight they serve 
changes every day, this is neither mappable nor verifyable nor maintainable.


tom


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

Re: [Tagging] Key:visibility

[Colin Smale]

Do you mean visibility, or would legibility be better here? Maybe I can
see a clock from 100m away, but it is not actually useful until it
becomes legible at 20m. 

You use the word "readable" (=legible) yourself. 

//colin

On 2016-11-28 12:30, Paul Desgranges wrote:

> Hello,  
> 
> Can we extend the Key:visibility [1] so that it covers not only the clock, 
> bit as well any device or feature which are readable on a public street ? For 
> example, it could apply as well to 'advertising' objects (but it likely could 
> apply to more cases). And in that case we could rather write something like : 
> 
> VISIBILITY=* is used in connection with publicly visible devices or features 
> to display their visibility/readability. -visibility=house Entity (or device 
> or feature) is readable from up to 5m (targeted mostly for pedestrians, or 
> bikers)
> -visibility=street Entity (or device or feature) is readable from up to 20m 
> (targeted for passers-by in for vehicles going slowly)
> -visibility=area Entity (or device or feature) is readable from more than 20m 
> (targeted for passers-by in vehicles going fast) 
> 
> Thanks 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:visibility___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Key:visibility

[Paul Desgranges]

Hello,

Can we extend the Key:visibility 
 so that it covers 
not only the clock, bit as well any device or feature which are readable 
on a public street ? For example, it could apply as well to 
'advertising' objects (but it likely could apply to more cases). And in 
that case we could rather write something like :



*visibility=** is used in connection with publicly visible devices or 
features to display their visibility/readability.


-visibility=house Entity (or device or feature) is readable from up to 
5m (targeted mostly for pedestrians, or bikers)
-visibility=street Entity (or device or feature) is readable from up to 
20m (targeted for passers-by in for vehicles going slowly)
-visibility=area Entity (or device or feature) is readable from more 
than 20m (targeted for passers-by in vehicles going fast)



Thanks

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

Re: [Tagging] Feature Proposal - RFC - flight route

[Michael Tsang]

The consensus is that the flight path should not be mapped, but we are 
interested the airport (Stop positions and platforms) where the flight serves.

Michael

Get Outlook for Android

From: Volker Schmidt
Sent: Sunday, 27 November, 17:23
Subject: Re: [Tagging] Feature Proposal - RFC - flight route
To: Tag discussion, strategy and related tools

This is a complex issue.

Lets start from the end user's point of view:

Flight number XXxxx is sold by airline XX and goes from airport ABC to airport 
XYZ, possibly with scheduled intermediate stops at airport DEF (and possibly 
more).

That flight is operated by the same airline or by another airline YY as flight 
number YYyyy.

The actual flight route is not fixed, but is defined before departure by the 
flight's captain.

The flight route has to follow established flight corridors or tracks, which in 
turn are not fixed (for example the North Atlantic Tracks [1]).

So what can we map as geographic data in OSM? The airports and that's it. The 
"The way making up the route" is not mappable, because it is variable from 
instance to instance of the flight.

The only way out I can see, is to accept as "the way making up the route" 
fictitious tracks connecting the airports on the shortest route.

(I know that we map already shipping routes, which have, in principle, similar 
problems.)

[1] https://en.wikipedia.org/wiki/North_Atlantic_Tracks)

On 26 November 2016 at 22:57, François Lacombe 
> wrote:

Hi Michael,

Read your proposal and have some comments/questions

Regarding travel duration, I think this information is irrelevant in the route 
relation, which is only a route.

The duration depends on what's walking the route (Paris/NYC with A380 = approx 
7h and Paris/NYC with Concorde used to be lasting 3h)

From/to should be derived from relation members (role=start/stop). But it may 
be desirable to have these data for display or labelling.

What if several operators use the route ? Will we have to create as many routes 
as operators ?

I use to believe flight routes aren't fixed paths but a bunch of paths which 
may vary depending on weather, air pressure, etc...

Is this really mapable in OSM ?

You may give a few details more in the Route tracking chapter

All the best

François

François Lacombe

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux

2016-11-22 15:41 GMT+01:00 Michael Tsang 
@gmail.com>:

Dear all,

I have proposed an extension to the public transport schema to include flights.

https://wiki.openstreetmap.org/wiki/Proposed_features/flight_route

Basically the flight route is mapped just like ferry routes in my proposal.

Michael
--
Sent from KMail

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


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


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