Re: [Tagging] building = house vs detached.

2018-07-24 Thread Andrew Hain
I see building=house as useful because it distinguishes houses from blocks of 
flats but the case to have anything that repeats way geometry or 
building:levels is much less obvious.

--
Andrew

From: Paul Allen 
Sent: 23 July 2018 22:55:36
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] building = house vs detached.

On Mon, Jul 23, 2018 at 10:45 PM, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:

> On 23. Jul 2018, at 17:07, Paul Allen 
> mailto:pla16...@gmail.com>> wrote:
>
> How about building=residential to replace house/terrace/detached?


-1, there are several established tags for residential buildings in osm, e.g. 
apartments,

The wonderful thing about standards is that there are so many of them.  We have 
many tags for residential buildings
and the result is that they're used inconsistently.

and as the example shows, it isn’t possible to reliably identify terraced 
houses just by analyzing the geometry, so
why would we want to remove the details? If someone is only interested in a 
detail level like “residential”, they won’t have to care about the differences 
in meaning and can normalize them all locally to residential.

That's what we do with some other types of buildings.  We separate form from 
function.   We have industrial buildings
and then specify the industry.

We can have building=bungalow but that is redundant when it just means 
building:levels=1.

We can have building=detached, building=semi,  building=house with most people 
using them incorrectly or
inconsistently or we can have building=residential and let the footprint 
indicate the type.  Or, if you insist, add
residential=* where clarification is desirable.

We've just had a lot of people say "The wiki says this should be 
building=detached but I always use building=house."
That indicates the tags don't map well to how people actually think.  It also 
means that you can't rely on the value
used indicating what it is meant to.  We can carry on with the current muddle 
or we can try to do better.  You vote muddle.

--
Paul

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


Re: [Tagging] "sym" tag

2018-07-24 Thread José G Moya Y .
El mar., 24 jul. 2018 17:38, Andy Townsend  escribió:

What you would need to do would be different for the next one though.  You
can't assume that (e.g. "sym=church" actually means a church on the
ground.  You'll have to do this on a case by case basis.

In fact, know it's not church but a hermit.

Regarding the rendering, I've discovered there was a
amenity=place_of_worship  node hidden under the marker of the node I was
talking about. That explains it being rendered.

El mar., 24 jul. 2018 17:38, Andy Townsend  escribió:

> On 24/07/2018 15:59, José G Moya Y. wrote:
>
> I've found some places of worship tagged with the undocumented
> "sym=church" tag.
>
>
> They're from Garmin waypoints.  See
> https://taginfo.openstreetmap.org/keys/sym for other examples.  Don't
> just mechanically edit them, because there are likely other (different)
> issues with each one.
>
> Taking a specific example:
>
> https://www.openstreetmap.org/node/1420261739/history
>
> (according to Overpass that's the nearest "sym" to where I am right now)
>
> Here there are a couple of obvious issues:
>
>- It has an unfeasibly accurate "ele" tag
>- It has a "sym" tag which makes no sense
>- The "time" tag isn't really relevant to OSM
>- It's on a the T-junction of 3 walls.
>
>
> In this case I'd:
>
>- Verify the gate location from imagery if possible (likely it's north
>of south of the wall join)
>- Remove the "sym" tag
>- Remove the "time" tag
>- Remove the decimal points from the "ele" tag (or remove it
>altogether if it looks unfeasible)
>- Upload to OSM with a changeset comment that said what you did and
>why, and what imagery you used.
>
>
> What you would need to do would be different for the next one though.  You
> can't assume that (e.g. "sym=church" actually means a church on the
> ground.  You'll have to do this on a case by case basis.
>
>
> It's surprising to see how these places are being rendered as churches despite
> of this tag does not appear in the wiki (and no other tag related with
> worship is in the place).
>
>
> I'd be really surprised if any software (other than Garmin's waypoint
> display) actually renders these as churches.
>
> However, I'm sure that lots of maps renders things that aren't listed in
> the wiki (different types of shops is an obvious example).
>
> Best Regards,
>
> Andy
>
> ___
> 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] "sym" tag

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Jul 2018, at 20:56, José G Moya Y.  wrote:
> 
> In fact, know it's not church but a hermit.


In case you didn’t find it, there’s amenity=monastery and 
monastery:type=hermitage to tag a hermitage.

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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Jerry Clough - OSM
 On 23/07/2018 14:00, Martin Koppenhoefer wrote


  
 it does not seem to be a very promising concept though. Terraced houses are 
usually seen as a compromise for people who want an independent house, but 
cannot afford a detached one. Terraced houses are cheaper because they need 
less ground (i.e. you can usually find them where the ground is expensive to 
buy), expensive ground means you’ll try to use it intensively, which is 
contradicting the bungalow concept.Terraced houses are almost always narrow, 
deep and relatively high.Maybe in the UK with its tradition of terraced houses 
there could be a cultural interest in something like terraced bungalows and 
there is also an energetic advantage from reducing external walls, but overall 
there’s little danger this will become a widespread concept for housing. 
Cheers,Martin ___Tagging mailing 
listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging 
 An unwise generalisation. Some of the most expensive houses in the UK are 
terraced houses (see Stefan Muthesius "The English Terraced House"). Notable 
examples can be found in Belgravia, Regent's Park, Edinburgh New Town, Regency 
Bath, and many other cities. I can also think of examples in Paris, e.g., Place 
des Vosges. The UK is probably unusual in that terraced houses were built for 
all classes over around a couple of hundred years (roughly 1700 to 1900). 
  At the opposite end of the spectrum, back-to-back terraced houses still exist 
in several places, notably Beeston, a suburb of Leeds (see for instance this 
blog). Thus a plain building=terrace may be inadequate for many purposes (from 
identifying less-well of housing areas, to locating specific types of houses).
  On the actual tagging: it's certainly useful in the UK to distinguish between 
detached, semi-detached and terraced houses. As has been pointed out 
building:levels=1 may be an adequate synonym for bungalow, but there also exist 
"chalet bungalows" which have bedrooms in the roof (usually with dormer 
windows), and certainly I see many detached and semi-detached bungalows. Other 
housing types which may be highly UK specific are : mews houses (found behind 
the grander types of terrace in London and Edinburgh and a few other places, 
and often very expensive); maisonettes, purpose built flats in a structure 
which looks like a house (no good description on wikipedia); (modern british 
usage of) town house, a terraced house with integral garage on the ground floor 
and most living accommodation on the upper floors; link-detached houses, the 
garages of adjacent houses completely fill the space between them.
 I dont have any generic solution to all this, other than to continue 
collecting data. Where I have been trying to precisely delineate very specific 
types of housing I'm using 'private' tags (in part because I need to do archive 
work to find the actual codes used by the architects). 
A commercial mapping provider gave a talk at Geomob about 3 years ago: they 
have something like 70 building classes to cover the spectrum of building types 
in British cities. I have their brochure, but have deliberately avoided 
examining it too closely in case of inadvertently copying their ideas.
 Jerry
      
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Dangerous waterways tagging

2018-07-24 Thread François Lacombe
Hi Dave,

I agree about monsooon or snow melt.
Regarding industrial operations involving downstream rivers, there are
precise restrictions and perimeters may be publicly displayed like this
https://imgur.com/a/TLhZcgE

Regarding this particular place :
The stream https://www.openstreetmap.org/way/610040431 is dangerous at any
time due to those canals https://www.openstreetmap.org/way/610040433 and
https://www.openstreetmap.org/way/610040432
The canals are locked by automated gates which can send approximately 50
m3/s from the underground aqueduct once open when this plant
https://www.openstreetmap.org/way/305700031 isn't in operation

By a nice sunny summer day you may be highly tempted to go fishing in the
stream down from the regulation canals.
OSM is legit to warns you.

All the best

François


*François Lacombe*

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

2018-07-24 11:57 GMT+02:00 Dave F :

> Hi
>
> This is another one of those discussion which comes up every year or so.
>
> The perception of danger is subjective; which never fits well within OSM.
>
> Waterways are not dangerous in themselves. They are inanimate objects.
> They don't jump out & attack you as you walk by. It's the naive way people
> interact with them which causes injury.
>
> If there's a sign indicating danger, tag that.
>
> Cheers
> DaveF
>
>
> On 23/07/2018 21:48, François Lacombe wrote:
>
> Hi,
>
> As the discussion about intermittent/seasonal/... on waterways goes on,
> there is another thing to map: how waterways banks can be dangerous due to
> sudden rise or lower water level.
> It is actually related to what we intend to map with intermittent or
> seasonal.
>
> For example in France, we often find such warning signs:
> https://imgur.com/a/QUxuPem
>
> Precise sections of streams or rivers are marked as dangerous even in good
> weather.
> It is stronger than simple intermittence or seasonality because of
> industrial activities running upstream (mainly hydroelectric power
> generation or dam operation).
> Nevertheless, I didn't find any global database or public information
> displaying data about such particular flooding situations. OSM can be one
> of this kind.
>
> Here is a public display next to a power plant in French Alps (with a nice
> piece of OSM without attribution)
> https://imgur.com/a/TLhZcgE
>
> Then what could be the best way to tag it?
> No existing tag sounds suitable for this, even the idea of a single
> "permanence" key.
>
> All the best
>
> François
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Dangerous waterways tagging: hazard?

2018-07-24 Thread ael
On Mon, Jul 23, 2018 at 10:48:05PM +0200, François Lacombe wrote:
> 
> As the discussion about intermittent/seasonal/... on waterways goes on,
> there is another thing to map: how waterways banks can be dangerous due to
> sudden rise or lower water level.

The obvious tag is hazard, but for some incomprehensible reason it seems
to be used rather rarely. Perhaps it is not in editor presets?

ael


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


Re: [Tagging] Dangerous waterways tagging

2018-07-24 Thread Dave F

Hi

This is another one of those discussion which comes up every year or so.

The perception of danger is subjective; which never fits well within OSM.

Waterways are not dangerous in themselves. They are inanimate objects. 
They don't jump out & attack you as you walk by. It's the naive way 
people interact with them which causes injury.


If there's a sign indicating danger, tag that.

Cheers
DaveF

On 23/07/2018 21:48, François Lacombe wrote:

Hi,

As the discussion about intermittent/seasonal/... on waterways goes 
on, there is another thing to map: how waterways banks can be 
dangerous due to sudden rise or lower water level.
It is actually related to what we intend to map with intermittent or 
seasonal.


For example in France, we often find such warning signs:
https://imgur.com/a/QUxuPem

Precise sections of streams or rivers are marked as dangerous even in 
good weather.
It is stronger than simple intermittence or seasonality because of 
industrial activities running upstream (mainly hydroelectric power 
generation or dam operation).
Nevertheless, I didn't find any global database or public information 
displaying data about such particular flooding situations. OSM can be 
one of this kind.


Here is a public display next to a power plant in French Alps (with a 
nice piece of OSM without attribution)

https://imgur.com/a/TLhZcgE

Then what could be the best way to tag it?
No existing tag sounds suitable for this, even the idea of a single 
"permanence" key.


All the best

François


___
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] Use of namespace as a Lifecycle

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Jul 2018, at 18:00, yo paseopor  wrote:
> 
> abandoned: (~180.000) ? Are you telling me are these items now exists yet in 
> OSM?


yes, abandoned means there is an abandoned feature there. If you go there, you 
should see something (a feature in decay, most likely, e.g. a railway-track 
with trees growing between the rails). Abandoned is not only disused, but also 
in some form of decay.

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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Jul 2018, at 09:36, Andrew Hain  wrote:
> 
> -1, there are several established tags for residential buildings in osm, e.g. 
> apartments,
> 
> The wonderful thing about standards is that there are so many of them.  We 
> have many tags for residential buildings
> and the result is that they're used inconsistently.


I am not seeing this, I can see many levels of detail, from “yes” via 
“residential” to “house”, “detached” and finally specific local types like 
“trullo”.

It is not inconsistent (in a harmful way) to map with different level of 
detail/specificity, it is rather normal for a project with many contributors 
with different personal interests and fields of knowledge. It would be a 
problem if the inconsistency were industrial production buildings mapped as 
residential buildings (for example).

We should not remove the details, and nuances in this field, data consumers can 
deal with it, they will either treat all/most buildings the same (so it doesn’t 
matter to them anyway), or they could be specifically interested in generalized 
types they can now define as they need, or they are really interested in 
different dwelling typologies and their spatial distribution, and are happy 
with what they find in some places in osm.

What would IMHO make more sense are lists or better structured trees that show 
the system / hierarchy of the building values that are in use. The current flat 
list does not do a very good job in explaining the system nor for finding 
specific tags.

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


Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-24 Thread Warin

Hi,

As part of the proposal .. I think  a document on how to map PTv3 in the 
simplest most basic way needs to be done.

This would not be the bells and whistles method, but the bread and water 
method. The basics that would have the routing working and the map displaying 
things.

It needs to be done for at least trains and buses. Some would like ferries too.


That would demonstrate how easy PTv3 would be for mappers to map,
without going through the documentation for the extra features that actually 
don't help the routing.

On 25/07/18 00:56, Leo Gaspard wrote:


Hi Ilya,

I unfortunately won't be anywhere near Milan anytime soon, but thanks
for the invitation :)

The problem I can see with your proposal is that it appears to be based
on PTv1, not on PTv2, which looks much more logical to me (even though I
still don't understand it completely). I mean, there are 8 tags in your
proposal for “Stops and Stations”, whereas if I try to adapt marginally
PTv2 I would get to public_transport=platform, bus=yes / tram=yes / ...
; which sounds more consistent and easy to use both for the mapper and
for the data consumer. Same issue with 5 tags for “platforms”.

Basically, I feel like (without anything to prove my point) just
reordering and rewording the documentation for PTv2 (by explicitly
marking some elements as “optional if the mapper feels like mapping
them” and not talking about things that were done once) and maybe minor
changes would be enough for a huge boost in usability of PTv2, without
needing to rollback to PTv1 :) (again, I don't know what I'm talking
about, but the feeling I had from PTv2 is that it tried to unify tagging
so that it's easier to both remember and programmatically use, and the
feeling I have from your current specification is that it's not really
unified)


On 07/24/2018 11:32 PM, Ilya Zverev wrote:

Hi Leo,

As a person who tried for many years not to touch any public transport in OSM 
because of hard to understand tagging, I share your pain about missing 
tutorials and instructions. The situation with these is a bit better in the 
Russian part of wiki, because we don't have hordes of mappers eager to bikeshed 
every explanation.

The title of the proposal is a bit misfortunate. It is not a new schema that coexists 
with previous two. On the contrary, it (if accepted) will be the single reference schema 
that data processors and validators would be built against. The version is misleading, 
and I think I should've taken on SK53's suggestion to rename it to e.g. "Refined 
Public Transport Tagging".

What the proposal really is is a clarification of what PTv1/2 elements really 
mean and how and when to use them. I refrained from wording it as a tutorial, 
because the last time I did that, I've got a lot of rage over every tiny thing. 
Some people here are still angry at me for that. Proposals are not tutorials.

I hope this answers your points 1-5. If you read the new proposal carefully, you'll 
notice that unlike the previous proposals, it spends many words explaining reasons behind 
every decision. It also makes mapping routes simple, while keeping options for 
micromapping (see the "Examples" section).

PTv1 will never vanish, because we didn't have it in the first place. It was just a pile 
of tags (like highway=bus_stop) which everybody understood and which did not form a 
coherent "schema", and route relations that were basically collections of 
everything related to a route.

PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
mapping. It failed with many mappers like you (and me), because it was based on 
industry standards, which are very sensible, but imply a state-of-art editing 
system behind them. Mapping a route in PTv2 is like writing a GTFS feed in the 
Notepad.

The new proposal is about shedding off all the complexity, and leaving only 
elements required for using stops and routes. Once (if) it is accepted, it 
would be very easy to write a tutorial, because then you would be able to learn 
it gradually. First with collecting bus_stop nodes in a relation, then with 
platforms, and so on. The new proposed schema is flexible, which means you 
don't have to learn all of it to map a proper route. I believe that will 
attract many new mappers to add their public transport routes.

Thank you for your opinion, and I would very much like to discuss how can we 
make mapping routes simpler. If you're in Milan these holidays, come to my talk 
on Sunday morning, and look for a public transport BoF meeting, most likely on 
Monday.

Ilya


24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):

My point of view, as a beginner in OSM who still hasn't understood how
PTv1 and PTv2 are supposed to work (and thus didn't read this specific
proposal, take this as generic comments on PT tagging in OSM):

1. Beginners are already at a loss, introducing a third (!) tagging
scheme will just make things worse

2. If I were developer of an OSM tool, I'd be facepalming 

[Tagging] landuse=scrub

2018-07-24 Thread Warin

Hi,

The next landuse = landcover tag that I have come across is 
landuse=scrub .. some 1,600 use of it according to taginfo.



The obvious thing to do is change them to natural=scrub.

I have not 'looked' at them (selected one and checked OSM rendering, and 
some imagery to 'see' what is there).


There are none of these in 'my' local area.


But in principle I think this should be done. Any thoughts?


-

PS landuse=sand when about half and half to natural=sand and surface=sand.

A fair proportion of these are gold=bunker,

if I were to do it again I think I might go with both surface=sand and 
natural=sand in order to get golf=bunker rendering done.


Yes I know - tagging for the renders. But 'we' do that for bus stops :)




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


Re: [Tagging] Dangerous waterways tagging

2018-07-24 Thread Graeme Fitzpatrick
On 24 July 2018 at 18:49, François Lacombe 
wrote:

>
> No because water always flows, look at the left picture on the danger sign.
>

 Sorry, couldn't see the water - just looked like a dry gully

It's just that sometimes, hydroelectric operator releases big amount of
> water wich completely and quickly flood the river bed.
>

We have similar situations near here, not so much for hydro plants, but
where roads will be cut if the upstream dam spillway is opened. One example
is:
https://www.google.com/maps/@-27.4429915,152.6679699,3a,75y,35.71h,84.39t/data=!3m6!1e1!3m4!1sFjJWiXyzTOGjLkKotkCgkw!2e0!7i13312!8i6656,
which we only show as a bridge across the River
https://www.openstreetmap.org/#map=16/-27.4427/152.6735


> flood_prone could be a solution, but it's currently intended for monsoon
> or snow melt moments, not for few hours or minutes of human controlled
> flooding.
>

That's certainly the way that the "varying water level" page is written,
but the flood_prone key https://wiki.openstreetmap.org/wiki/Key:flood_prone
says " A way or an area that is prone to flooding". Yes, it goes on to also
say mostly after heavy rain, but I don't think it precludes any form of
flooding / inundation?

Do we have any way of tagging the rate at which the water level rises eg 1m
in 10 minutes? That may be another way of pointing out that this is a
dangerous area.

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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Jul 2018, at 09:36, Andrew Hain  wrote:
> 
> That's what we do with some other types of buildings.  We separate form from 
> function.   We have industrial buildings
> and then specify the industry.


building=industrial is very poor tagging (armchair level of detail), as 
industrial contains storage as well as production, these two would IMHO be a 
minimum distinction to make sense. Clearly a cement plant is a very different 
kind of structure than a warehouse or a sawmill or a chip production plant. If 
someone maps them all as industrial because they don’t care or know at the 
moment, that is fine, but they should not wonder if with the time these will 
become more refined.


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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Jul 2018, at 09:36, Andrew Hain  wrote:
> 
> We can have building=bungalow but that is redundant when it just means 
> building:levels=1.


I am still not sure building=bungalow really says nothing more than 1 floor, 
but if it did, it is ok.


> 
> We can have building=detached, building=semi,  building=house with most 
> people using them incorrectly or
> inconsistently or we can have building=residential and let the footprint 
> indicate the type. 


you can’t get the type by looking at the footprint.


Or, if you insist, add
> 
> residential=* where clarification is desirable.



there’s no benefit in splitting one good tag in 2, if the second makes the 
first redundant.


> 
> We've just had a lot of people say "The wiki says this should be 
> building=detached but I always use building=house."


They can do this, detached houses are a subclass of houses. Nobody urges them 
to add more detail.


> That indicates the tags don't map well to how people actually think.


come on, a handful of contributions to this thread, most people are ok with how 
it is and don’t engage in this discussion, because it is clear it will most 
likely not lead to changes in the tagging recommendations for residential 
buildings.

There are more than a million detached houses mapped as such. It is a common 
term, people understand it well, it won’t go away.


  It also means that you can't rely on the value
> 
> used indicating what it is meant to.  We can carry on with the current muddle 
> or we can try to do better.  You vote muddle.


Can you give an example why what you describe is “muddle” and how you cannot 
rely on it? How would the situation improve if all this information was 
replaced by “residential”?

I would not call this “muddle” but plurality. We are still not at a very good 
point with buildings (80% still not classified at all), but the situation is 
improving, last time I looked at it, more than 90% of all values were “yes”.
Shall we retag all building=residential to building=yes for consistency (after 
all it is likely that most residential buildings are tagged as “yes”)?


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


Re: [Tagging] Use of namespace as a Lifecycle

2018-07-24 Thread Warin

On 25/07/18 02:00, yo paseopor wrote:
Thank you for guide me to a project that...doesn't work at some times. 
You know now why my option is the one I have made.


In addition to that. As the future does not exist these items with 
proposed also does not exist, doesn't? So these (~20.000) items: out 
of OSM please.


The explanation also for disused is ok, but what about was: (~10.000) 
or abandoned: (~180.000) ? Are you telling me are these items now 
exists yet in OSM? Also this 
https://www.openstreetmap.org/way/41779143 
 ?


I don't map anything that does not exists, the works to do the 
conservation of the sand has almost done. The parking is 
transformed.It is not a parking no more but is the same zone.It is not 
the first example you can find of that in OSM.


Also I know in background OSM database does not erase anything!! (I 
have read it marks with non-visible tags or something like that) so 
there is no reason for losing the information we have now. It is 
present, it is real, and I invite you to visit this beautiful zone ;)




OSM in principle is for things that exist.

disused in OSM indicate that the feature is there, and can be easily 
restored back into functioning condition.
abandoned in OSM means you can still see something of the feature there, 
but it cannot be easily restored.


planning in OSM is strange. I don't map it. However some insist on 
adding things in the 'planning stage' .. so this does provide for it.
Where construction has started on one end then I see the point of having 
the rest of it as 'planned'.


But something that is no longer there? .. OHM is the place for that. OHM 
is evolving and young, so there will be times where things are not so good.
I have moved some things out of OSM into OHM. And will continue to do so 
where they are no longer on the ground.
Some things are historical even where they are still on the ground, I 
copy those from OSM to OHM .. but leave them in OSM.



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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Martin Koppenhoefer


sent from a phone

> On 25. Jul 2018, at 00:11, Colin Smale  wrote:
> 
> But we must also not be tempted to force multiple concepts into a single tag 
> hierarchy. Before we start down that path, let us be clear what the hierarchy 
> is intended to represent, and what factors are in-scope (a different brick 
> colour will not lead to a different building type, but brick-built vs. 
> wood-faced may impact the type).


I was mainly thinking about offering a possible structure for the tags that are 
used now (most usage). It would hopefully grow with the help of many mappers. 
Overlaps and orthogonal classes can be discussed when we find them. For rough 
classes like those that are mostly used, there is usually no material implied 
(material can be tagged separately anyway).



> Lets be explicit about whether it is as-built or as-used, and how to handle 
> mixed-use buildings.


These are both very good questions. Generally the type is as-built, but this 
includes transformations. If something was built as a water tower (extreme 
example) and now there are apartments in it, how do we classify it. The answer 
is probably in judging the single case. Does it still look like a water tower 
with apartments in, or is it not recognizable any more? Mostly I would tend to 
use the original purpose, which imposed the requirements that made the building 
what it is (unless drastical modifications were applied later on). 


For mixed use buildings: these could be types of their own. While 
mathematically there could be near infinite combinations, in practice there are 
not so many. There are surely also a handful of weird/unexpected combinations, 
but for these you’ll have problems with any system anyway, let’s not get them 
into the way of finding something for typical combinations (e.g. from bottom to 
top, all are optional, shops-offices-apartments). I’d treat shops and 
restaurants/pubs/cafes the same here.
A different approach would be splitting into building_part of blocks of 
building levels with the same structure and add level tags




> If we look first at as-built, we will need a parallel tagging taxonomy for 
> the usage aspect; and the other way around of course.


Usage is already tagged as POIs, if you map them as areas and add level tags 
you are done. (Do we need tags for residential units?)


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


Re: [Tagging] building = house vs detached.

2018-07-24 Thread Colin Smale
On 2018-07-24 23:51, Martin Koppenhoefer wrote:

> We should not remove the details, and nuances in this field, data consumers 
> can deal with it, they will either treat all/most buildings the same (so it 
> doesn't matter to them anyway), or they could be specifically interested in 
> generalized types they can now define as they need, or they are really 
> interested in different dwelling typologies and their spatial distribution, 
> and are happy with what they find in some places in osm. 
> 
> What would IMHO make more sense are lists or better structured trees that 
> show the system / hierarchy of the building values that are in use. The 
> current flat list does not do a very good job in explaining the system nor 
> for finding specific tags.

I am always in favour of initiatives to increase the structuredness of
the data. But we must also not be tempted to force multiple concepts
into a single tag hierarchy. Before we start down that path, let us be
clear what the hierarchy is intended to represent, and what factors are
in-scope (a different brick colour will not lead to a different building
type, but brick-built vs. wood-faced may impact the type). Lets be
explicit about whether it is as-built or as-used, and how to handle
mixed-use buildings. If we look first at as-built, we will need a
parallel tagging taxonomy for the usage aspect; and the other way around
of course.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] landuse=sand

2018-07-24 Thread Warin

Done. There will probably be more in the future.
As long as the numbers can be kept down then it will not get like landuse=grass.

On 20/07/18 06:13, Tobias Knerr wrote:


On 18.07.2018 07:43, Warin wrote:

I have already changed a few. Are there any comments on changing
landuse=sand, before it becomes like landuse=grass etc,?

I fully agree with you that landuse=sand should not be used. Existing
tags like natural=sand and surface=sand already cover sand-related use
cases just fine. So thanks for keeping an eye on this!

___
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 - Voting - ephemeral -STOPPED

2018-07-24 Thread Warin

Unfortunately seasonal has a wider use than just waterways ...
Used with highways ~8,000 times (probably snow closures)
Used with sports ~1,600 times (things like cricket in the summer and 
soccer in the winter)


So I don't think that water_permanence is all that useful.

On 20/07/18 05:45, François Lacombe wrote:

Hi

2018-07-19 2:17 GMT+02:00 Warin <61sundow...@gmail.com 
>:



That does not allow for a combination .. e.g.

seasonal presence in winter
intermittent presence in spring;summer

The present practice of adding the tag intermittent to anything
tagged seasonal does not help at all for any chance of
combinations ... so OSM may as well abandon any hope of detailing
any complex situation.


I think this is too variable, and then OSM isn't the best place to put 
kind of waterflow timeserie.
water_permanance=intermittent should also reflect that water may be 
there occasionally without any fixed pattern.


All the best

François



___
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] Documentation issues of PT tagging schemes

2018-07-24 Thread Roland Olbricht

Hi,

This would not be the bells and whistles method, but the bread and water 
method. The basics that would have the routing working and the map 
displaying things.


See
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
and
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform

Both wiki pages are up to date and pretty prefect. "Up to date" means 
that more than 90% of all public transport objects are mapped that way.


From a semantic way, it would only be necessary to drop a few words for
- tram stops without a platform
- subway stations: if the underground structure is not known then you 
should map at least "railway=station" + "name=" and all entrances

And a decent mapping scheme would be complete.

I have written routers for passengers, routers for the operators, a 
route display tool

https://overpass-api.de/public_transport.html
and a JOSM plugin for editing public transport. Bottom line: Nobody, 
really nobody needs relations of type stop_area, stop_area_group, 
route_master, network, and stop_position information.


This is also the thing I do not like about the proposal: it is again 
cluttered with also that complexity, mixing the important with the 
unimportant and the commonplace with the obscure.


The upside is: public transport is in a much better state than all the 
discussion contributions suggest. Public transport operators from five 
continents are now voluntarily using OpenStreetMap data for a wide range 
of purposes, because it is good enough to do so.


For discussing details I suggest the relevant mailing list
https://lists.openstreetmap.org/listinfo/talk-transit
It is purely about public transport and has some hundreds of 
subscribers. On this mailing list "tagging" here, between golf courses 
and detached houses relatively few people will find this discussion in 
the long run.


Best regards,
Roland

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


Re: [Tagging] Use of namespace as a Lifecycle

2018-07-24 Thread yo paseopor
Thank you for guide me to a project that...doesn't work at some times. You
know now why my option is the one I have made.

In addition to that. As the future does not exist these items with proposed
also does not exist, doesn't? So these (~20.000) items: out of OSM please.

The explanation also for disused is ok, but what about was: (~10.000) or
abandoned: (~180.000) ? Are you telling me are these items now exists yet
in OSM? Also this https://www.openstreetmap.org/way/41779143 ?

I don't map anything that does not exists, the works to do the conservation
of the sand has almost done. The parking is transformed.It is not a parking
no more but is the same zone.It is not the first example you can find of
that in OSM.

Also I know in background OSM database does not erase anything!! (I have
read it marks with non-visible tags or something like that) so there is no
reason for losing the information we have now. It is present, it is real,
and I invite you to visit this beautiful zone ;)

Salut i mapes
yopaseopor

PD: This issue is about a parking of the zone, it is not about an imported
item.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Dangerous waterways tagging

2018-07-24 Thread François Lacombe
Hi Graeme,

2018-07-24 0:12 GMT+02:00 Graeme Fitzpatrick :

>
> On 24 July 2018 at 06:48, François Lacombe 
> wrote:
>
>>
>> Then what could be the best way to tag it?
>> No existing tag sounds suitable for this, even the idea of a single
>> "permanence" key.
>>
>
> I think intermittent would still be correct, because the water is only
> sometimes there?
>

No because water always flows, look at the left picture on the danger sign.
It's just that sometimes, hydroelectric operator releases big amount of
water wich completely and quickly flood the river bed.


> Saw reference to https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverb
> ank#Varying_water_level_river which also suggests use of a
> flood_prone=yes tag, which may also work, possibly together with a
> max_depth tag?
>

flood_prone could be a solution, but it's currently intended for monsoon or
snow melt moments, not for few hours or minutes of human controlled
flooding.

All the best

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


[Tagging] Use of namespace as a Lifecycle

2018-07-24 Thread yo paseopor
Hi!

As I have received some notes for Mueschel and other user in a authorized
import of the Spanish Cadastre I want to explain some variations I use in
tagging of erased items. The rationale is simple: If I can use the prefix
"was:" and also exists https://wiki.openstreetmap.org/wiki/Namespace and
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix why I can't use it
with exact information: nor "was" but the year or the exact date of the
information (I know it because I am from the zone of that item).

Yes, I see there is with some suffixes, specially name  . But if I do that
I will lose some information I have had with the other tags. Also I would
might use it a suffix (one user told me query it aat taginfo : about ~100
uses) . And then I think: What if I do the same but with the prefix (as the
lifecycle prefix) . In that way the tags will be ordered by year, making
easy the possibility to make a map with a specific year, for example. Also
I don't lose any information and as the prefix (not new tags, sorry) is
numeric when you order the tags to edit in software like JOSM these are
together without bug disturbances or influences on the present of the
information. Also these kind of tags would be able to be ignored to
standard systems as iD, for example. It is better to make that in prefix
than the suffix.

Salut i mapes
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Use of namespace as a Lifecycle

2018-07-24 Thread Ilya Zverev
Lifecycle prefixes are not for adding historic or future data in OpenStreetMap. 
Please see http://openhistorymap.org/ for that.

These prefixes are in OSM only to avoid mapping mistakes. For example, when a 
building is visible on a commonly used satellite imagery, but has been 
demolished, we use was:building (not sure about the exact prefix) to tell 
mappers not to re-add it to the map. When a mapper finds a plan for a new city 
block, a prefix "proposed:" will tell them that yes, we know about that plan, 
but it's not up yet.

Another use for lifecycle prefixes is a temporary closure. For example, when a 
shop closes and most likely another shop will open, we add "disused:shop" to 
mark the location of the POI, prompting to re-survey it.

By no means you should use these prefixes to _add_ information about something 
that's not there. OSM is only for objects that exist on the ground right now. 
With a few exceptions dictated by nature of mapping.

Ilya

> 24 июля 2018 г., в 16:30, yo paseopor  написал(а):
> 
> Hi!
> 
> As I have received some notes for Mueschel and other user in a authorized 
> import of the Spanish Cadastre I want to explain some variations I use in 
> tagging of erased items. The rationale is simple: If I can use the prefix 
> "was:" and also exists https://wiki.openstreetmap.org/wiki/Namespace and 
> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix why I can't use it with 
> exact information: nor "was" but the year or the exact date of the 
> information (I know it because I am from the zone of that item).
> 
> Yes, I see there is with some suffixes, specially name  . But if I do that I 
> will lose some information I have had with the other tags. Also I would might 
> use it a suffix (one user told me query it aat taginfo : about ~100 uses) . 
> And then I think: What if I do the same but with the prefix (as the lifecycle 
> prefix) . In that way the tags will be ordered by year, making easy the 
> possibility to make a map with a specific year, for example. Also I don't 
> lose any information and as the prefix (not new tags, sorry) is numeric when 
> you order the tags to edit in software like JOSM these are together without 
> bug disturbances or influences on the present of the information. Also these 
> kind of tags would be able to be ignored to standard systems as iD, for 
> example. It is better to make that in prefix than the suffix.
> 
> Salut i mapes
> yopaseopor
> ___
> 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] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Leo Gaspard
My point of view, as a beginner in OSM who still hasn't understood how
PTv1 and PTv2 are supposed to work (and thus didn't read this specific
proposal, take this as generic comments on PT tagging in OSM):

 1. Beginners are already at a loss, introducing a third (!) tagging
scheme will just make things worse

 2. If I were developer of an OSM tool, I'd be facepalming as soon as I
saw the word “PTv3”

 3. What is *really* needed is a clarification of what PTv[12] actually
mean. This is first and foremost a documentation issue, not a tagging
scheme issue.

 4. If I understood correctly, it's possible to use PTv2 with as few
tags as PTv1, but noone really understands it because the documentation
is such a mess. So I think a proposal of “Clarification of the relative
importance of tags in Public Transportation tagging” would be great.

 5. Such a proposal would “just” improve the documentation for PTv2 and
erase completely any reference to PTv1 from the wiki (or move it to a
“historic tagging scheme, no longer to be used, but that could be
necessary to understand for consumers until the migration has ended”
section)

 6. I personally spent at least half an hour (didn't count) trying to
understand how to tag public transportation. After having tried to read
the wiki, I just ragequit. The *documentation* is the issue for public
transport, and adding a third tagging scheme will only make things worse.

 7. Once the documentation about PTv1 will have vanished and about PTv2
will be clear (and once the names PTv* will have disappeared to just be
called “PT tagging”, in order to be less frightening for the beginner),
*then* it would be interesting to discuss incremental modifications of
the PT scheme. I guess that's where the changes you're proposing for
“PTv3” (something that I think should not ever happen, would it be just
for its name) would be interesting to integrate.

 8. For my desiderata about the documentation, I think it should:
 1. Be simple to read
 2. Go from the simplest tagging elements to the most complex. For
example, if I understood correctly PTv2 (ie. likely not), something like:
 1. how to place public_transport=stop_position
 2. how to make a route relation
 3. how to make a master route relation
 4. how to add public_transport=platform for people who feel like it
 3. Fit in a single page (having to switch back and forth between
dozens of pages for PT is just impossible to do while keeping focus)
 4. Potentially, *at the end, once all important concepts will have
been explained*, link to pages of individual transportation methods
 5. Be written in a didactic style. Currently it's full of “There
was this for a long time, and also that and that, but that is made
possible by PTv2”. BUT WHAT SHOULD I DO? (sorry, that's not to be read
yelling, just my internal thoughts when reading this kind of
paragraphs). That's just not how we can make people do something, that's
just a way to mix up everyone's mind but the minds of people who
actively designed the scheme.
 6. Give instructions as for what to do when the information is
incomplete (eg. I saw a few stops but not the full route, but I've got a
picture of the list of stations, what should I do?)

Again, these are my 2¢ as a beginner who tried to understand the current
way of tagging PT and just didn't understand it enough to try actually
mapping with it. Also, obviously, I can say how I would want the page to
be, but I can't do it myself because I just didn't manage to understand
in a reasonable amount of time the PT tagging scheme. So I'll have to
rely on you (yes, thou who readeth me) to write it, sorry!


On 07/20/2018 10:48 PM, Ilya Zverev wrote:
> Hi folks,
> 
> As you might've noticed, in the past year there has been growing discomfort 
> with the current Public Transport tagging schema. Of course, it brought order 
> to our route relations, but also introduced a lot of redundant concepts. 
> We've seen a couple proposals aiming to fix some of issues, but nothing stuck.
> 
> Please consider this new revision for the PT schema, which addresses most of 
> the issues, while keeping as backward compatible as possible:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
> 
> I'd be happy to hear any suggestions. Next week, I'll be presenting it, among 
> other things, during my talk "What's up with the public transport" at the 
> State of the Map conference.
> 
> Thanks,
> Ilya
> ___
> 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] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Jo
The whole point of wanting to move to a simpler tagging scheme is to become
able to write simple to understand documentation.

Dropping the "v1" tags that some like to call 'deprecated' is not possible,
because then your stops don't render.
Replacing highway=bus_stop by public_transport=platform doesn't work
either, as you lose the information about the mode of transport,
bus=yes/tram=yes.

Dropping the public_transport tags on stops seems somewhat more
straightforward, but isn't completely either. (For example, I don't like
stop_position nodes and won't add them everywhere, but I had started to add
them where the itineraries terminate).

We're stuck.

When PT_Assistant stabilizes and becomes usable with josm_tested.jar, I'll
create some videos on what I consider to be "reasonable practices". That
will be in about 3 weeks, normally.

Polyglot

Op di 24 jul. 2018 om 15:56 schreef Leo Gaspard :

> My point of view, as a beginner in OSM who still hasn't understood how
> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
> proposal, take this as generic comments on PT tagging in OSM):
>
>  1. Beginners are already at a loss, introducing a third (!) tagging
> scheme will just make things worse
>
>  2. If I were developer of an OSM tool, I'd be facepalming as soon as I
> saw the word “PTv3”
>
>  3. What is *really* needed is a clarification of what PTv[12] actually
> mean. This is first and foremost a documentation issue, not a tagging
> scheme issue.
>
>  4. If I understood correctly, it's possible to use PTv2 with as few
> tags as PTv1, but noone really understands it because the documentation
> is such a mess. So I think a proposal of “Clarification of the relative
> importance of tags in Public Transportation tagging” would be great.
>
>  5. Such a proposal would “just” improve the documentation for PTv2 and
> erase completely any reference to PTv1 from the wiki (or move it to a
> “historic tagging scheme, no longer to be used, but that could be
> necessary to understand for consumers until the migration has ended”
> section)
>
>  6. I personally spent at least half an hour (didn't count) trying to
> understand how to tag public transportation. After having tried to read
> the wiki, I just ragequit. The *documentation* is the issue for public
> transport, and adding a third tagging scheme will only make things worse.
>
>  7. Once the documentation about PTv1 will have vanished and about PTv2
> will be clear (and once the names PTv* will have disappeared to just be
> called “PT tagging”, in order to be less frightening for the beginner),
> *then* it would be interesting to discuss incremental modifications of
> the PT scheme. I guess that's where the changes you're proposing for
> “PTv3” (something that I think should not ever happen, would it be just
> for its name) would be interesting to integrate.
>
>  8. For my desiderata about the documentation, I think it should:
>  1. Be simple to read
>  2. Go from the simplest tagging elements to the most complex. For
> example, if I understood correctly PTv2 (ie. likely not), something like:
>  1. how to place public_transport=stop_position
>  2. how to make a route relation
>  3. how to make a master route relation
>  4. how to add public_transport=platform for people who feel like
> it
>  3. Fit in a single page (having to switch back and forth between
> dozens of pages for PT is just impossible to do while keeping focus)
>  4. Potentially, *at the end, once all important concepts will have
> been explained*, link to pages of individual transportation methods
>  5. Be written in a didactic style. Currently it's full of “There
> was this for a long time, and also that and that, but that is made
> possible by PTv2”. BUT WHAT SHOULD I DO? (sorry, that's not to be read
> yelling, just my internal thoughts when reading this kind of
> paragraphs). That's just not how we can make people do something, that's
> just a way to mix up everyone's mind but the minds of people who
> actively designed the scheme.
>  6. Give instructions as for what to do when the information is
> incomplete (eg. I saw a few stops but not the full route, but I've got a
> picture of the list of stations, what should I do?)
>
> Again, these are my 2¢ as a beginner who tried to understand the current
> way of tagging PT and just didn't understand it enough to try actually
> mapping with it. Also, obviously, I can say how I would want the page to
> be, but I can't do it myself because I just didn't manage to understand
> in a reasonable amount of time the PT tagging scheme. So I'll have to
> rely on you (yes, thou who readeth me) to write it, sorry!
>
>
> On 07/20/2018 10:48 PM, Ilya Zverev wrote:
> > Hi folks,
> >
> > As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot 

Re: [Tagging] "sym" tag

2018-07-24 Thread Andy Townsend

On 24/07/2018 15:59, José G Moya Y. wrote:
I've found some places of worship tagged with the undocumented 
"sym=church" tag.


They're from Garmin waypoints.  See 
https://taginfo.openstreetmap.org/keys/sym for other examples. Don't 
just mechanically edit them, because there are likely other (different) 
issues with each one.


Taking a specific example:

https://www.openstreetmap.org/node/1420261739/history

(according to Overpass that's the nearest "sym" to where I am right now)

Here there are a couple of obvious issues:

 * It has an unfeasibly accurate "ele" tag
 * It has a "sym" tag which makes no sense
 * The "time" tag isn't really relevant to OSM
 * It's on a the T-junction of 3 walls.


In this case I'd:

 * Verify the gate location from imagery if possible (likely it's north
   of south of the wall join)
 * Remove the "sym" tag
 * Remove the "time" tag
 * Remove the decimal points from the "ele" tag (or remove it
   altogether if it looks unfeasible)
 * Upload to OSM with a changeset comment that said what you did and
   why, and what imagery you used.


What you would need to do would be different for the next one though.  
You can't assume that (e.g. "sym=church" actually means a church on the 
ground.  You'll have to do this on a case by case basis.




It's surprising to see how these places are being rendered as churches 
despite of this tag does not appear in the wiki (and no other tag 
related with worship is in the place).


I'd be really surprised if any software (other than Garmin's waypoint 
display) actually renders these as churches.


However, I'm sure that lots of maps renders things that aren't listed in 
the wiki (different types of shops is an obvious example).


Best Regards,

Andy

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


Re: [Tagging] Use of namespace as a Lifecycle

2018-07-24 Thread Mateusz Konieczny
24. Lipiec 2018 15:30 od yopaseo...@gmail.com :


> tagging of erased items
>




Please, do not add (especially via import!) objects that are no longer 
existing. 

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


Re: [Tagging] Documentation issues of PT tagging schemes

2018-07-24 Thread Leo Gaspard
On 07/24/2018 11:17 PM, Jo wrote:
> The whole point of wanting to move to a simpler tagging scheme is to become
> able to write simple to understand documentation.

From what I understood (so, second-hand information) PTv2 can be used
with as few objects and tags as PTv1, so it's not inherently more
complex. However, it allows more things to be tagged. Putting these
“more things” in small font at the end of the wiki page would be enough
to have a simple, yet complete documentation, and leave people who like
PTv2 the ability to tag complex things :)

> Dropping the "v1" tags that some like to call 'deprecated' is not possible,
> because then your stops don't render.

Honestly… proposal, mass-edit, renderers (that will have had a say in
the discussion, obviously, but I don't think they wouldn't welcome a
reduction of the number of tagging schemes) will be forced to adapt, done.

There seems to be strong resistance in OSM against re-tagging and
mass-edits, but in this special case, so long as it can be done in a
loss-less way, I couldn't understand how all data consumers and all
mappers (interested in having newcomers understand the documentation)
wouldn't agree.

So long as there will be 2+ tagging schemes in operation it'll not be
possible to have a simple documentation, and things will be a mess.

> Replacing highway=bus_stop by public_transport=platform doesn't work
> either, as you lose the information about the mode of transport,
> bus=yes/tram=yes.

https://wiki.openstreetmap.org/wiki/Public_transport seems to mention
that `highway=bus_stop` could be relatively well replaced by
`public_transport=platform, highway=bus_stop` (so just adding
`public_transport=platform`? Then again I don't understand what is PTv1
and what is PTv2 and what is a mix of “people actually do that” in this
page).

I personally don't care if “PT” is not exactly PTv2 but a mix of PTv1
and PTv2. All I care about is having clear guidelines, and I've been
told PTv2 is basically more featureful than PTv1 but still allowing
simple mapping, so PTv2 looks like the thing to use to me.

Then, once this “PT” tagging scheme would have been documented,
incremental improvements could be proposed to it, like having `bus=yes`
/ `tram=yes` tags on platforms or whatever.

All I'm saying is that *before* changing the way we tag, we should first
document clearly what people currently do and make the Grand Public
Transport Unification happen.

> Dropping the public_transport tags on stops seems somewhat more
> straightforward, but isn't completely either. (For example, I don't like
> stop_position nodes and won't add them everywhere, but I had started to add
> them where the itineraries terminate).

Maybe in my list I inverted stop_position and platform, I don't know.
But such a “simplify the documentation” effort would have to decide
which one is important and which one is not, and then make it explicit
so that everyone can tag just the important one and forget the
non-important one if they don't feel like it.

> We're stuck.

Until there is a clearly documented reasonably usable **unambiguous**
tagging scheme, then I agree with you, unfortunately. And a mass edit
would likely help for tools to be able to become *much* simpler by
handling only one tagging scheme and not trying to support 2,5 tagging
schemes :)

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


Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Leo Gaspard
Hi Ilya,

I unfortunately won't be anywhere near Milan anytime soon, but thanks
for the invitation :)

The problem I can see with your proposal is that it appears to be based
on PTv1, not on PTv2, which looks much more logical to me (even though I
still don't understand it completely). I mean, there are 8 tags in your
proposal for “Stops and Stations”, whereas if I try to adapt marginally
PTv2 I would get to public_transport=platform, bus=yes / tram=yes / ...
; which sounds more consistent and easy to use both for the mapper and
for the data consumer. Same issue with 5 tags for “platforms”.

Basically, I feel like (without anything to prove my point) just
reordering and rewording the documentation for PTv2 (by explicitly
marking some elements as “optional if the mapper feels like mapping
them” and not talking about things that were done once) and maybe minor
changes would be enough for a huge boost in usability of PTv2, without
needing to rollback to PTv1 :) (again, I don't know what I'm talking
about, but the feeling I had from PTv2 is that it tried to unify tagging
so that it's easier to both remember and programmatically use, and the
feeling I have from your current specification is that it's not really
unified)


On 07/24/2018 11:32 PM, Ilya Zverev wrote:
> Hi Leo,
> 
> As a person who tried for many years not to touch any public transport in OSM 
> because of hard to understand tagging, I share your pain about missing 
> tutorials and instructions. The situation with these is a bit better in the 
> Russian part of wiki, because we don't have hordes of mappers eager to 
> bikeshed every explanation.
> 
> The title of the proposal is a bit misfortunate. It is not a new schema that 
> coexists with previous two. On the contrary, it (if accepted) will be the 
> single reference schema that data processors and validators would be built 
> against. The version is misleading, and I think I should've taken on SK53's 
> suggestion to rename it to e.g. "Refined Public Transport Tagging".
> 
> What the proposal really is is a clarification of what PTv1/2 elements really 
> mean and how and when to use them. I refrained from wording it as a tutorial, 
> because the last time I did that, I've got a lot of rage over every tiny 
> thing. Some people here are still angry at me for that. Proposals are not 
> tutorials.
> 
> I hope this answers your points 1-5. If you read the new proposal carefully, 
> you'll notice that unlike the previous proposals, it spends many words 
> explaining reasons behind every decision. It also makes mapping routes 
> simple, while keeping options for micromapping (see the "Examples" section).
> 
> PTv1 will never vanish, because we didn't have it in the first place. It was 
> just a pile of tags (like highway=bus_stop) which everybody understood and 
> which did not form a coherent "schema", and route relations that were 
> basically collections of everything related to a route.
> 
> PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
> mapping. It failed with many mappers like you (and me), because it was based 
> on industry standards, which are very sensible, but imply a state-of-art 
> editing system behind them. Mapping a route in PTv2 is like writing a GTFS 
> feed in the Notepad.
> 
> The new proposal is about shedding off all the complexity, and leaving only 
> elements required for using stops and routes. Once (if) it is accepted, it 
> would be very easy to write a tutorial, because then you would be able to 
> learn it gradually. First with collecting bus_stop nodes in a relation, then 
> with platforms, and so on. The new proposed schema is flexible, which means 
> you don't have to learn all of it to map a proper route. I believe that will 
> attract many new mappers to add their public transport routes.
> 
> Thank you for your opinion, and I would very much like to discuss how can we 
> make mapping routes simpler. If you're in Milan these holidays, come to my 
> talk on Sunday morning, and look for a public transport BoF meeting, most 
> likely on Monday.
> 
> Ilya
> 
>> 24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):
>>
>> My point of view, as a beginner in OSM who still hasn't understood how
>> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
>> proposal, take this as generic comments on PT tagging in OSM):
>>
>> 1. Beginners are already at a loss, introducing a third (!) tagging
>> scheme will just make things worse
>>
>> 2. If I were developer of an OSM tool, I'd be facepalming as soon as I
>> saw the word “PTv3”
>>
>> 3. What is *really* needed is a clarification of what PTv[12] actually
>> mean. This is first and foremost a documentation issue, not a tagging
>> scheme issue.
>>
>> 4. If I understood correctly, it's possible to use PTv2 with as few
>> tags as PTv1, but noone really understands it because the documentation
>> is such a mess. So I think a proposal of “Clarification of the relative
>> importance of tags 

Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Ilya Zverev
Hi Leo,

As a person who tried for many years not to touch any public transport in OSM 
because of hard to understand tagging, I share your pain about missing 
tutorials and instructions. The situation with these is a bit better in the 
Russian part of wiki, because we don't have hordes of mappers eager to bikeshed 
every explanation.

The title of the proposal is a bit misfortunate. It is not a new schema that 
coexists with previous two. On the contrary, it (if accepted) will be the 
single reference schema that data processors and validators would be built 
against. The version is misleading, and I think I should've taken on SK53's 
suggestion to rename it to e.g. "Refined Public Transport Tagging".

What the proposal really is is a clarification of what PTv1/2 elements really 
mean and how and when to use them. I refrained from wording it as a tutorial, 
because the last time I did that, I've got a lot of rage over every tiny thing. 
Some people here are still angry at me for that. Proposals are not tutorials.

I hope this answers your points 1-5. If you read the new proposal carefully, 
you'll notice that unlike the previous proposals, it spends many words 
explaining reasons behind every decision. It also makes mapping routes simple, 
while keeping options for micromapping (see the "Examples" section).

PTv1 will never vanish, because we didn't have it in the first place. It was 
just a pile of tags (like highway=bus_stop) which everybody understood and 
which did not form a coherent "schema", and route relations that were basically 
collections of everything related to a route.

PTv2 (based on Oxomoa's schema) was an attempt at introducing an order into 
mapping. It failed with many mappers like you (and me), because it was based on 
industry standards, which are very sensible, but imply a state-of-art editing 
system behind them. Mapping a route in PTv2 is like writing a GTFS feed in the 
Notepad.

The new proposal is about shedding off all the complexity, and leaving only 
elements required for using stops and routes. Once (if) it is accepted, it 
would be very easy to write a tutorial, because then you would be able to learn 
it gradually. First with collecting bus_stop nodes in a relation, then with 
platforms, and so on. The new proposed schema is flexible, which means you 
don't have to learn all of it to map a proper route. I believe that will 
attract many new mappers to add their public transport routes.

Thank you for your opinion, and I would very much like to discuss how can we 
make mapping routes simpler. If you're in Milan these holidays, come to my talk 
on Sunday morning, and look for a public transport BoF meeting, most likely on 
Monday.

Ilya

> 24 июля 2018 г., в 16:55, Leo Gaspard  написал(а):
> 
> My point of view, as a beginner in OSM who still hasn't understood how
> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
> proposal, take this as generic comments on PT tagging in OSM):
> 
> 1. Beginners are already at a loss, introducing a third (!) tagging
> scheme will just make things worse
> 
> 2. If I were developer of an OSM tool, I'd be facepalming as soon as I
> saw the word “PTv3”
> 
> 3. What is *really* needed is a clarification of what PTv[12] actually
> mean. This is first and foremost a documentation issue, not a tagging
> scheme issue.
> 
> 4. If I understood correctly, it's possible to use PTv2 with as few
> tags as PTv1, but noone really understands it because the documentation
> is such a mess. So I think a proposal of “Clarification of the relative
> importance of tags in Public Transportation tagging” would be great.
> 
> 5. Such a proposal would “just” improve the documentation for PTv2 and
> erase completely any reference to PTv1 from the wiki (or move it to a
> “historic tagging scheme, no longer to be used, but that could be
> necessary to understand for consumers until the migration has ended”
> section)
> 
> 6. I personally spent at least half an hour (didn't count) trying to
> understand how to tag public transportation. After having tried to read
> the wiki, I just ragequit. The *documentation* is the issue for public
> transport, and adding a third tagging scheme will only make things worse.
> 
> 7. Once the documentation about PTv1 will have vanished and about PTv2
> will be clear (and once the names PTv* will have disappeared to just be
> called “PT tagging”, in order to be less frightening for the beginner),
> *then* it would be interesting to discuss incremental modifications of
> the PT scheme. I guess that's where the changes you're proposing for
> “PTv3” (something that I think should not ever happen, would it be just
> for its name) would be interesting to integrate.
> 
> 8. For my desiderata about the documentation, I think it should:
> 1. Be simple to read
> 2. Go from the simplest tagging elements to the most complex. For
> example, if I understood correctly PTv2 (ie. likely not), something like:
> 1. 

Re: [Tagging] building = house vs detached.

2018-07-24 Thread Jmapb

On 7/23/2018 5:56 PM, Martin Koppenhoefer wrote:


On 23. Jul 2018, at 17:08, Jmapb  wrote:

woke up to the conclusion that the attached/detached/semi-detached distinction 
is not a great use of the building tag. As mentioned by André, we can literally 
see on the map if these house footprints are attached via shared party wall.


it is not possible to do it reliably for terraced houses, because they are not 
only characterized by being attached.


This is true. Once a terrace has been converted from a single 
building=terrace way to a row of building=house ways, there's no sure 
way to distinguish it from a group of same-sized adjacent non-terrace 
houses. If we want to be able to pinpoint terraces, we should leave them 
as building=terrace ways. The wiki, though, specifically encourages 
breaking them up into houses.


Is it important to be able to query the map for terraces? If so, the 
wiki should change. Change the text to favor a single building=terrace 
way... or encourage a value like building=terrace_house when dividing 
them up into individual residences. But my guess is that the number of 
terraces already chopped up into building=house is so large that this 
would be futile.



So there's really no need to describe the attached-ness using the building tag. 
 So the building tag is freed up to describe the characteristic style of 
the building  -- hut, shed, bungalow, house, apartments, villa, static_caravan


if you agree with the list above it seems more consistent not to drop detached 
in favor of residential; detached, semi-detached and terraced are all subtypes 
of houses, there is some overlap with bungalows and villas.


I don't consider that list to be canonical, just rattling off some of 
the more popular typologies. But in my mind, if the attached-ness can be 
visually seen on the map and geometrically determined by examining 
adjacent ways (admittedly this would be a complex query -- can't even 
begin to think how I'd code that in overpass) there's no need to crowd 
that info into the value of the building tag.


Mainly, I'm doubting the need for building=detached -- it's a house, and 
if it doesn't share a party wall with another building, then clearly 
it's a detached house. But it's also true that the word "detached" 
evokes a certain style of building, and if mappers think it's a good 
value to describe a particular building, I'm not going to argue, or 
advocate for retagging.


J

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


[Tagging] "sym" tag

2018-07-24 Thread José G Moya Y .
Hi!
I've found some places of worship tagged with the undocumented "sym=church"
tag.
It appears to be added from some old software, since the"name" tag in the
same element is truncated to eight characters.

It's surprising to see how these places are being rendered as churches despite
of this tag does not appear in the wiki (and no other tag related with
worship is in the place).

Should I delete the "sym" tag after tagging the building with a more proper
tag?

Yours,
José G. Moya Yangüela
Spain
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Dangerous waterways tagging: hazard?

2018-07-24 Thread Yves
The tag 'hazard' can be found on the whitewater wiki page, so I guess whatever 
tag is found here would be worth mentioned there.
Yves 

Le 24 juillet 2018 12:51:39 GMT+02:00, ael  a écrit :
>On Mon, Jul 23, 2018 at 10:48:05PM +0200, François Lacombe wrote:
>> 
>> As the discussion about intermittent/seasonal/... on waterways goes
>on,
>> there is another thing to map: how waterways banks can be dangerous
>due to
>> sudden rise or lower water level.
>
>The obvious tag is hazard, but for some incomprehensible reason it
>seems
>to be used rather rarely. Perhaps it is not in editor presets?
>
>ael
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging