[Tagging] Re : Ski resort (once again)

[yve...@gmail.com]

There is already route=piste relations (the colors on the link provided).
This is something else.
Yves

- Reply message -
De : "Martin Koppenhoefer" 
Pour : "Tag discussion, strategy and related tools" 
Objet : [Tagging] Ski resort (once again)
Date : dim., févr. 3, 2013 23:59


2013/2/3 yvecai :
> The problem is the following: in this link, the nordic pistes belong to
> several interconnected 'resorts' or 'domains':
>
> http://www.pistes-nordiques.org/?zoom=13&lat=46.80895&lon=6.43328&layers=&e=false&m=raster
>
> There is the pistes of 'L'Auberson', 'Les Fourgs', 'La Seigne' and 'Jougne'.
>
> I think a relation where we could find those names would be great. To tag
> each way and relation with a 'resort' tag why not, but error-prone.
> I agree this is a just 'collection' of stuff, but these 'resorts' doesn't
> necessarily obey to administrative boundaries or geographical features.
>
> So what about a relation:
> type=site
> site=piste
> piste:type=nordic
> name='La Seigne'
> role=entrance could be helpful to know where to park.
>
> What do you think ?


wouldn't those by their nature (linear) be better route-relations?

cheers,
Martin

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

Re: [Tagging] Ski resort (once again)

[Janko Mihelić]

2013/2/3 yvecai 

>
> So what about a relation
>

There is a rule in Openstreetmap called "relations are not categories". This
is an 
explanation.

I was thinking about this same problem (grouping ski resorts), and I wanted
to introduce a tag "ticket:admission=*". That way you can tag the ski lifts
with, for example, ticket:admission=L'Auberson, and if there is a ticket
with which you can ski on all three, you write that one down too, delimited
with ";" (for example ticket:admission=L'Auberson;Tre Valli)

First I thought about the tag operator=*, but who knows which operators do
maintenance on which ski lifts. They may not be consistent with ticket
systems.

Than we could use the tag ticket:retail=* to tag the place where you can
buy certain tickets (ticket:retail=L'Auberson;Tre Valli)

I think this tagging system could be very helpful in many different places
where tickets are needed to get to a certain place. A router should first
route you to a parking that is close to the ticket:retail=* place, and only
then route you to the place itself.

Maybe we could use this tag on public transport, like buses or trains (use
ticket:admission=* on relations with type=bus or type=train).

As for parking, you just tag it with fee=no, and maybe capacity=*, and that
should be enough for routers to find a parking nearby. No relations needed
there.

Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ski resort (once again)

[Martin Koppenhoefer]

2013/2/3 yvecai :
> The problem is the following: in this link, the nordic pistes belong to
> several interconnected 'resorts' or 'domains':
>
> http://www.pistes-nordiques.org/?zoom=13&lat=46.80895&lon=6.43328&layers=&e=false&m=raster
>
> There is the pistes of 'L'Auberson', 'Les Fourgs', 'La Seigne' and 'Jougne'.
>
> I think a relation where we could find those names would be great. To tag
> each way and relation with a 'resort' tag why not, but error-prone.
> I agree this is a just 'collection' of stuff, but these 'resorts' doesn't
> necessarily obey to administrative boundaries or geographical features.
>
> So what about a relation:
> type=site
> site=piste
> piste:type=nordic
> name='La Seigne'
> role=entrance could be helpful to know where to park.
>
> What do you think ?


wouldn't those by their nature (linear) be better route-relations?

cheers,
Martin

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

Re: [Tagging] Is the difference between power station and sub station clear?

[François Lacombe]

Hi folks,

Here is the English translation of don-vip's answer to my last week message.

---

Hi François,

I'm glad to see someone be interested in that topic, and moreover a French
one.
I've actually built this proposition based upon the observation the power
tagging model isn't properly finalized. I'm happy to see this proposal
please you.

After a few weeks time, when I wasn't able to complete this proposal,
someone launch the vote and did not announce it on @talk
The result was 3 little votes, it was "rejected" according the schema
complexity, and I was pretty disgusted. Enough to don't finish it.

I've read quickly the past discussions about power tag on talk-fr and I
agree with what you're doing on that topic.
As I don't plan to invest myself in that domain any more (I'm 100% on JOSM
now), I give you my agreement to work on you own on my proposal, if you're
interested in, and to get it accepted :)

