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

[Volker Schmidt]

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 :
>
>> 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

Re: [Tagging] name:zh-yue

[jc86035]

Should a separate bug be filed to fix iD before your fix to use CLDR is
implemented, and would it be a good idea to go through all of the
objects using name:zh-yue=* (via overpass turbo) and replace the tag
with name:yue=*?

jc86035

Bryan Housel:
> Worth mentioning here that iD might be doing the wrong thing:
> https://github.com/openstreetmap/iD/issues/2457 
> 
> 
> We are using wikimedia as our source for languages, which is where the 
> "zh-yue" came from.
> As mentioned in the ticket, I’m planning to switch this to a more proper 
> language list.
> CLDR has: 
> https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json 
> 
> 
> So `name:zh` and `name:yue` are probably both valid language codes, and 
> `name:zh-yue` probably is not.
> 
> Thanks,
> Bryan
> 
> 
> 
> 
>> On Nov 24, 2016, at 8:53 AM, jc86035  wrote:
>>
>> Mostly in Hong Kong, some places with Cantonese names use name:yue=*,
>> whereas others use name:zh-yue=* (which is supported by iD). Should
>> those objects using the former be changed to use the latter? (In
>> addition, should those objects with name:zh-yue=* same as name:zh=* have
>> name:zh-yue=* deleted?)
>>
>> jc86035
>>
>> ___
>> 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

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

[Philip Barnes]

On Sun, 2016-11-27 at 10:21 +0100, Volker Schmidt wrote:
> 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.)
> 
> 
> 
> 
Although shipping and ferry routes are mapped across open water and do not 
interfere with other mapping.

Imagine we added globe spanning ways linking airports, think of the problems 
that this will cause other mappers with no interest in air travel. 

The areas around major airports, such as Heathrow, will be covered in these 
ways. Imagine how much hassle this is going to cause a mapper who wants to 
trace houses, footpaths?

This is a really bad idea. 

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

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

[yo paseopor]

For me it is not a bad idea. OpenStreetmap has to start to think in a
"global map" as is a geographic database, so flights or ferries has to be
inside in.
But what about people who did not interest it? And what about tagging
fire_hydrants? who cares about? or "love hotels"? who cares about? All
cares to all people. We cannot start to say this no because this is not
important. OpenStreetMap should start to think in "levels". For example
what about mapping underground transports or indoors? These kinds of map
are mixed with normal level street and it is a mess to edit, to watch it,
to use it. One way to fix all this could be mapping at different levels. I
think OSM user...and iD user, and JOSM user, and Potlach user need the
possibility to filter which level wants to download, edit and view:
underground? level street? indoor? sky? present? past? We have to start to
think this.

This would be a good possibility givin' answer to the future (or present)
complexity of OpenStreetMap as a main geographic database.
Salut i futur (health and future)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Frederik Ramm]

Hi,

On 11/27/2016 02:28 PM, yo paseopor wrote:
> For me it is not a bad idea. OpenStreetmap has to start to think in a
> "global map" as is a geographic database, so flights or ferries has to
> be inside in.

No. Contrary to what many people believe (and contrary to what the term
"airway" might suggest), flight routes are not fixed and it makes no
sense to map the course of one individual aircraft at one given day in
OSM. See also http://wiki.openstreetmap.org/wiki/Aviation

(Approach and departure patterns at large airports may be semi-fixed but
subject to change at any time.)

For public transport information, the fact that there is a flight
connection between A and B might be interesting but that is just some
company's proprietary schedule and not geodata that should be in OSM.

OSM is not a database of everything someone might find interesting.
Store flight information in a separate system and plot it on OSM if you
like.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] name:zh-yue

[Bryan Housel]

> On Nov 27, 2016, at 5:28 AM, jc86035  wrote:
> 
> Should a separate bug be filed to fix iD before your fix to use CLDR is
> implemented,

No need to file a separate bug..



> and would it be a good idea to go through all of the
> objects using name:zh-yue=* (via overpass turbo) and replace the tag
> with name:yue=*?

Sounds like a good idea to me (and I wish there were more enthusiasm within OSM 
for cleaning up tags), but please check with the local community before doing a 
mass tag change like that.

Thanks, Bryan





> jc86035
> 
> Bryan Housel:
>> Worth mentioning here that iD might be doing the wrong thing:
>> https://github.com/openstreetmap/iD/issues/2457 
>>  
>> > >
>> 
>> We are using wikimedia as our source for languages, which is where the 
>> "zh-yue" came from.
>> As mentioned in the ticket, I’m planning to switch this to a more proper 
>> language list.
>> CLDR has: 
>> https://github.com/unicode-cldr/cldr-core/blob/master/availableLocales.json 
>> 
>>  
>> > >
>> 
>> So `name:zh` and `name:yue` are probably both valid language codes, and 
>> `name:zh-yue` probably is not.
>> 
>> Thanks,
>> Bryan
>> 
>> 
>> 
>> 
>>> On Nov 24, 2016, at 8:53 AM, jc86035  wrote:
>>> 
>>> Mostly in Hong Kong, some places with Cantonese names use name:yue=*,
>>> whereas others use name:zh-yue=* (which is supported by iD). Should
>>> those objects using the former be changed to use the latter? (In
>>> addition, should those objects with name:zh-yue=* same as name:zh=* have
>>> name:zh-yue=* deleted?)
>>> 
>>> jc86035
>>> 
>>> ___
>>> 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 
> 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> Il giorno 27 nov 2016, alle ore 14:28, yo paseopor  ha 
> scritto:
> 
> For me it is not a bad idea. OpenStreetmap has to start to think in a "global 
> map" as is a geographic database, so flights or ferries has to be inside in.


while ferries take more or less everytime the same route, airplanes don't as 
explained above. There's airspace, which has the 3d problem but could 
theoretically be mapped as areas with height information (but there's no way 
for mappers to observe it). IMHO this would cause much more disturbance than 
benefit (and likely there aren't any compatible sources available anyway).

What could be mapped are connections, i.e. relations with just the airports as 
members in the order they form the route, with operator tags, flight numbers, 
etc, but without connecting ways (as these aren't anything fixed). We'd end up 
with hundreds of relations for the major airports, obfuscating the other 
relations, but could be filtered. Also for these I'm not sure if there are any 
compatible sources, and if there were it seems more suitable to let users on 
the fly create these connections locally, as the airports with IATA codes are 
already there, and it seems trivial to do it, while osm data in this field 
would likely be incomplete and outdated anyway (too much change and too few 
users).

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

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

[Martin Koppenhoefer]

sent from a phone

> Il giorno 27 nov 2016, alle ore 15:12, Frederik Ramm  ha 
> scritto:
> 
> For public transport information, the fact that there is a flight
> connection between A and B might be interesting but that is just some
> company's proprietary schedule and not geodata that should be in OSM.


it's the proprietary(?) schedule of some public or private company offering a 
public service though, and connections between points in space/on the surface 
of the earth, clearly are geodata. Whether it should be in OSM is a different 
question, what clearly shouldn't be there are arbitrary "connection ways".


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

[Tagging] Feature Proposal - RFC - (3d_shop)

[José Juan Sánchez del Arco]

Hello everyone,

Please have a look at my new tag proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/3D_shop, a shop selling 
3D printers, materials and components for machines, or which offers 3D printing 
services.

Best regards,
Jose Sánchez

Sent from Mail for Windows 10

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