Be careful, I deliberately attempted to restrict my proposal to power
generation facility and not extend it to transmission ones as for obtain
concise work. But if the subject is to add 1 or 2 tag, I think it would be
a great occasion.

A+ Vincent.
---

According to what he said, I would re-introduce his proposal to re-vote it.
Feel free to continue the discussion on non-solved points before the vote
start.
Be sure the vote starting date will be announced properly on this
mailing-list.

Regards.


-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Ski resort (once again)

[yvecai]

The problem is the following: in this link, the nordic pistes belong to 
several interconnected 'resorts' or 'domains':


http://www.pistes-nordiques.org/?zoom=13&lat=46.80895&lon=6.43328&layers=&e=false&m=raster

There is the pistes of 'L'Auberson', 'Les Fourgs', 'La Seigne' and 'Jougne'.

I think a relation where we could find those names would be great. To 
tag each way and relation with a 'resort' tag why not, but error-prone.
I agree this is a just 'collection' of stuff, but these 'resorts' 
doesn't necessarily obey to administrative boundaries or geographical 
features.


So what about a relation:
type=site
site=piste
piste:type=nordic
name='La Seigne'
role=entrance could be helpful to know where to park.

What do you think ?

Yves

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

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[doug . fraser]

Followup to my post: 

I am here at the London OSM Hack Weekend and spoke to someone who explained 
to me the larger issues and questions about importing / updating metadata 
like LOCODEs that can't be surveyed - i.e. data where managing the process 
of keeping it current may be troublesome. 

I agree with everything he explained and so now I don't think updating the 
LOCODEs that are present, etc would be the best idea.  Letting the existing 
tags die off sounds like the best idea. 

But locodes are assigned to harbours and they are surveyable, can be 
verified by the public, all that sort of thing.  So the UN list could be 
used to update or verify that cities have appropriate harbour tags 
associated with them.  IIRC, Long Beach (or LA) was one test case I looked 
at and it didn't have a tag that i'd expected. 

So now my idea is to check the harbour tags against the UN data (this could 
also be done for rail stations) and then determine how much data is missing 
and what ought to be improved. 

A related idea is that port terminals (for commercial shipping) are 
becoming prominent features (e.g. they are getting their own locodes) and 
perhaps a new tag harbour:terminal (like harbour:pier) could be created for 
handling this data.  Container terminals are physical features and won't 
arbitrarily change, so they aren't metadata like LOCODEs. 

If anyone has any feedback, I'd appreciate it.  I don't plan on doing 
anything until I fully understand the details of all this, so I can write 
it all up, etc. 

doug 



[Imports] RFC - Adding UN LOCODE tags to OSM writes: 

Hi everyone,  

This is a duplicate of a email I sent to the Tagging list:  

The company I work for deals with shipping ports, UN LOCODEs, and shipping 
schedules - I had hoped to use OSM to correlate geographical type info and 
LOCODEs.  The problem has become messier than I ever thought, and 
unfortunately OSM does not have much in the way of LOCODE related data.  

At this point, we have a well maintained list of LOCODEs and other such 
data that I keep track with the UN list as it is updated.  So I thought 
it'd be useful to put all that into OSM and clean up the handful of LOCODE 
tags that I have seen in OSM.  This list also includes IATA data and some 
other port type info - everything has been gleaned from public data 
sources like the UN, so I'm sure there are no license related issues.  I'm 
also confident of the accuracy since I'm the one responsible for 
maintaining the data.  

I will write up a feature proposal on the wiki to outline the details, but 
first I wanted to see if there were any comments or advice people might 
have.  I do plan to automate the updates - none of this is map data per 
se, but just tags, so I assume there won't be any real complications. So I 
will read all about the guidelines around automation.  

The questions I had are:  

1) the UN provides geographical coordinates of these LOCODEs, typically 
the city center.  Is there any standard that OSM adheres to regarding the 
location of cities?  Anyone have any pointers to info I should read?  

2) alternative place names - the UN provides some data and we have data 
from other sources.  The data is good, but is there any consensus on this 
topic about how OSM ought to operate?  

3) locations/cities not in OSM at all - adding these in is a separate task 
entirely so I will leave that till I understand OSM better.  But if 
someone could point me in the right direction, that'd be great.  


Thanks
doug 


___
Imports mailing list
impo...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/imports


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

Re: [Tagging] Power Tagging

[Ole Nielsen]

On 03/02/2013 02:31, Michael Patrick wrote:

For reference, see the International Electrotechnical Commission (
http://www.iec.ch/about/ ) Electropedia ( http://www.electropedia.org/ )
or from the Glossary search at ( http://std.iec.ch/glossary  ),  to the
Overhead lines / Towers description page (
http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=466-08-08 )
where we see a diagram (
http://www.electropedia.org/iev/iev.nsf/master/466-08-08:fr/$FILE/466-fig2.gif
) and nomenclature in multiple languages: (English) double warren
redundant support ..


This is a highly useful reference that I would have liked to know about 
earlier. Now I see why the Germans are so fond of the "power=station" 
tag: en:substation = de:Station (authoritative!).


Whether we should go into details about how towers are braced etc can be 
discussed. If somebody wants to tag bracing types, ok with me, but I 
would find it of little added value in osm. There is already a scheme to 
tag different types or designs of towers, see 
http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower, but it does not go 
into that kind of details.



While I get that crowd generated attribute tagging has some unique
advantages, huge flexibility, allows whatever level of detail in any
language to be incorporates, at the other end of the pipe are editing
tools, maintenance bots, and rendering engines which do expect some sort
of conventions. There might be some advantages to at least examining
these vocabularies ( like the IEC). For instance, it might be revealed
that a proposed tag might actually be several additional tags ( I
usually can't see every possible variation when looking at a  specific
case). As dedicated user communities seek to add their own tags, there
would be a path to add more level of detail without breaking downstream
tools. Expanding tag sets to other languages is somewhat easier because
the basic objects and concepts are already translated. There also seems
to be a growing space of communities and applications outside of OSM
that would benefit from interoperability ( 'routing' as a quick example ).


I agree that it would have been better to define osm features according 
to internationally accepted standards to facilitate the use of such 
data. However the existing power tagging scheme is going to be difficult 
to adapt although our terminology and definitions are clearly different 
from IEC and often illogical ('cables' and 'wires' being some of the 
more strange tags). As an example we are currently trying to eliminate 
the station/substation confusion but even that isn't appreciated by 
everybody. For some features it may be possible to subtag further 
details according to the IEC definitions and I would certainly recommend 
to consult the IEC vocabulary when drafting new power related proposals.


Ole

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

Re: [Tagging] RFC - UN LOCODE tags

[Richard Welty]

On 2/3/13 8:48 AM, doug.fra...@tarisoga.com wrote:


I will write up a feature proposal on the wiki to outline the details, 
but first I wanted to see if there were any comments or advice people 
might have.  I do plan to automate the updates - none of this is map 
data per se, but just tags, so I assume there won't be any real 
complications. So I will read all about the guidelines around automation.

The questions I had are:
1) the UN provides geographical coordinates of these LOCODEs, 
typically the city center.  Is there any standard that OSM adheres to 
regarding the location of cities?  Anyone have any pointers to info I 
should read?
2) alternative place names - the UN provides some data and we have 
data from other sources.  The data is good, but is there any consensus 
on this topic about how OSM ought to operate?
3) locations/cities not in OSM at all - adding these in is a separate 
task entirely so I will leave that till I understand OSM better.  But 
if someone could point me in the right direction, that'd be great.

you probably want to take this up with the imports list as well.

richard


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

[Tagging] RFC - UN LOCODE tags

[doug . fraser]

Hi everyone, 

The company I work for deals with shipping ports, UN LOCODEs, and shipping 
schedules - I had hoped to use OSM to correlate geographical type info and 
LOCODEs.  The problem has become messier than I ever thought, and 
unfortunately OSM does not have much in the way of LOCODE related data. 

At this point, we have a well maintained list of LOCODEs and other such 
data that I keep track with the UN list as it is updated.  So I thought 
it'd be useful to put all that into OSM and clean up the handful of LOCODE 
tags that I have seen in OSM.  This list also includes IATA data and some 
other port type info - everything has been gleaned from public data sources 
like the UN, so I'm sure there are no license related issues.  I'm also 
confident of the accuracy since I'm the one responsible for maintaining the 
data. 

I will write up a feature proposal on the wiki to outline the details, but 
first I wanted to see if there were any comments or advice people might 
have.  I do plan to automate the updates - none of this is map data per se, 
but just tags, so I assume there won't be any real complications. So I will 
read all about the guidelines around automation. 

The questions I had are: 

1) the UN provides geographical coordinates of these LOCODEs, typically the 
city center.  Is there any standard that OSM adheres to regarding the 
location of cities?  Anyone have any pointers to info I should read? 

2) alternative place names - the UN provides some data and we have data 
from other sources.  The data is good, but is there any consensus on this 
topic about how OSM ought to operate? 

3) locations/cities not in OSM at all - adding these in is a separate task 
entirely so I will leave that till I understand OSM better.  But if someone 
could point me in the right direction, that'd be great. 


Thanks
doug

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

Re: [Tagging] Contents of tagging digest, Vol 41, Issue 8, message 4

[Martin Koppenhoefer]

2013/2/3 St Niklaas :
>> viaduct
>> A ''long'' rail, road, or other bridge made up of many short spans.
>> no
>> 7?572 0.45% hint for other mappers, no special treatment
> I used that one, after reading the Wiki I abandoned it.
> +1


actually the comment above is refering to bridge=no


>> aqueduct
>> 1?084 0.06% prefer historic=aqueduct for historic aqueducts (also
>> fragments) and would rather introduce a tag similar to "power" for
>> water if I wanted to map modern aqueducts. Anyway an aqueduct has not
>> much to do with bridges
> -1


> Both are IMHO originally latin


+1


>, a viaduct is a crossing between 2 ways and a
> aquaduct a crossing between a way and a waterway.


no, it is not about crossing, it is about "conducting", an aqueduct is
conducting water, a viaduct is conducting a road. An aqueduct can be
on the ground, on a wall, below ground, and also span over something
with a bridge. bridge=aqueduct is therefor not a suitable tag for
aqueducts, but it could be OK in some cases. In the end if you already
use a different tag to say it is an aqueduct you just as well use
bridge=yes for these parts.

cheers,
Martin

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

Re: [Tagging] Power Tagging

[Martin Koppenhoefer]

2013/2/3 Michael Patrick :
> For reference, see the International Electrotechnical Commission (
> http://www.iec.ch/about/ ) Electropedia ( http://www.electropedia.org/ ) or
> from the Glossary search at ( http://std.iec.ch/glossary  ),  to the
> Overhead lines / Towers description page (
> http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=466-08-08 )
> where we see a diagram (
> http://www.electropedia.org/iev/iev.nsf/master/466-08-08:fr/$FILE/466-fig2.gif
> ) and nomenclature in multiple languages: (English) double warren redundant
> support, (French) triangulation en losange, (Arabic)  تركيبة عل شكل المعين ,
> (German) Ausfachung mit gekreuzten Diagonalen und Sekundärfachwerk,
> (Spanish) celosía doble, (Italian) tralicciatura doppia con rompitratta,
> (Japanese) ダブルワーレン補助材, (Portuguese) reticulação em losango, (Swedish) dubbel
> diagonalvandring med knäckavstyvning.


if you are asking what might be a key for these, I'd use
tower:structure or similar. They are not details regarding "power" but
the structure of the support.


> It is true that these standard vocabularies drill down to excruciating
> detail which may not be relevant to OSM ( characteristics which are visible
> (or inferred, like voltage from the in out conductor spacing) .


well, for us it is relevant what interests the mappers ("anything you
like", facts)


> While I get that crowd generated attribute tagging has some unique
> advantages, huge flexibility, allows whatever level of detail in any
> language to be incorporates, at the other end of the pipe are editing tools,
> maintenance bots, and rendering engines which do expect some sort of
> conventions.


yes, that's the classic balance act we have to master somehow.
Preferably when you want to invent a new tag for which you don't find
yet documentation (and use) you will ask on one of the lists if there
is already someone using a tagging scheme for this. That way you can
be more confident that you haven't overlooked already in use tags and
reduce the possibility of creating duplicates.


> There might be some advantages to at least examining these
> vocabularies ( like the IEC). For instance, it might be revealed that a
> proposed tag might actually be several additional tags ( I usually can't see
> every possible variation when looking at a  specific case). As dedicated
> user communities seek to add their own tags, there would be a path to add
> more level of detail without breaking downstream tools.


+1, issues of copyright might come into play though


> Expanding tag sets
> to other languages is somewhat easier because the basic objects and concepts
> are already translated.


sometimes (in technical fields most probably, in other areas sometimes
there is lack or different concepts not directly associable, just have
a look at wikipedia interlanguage links to see the problems)


> There are several excellent one for LULC (Land Use and
> Land Cover) for example.


which is exactly the problem: there are several of them. There is not
the one and only true classification system, there are different
approaches (also depending on the method and scale of the data
collection and the level of detail). Not even the classification of
legally permitted land use is equal in different legislations, even
less that of the effective land use (=our tag landuse).
There are fundamental cultural differences (e.g. I remember
discussions with Americans for whom the craft tag seemed a peripheral
tag for artisans, while for Germans it was one of the main tags to
describe their environment (most of what they use it for would be
considered "industrial" by an American)).

cheers,
Martin

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

Re: [Tagging] Contents of tagging digest, Vol 41, Issue 8, message 4

[St Niklaas]

> Message: 4
> Date: Sat, 2 Feb 2013 18:57:36 +0100
> From: Martin Koppenhoefer 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Feature Proposal - RFC - Bridge types
> Message-ID:
>   
> Content-Type: text/plain; charset=UTF-8
>Hi Martin, 

> null
> viaduct
> A ''long'' rail, road, or other bridge made up of many short spans.
> no
> 7?572 0.45%   hint for other mappers, no special treatmentI used that one, 
> after reading the Wiki I abandoned it.+1

> null
> aqueduct
> 1?084 0.06%  prefer historic=aqueduct for historic aqueducts (also
> fragments) and would rather introduce a tag similar to "power" for
> water if I wanted to map modern aqueducts. Anyway an aqueduct has not
> much to do with bridges-1Both are IMHO originally latin, a viaduct is a 
> crossing between 2 ways and a aquaduct a crossing between a way and a 
> waterway. The last one has always a track or even 2 besides or above the 
> waterway. Whats the difference between this 'bridge' and a the other ones ? 
> Since I use them to cross a valley or a highway, since there less footbridges 
> over that kind of obstacles.
GreetzHendrik ___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging