Re: [Tagging] emergency=control_centre

[Javier Sánchez Portero]

I answer inline to Paul and Markus

El dom., 9 dic. 2018 a las 15:12, Paul Allen ()
escribió:

> On Sun, Dec 9, 2018 at 3:06 PM dktue  wrote:
>
>>
>> I would like to propose a tag for emergency control centers (the place
>> you reach when you call 112 in Europe).
>>
>
> Why?
>
> As far as I know, these are places one contacts via telephone.  They may
> be located far from
> the locality they serve, even though calls from that locality may be
> routed to one particular
> control centre.  Are the ones you are familiar with of a kind where one
> must walk in to report
> an emergency?  Unless they are, it serves no purpose to mark them on a
> map.  Unless, perhaps,
> one is a terrorist intent upon damaging infrastructure.
>
>
I kindly disagree with you. I think this information is important in the
map as is everything related to emergencies. We can distinguish the calling
centre and the centre for coordination for emergency forces and resources.
Usually they are located in the same place. Of course a ordinary person
don't need to know where they are, but for a emergency planner these are
strategic places into the emergencies services that need to be preserved
and defended. Of course the emergency services should have their own maps
and data bases, but I think that is our goal to offer the best possible
geographic information data base for all kind of user and to serve as a
valid alternative to any government user which want to use it. In addition
the terrorist, many other people could need to know the location of such a
place, for example mail and delivery services, taxis, and any one who is
interested in work in such a place or know how the work (school visits). At
least in my country these location are publicly know through the contact
section of their web site. They are also verifiable on the on the ground
features and as such they have place in our database.

El dom., 9 dic. 2018 a las 15:51, Markus ()
escribió:

> office=public-safety_answering_point would probably fit better than
> emergency=*. (In an emergency it might not help much to know where the
> public-safety answering point is located.)
>
> Regards
> Markus
>
>
To join together all emergency related stuff into a key seems to me very
logic and important to reach the goal I described previously. It could be
used office=any as main key but emergency = something should be available
to facilitate searchs and grouping.

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

Re: [Tagging] How to tag named group of named water areas?

[Javier Sánchez Portero]

I'm not arguing about any particular tagging, but I would like to point the
fact that the map you send uses different colours for Three Lakes and for
the named lakes (Chloya and Twin Islands lakes). The lakes have blue labels
denoting that the name is for a water body while the group of lakes is in
black typography. I think it means that the name of the group denotes the
diffuse region where the lakes are placed.

Cheers, Javier

El lun., 8 oct. 2018 a las 12:29, Dave Swarthout ()
escribió:

> Regarding the validity of the name Three Lakes, I think it's very clearly
> correct and as such, suitable for inclusion in OSM. There is a screenshot
> in my Dropbox and also this citation from the Dictionary of Alaska Place
> Names, Orth (1963):
>
> Three Lakes: lakes, 4 mi. SW of Birch Creek
> (locality), 30 mi. SW of Fort Yukon, Yukon
> Flats; 66"13' N, 145"50f W; (map 119).
> Local name obtained in 1956 by USGS.
>
> Screenshot here:
> https://www.dropbox.com/s/idrxsi7m1p2nvze/Three%20Lakes%20Topo.JPG?dl=0
> from USGS Topo overlay
>
> On Mon, Oct 8, 2018 at 6:17 PM Martin Koppenhoefer 
> wrote:
>
>>
>>
>> Am Mo., 8. Okt. 2018 um 13:12 Uhr schrieb Martin Koppenhoefer <
>> dieterdre...@gmail.com>:
>>
>>> A very similar problem are parts of lakes by the way, e.g. look at this
>>> map of the lake of Constance, showing names for parts of the lake:
>>> https://de.wikipedia.org/wiki/Bodensee#/media/File:Bodensee_satellit%2Btext.png
>>> (or maybe the "lake" in this case is a group of lakes as well).
>>>
>>
>>
>> The current solution in this case seems to use "natual=bay" tags: e.g.
>> https://www.openstreetmap.org/relation/74974
>>
>> Cheers,
>> Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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] Tagging suggestions for electricity

[Javier Sánchez Portero]

That was in the past, but now there is a visual editor very easy to use.

El lun., 3 sept. 2018 a las 1:52, Dave Swarthout ()
escribió:

> One of the biggest problems with "creating a proposal" is that the Wiki
> markup language is so painfully tedious I've taken pains to avoid it.
> People always say, "write it up in the Wiki" as though it's similar to
> writing a letter in a word processor. It is not. It's a process I've
> criticized in the past as being very difficult— it's one reason why many
> proposals aren't written up but simply acted upon.
>
> My 2 cents
>
> Dave
>
> On Mon, Sep 3, 2018 at 7:38 AM Warin <61sundow...@gmail.com> wrote:
>
>> On 03/09/18 10:05, Martin Koppenhoefer wrote:
>>
>>
>>
>> sent from a phone
>>
>> On 3. Sep 2018, at 01:42, Warin <61sundow...@gmail.com> wrote:
>>
>> Just one question though: for the wiki page of this do I put "draft" or
>> "proposed" or "de facto" or "in use" for the status?
>>
>>
>> I would not put a status on it.
>>
>> It is not a draft, proposed nor approved.
>> It has no use at the moment, and it is certainly not de facto.
>>
>>
>>
>> if you want to introduce an (also almost) unused tag to the wiki you
>> should create a proposal, it is the established way. You can set the status
>> to draft while you work on it, then formally ask for comments here, it
>> should be all explained there:
>>
>> https://wiki.openstreetmap.org/wiki/Proposal_process
>>
>>
>> That is one way.
>> It is not compulsory to do that.
>> You can simply start to use the tag AND document its use.
>> The problem with tags that have some use but no documentation is that no
>> one really knows what was intended. e.g. landuse=clearing.
>> I have tried to contact the people that used this tag -- no response.
>>
>> Things like the key shop have been introduced without going through a
>> proposal process.
>> If you don't want to go through the proposal process .. then don't.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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] (no subject)

[Javier Sánchez Portero]

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

Re: [Tagging] How to tag small canals?

[Javier Sánchez Portero]

This kind of man-made structure for water transportation is very frequent
in Azores, Madeira, Canary Islands and Mediterranean countries. Please see
https://en.wikipedia.org/wiki/Levada

Now most of them are tagged with waterway=ditch.

As long as I now, they could be used not only for irrigation but also for
drinking. They could be open to air or closed, located on ground, over
(aqueduct) or inside (tunnel). Usual width from 0.2 to 1.0 meters.

El jue., 16 ago. 2018 a las 15:15, Christoph Hormann ()
escribió:

> On Thursday 16 August 2018, SelfishSeahorse wrote:
> > Hello
> >
> > What is the usual (or sensible) way to tag small canals like mill
> > races (example: [^1]) or small irrigation channels (example: [^2]),
> > i.e. the small equivalent of waterway=canal?
>
> A bit of information on current meaning of artificial waterway tags:
>
> waterway=ditch and waterway=drain are largely used without a well
> defined difference between them.  In terms of documented meaning
> waterway=ditch is more for features collecting water while
> waterway=drain is more for features transporting water.  But this is
> not a difference you can find consistently being made in actual
> mapping.  Both tags were invented and are primarily used for waterways
> removing undesirable water.
>
> There is also some minor use of waterway=ditch and waterway=drain for
> smaller natural waterways because it is rendered slightly thinner than
> waterway=stream in the standard style but this is generally accepted to
> be abuse of the tags.
>
> waterway=canal is essentially for all open artificial waterways that are
> not primarily for transporting away undesirable water (which would be
> waterway=ditch or waterway=drain).  However since the standard style
> renders it in a fairly prominent form with a thick line smaller canals
> (like for irrigation purposes) are often tagged differently
> (waterway=ditch, waterway=drain or waterway=stream) despite not
> qualifying as such.  Still waterway=canal is the corrent tagging here,
> nothing except the standard style suggests a lower size limit for
> waterway=canal.
>
> All of this together has its origin in the fact that in the UK and other
> early OSM countries large artificial waterways are almost always for
> navigation and small artificial waterways are almost always for
> transporting away undesirable water.
>
> Long story short: My recommendation would be tagging waterway=canal and
> specifying usage=* and width=*.  This might not look ideal on the map
> but will allow all data users to correctly interpret the data.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Fwd: Missing access value (access=license / authorization?)

[Javier Sánchez Portero]

Hello Szem

No. That way is just the opposite of the intended meaning. It says that
every body need a permit (for example cars) and hikers and riders can
access freely. The previous one was ok. Access=no (or private as someones
suggest) + transportmode=permit

El lun., 13 ago. 2018 20:54, Szem  escribió:

> access=permit, foot=yes, horse=yes, bicycle=yes
> ?
>
>
> - Roads in wildlife conservation areas:
> access= private, motor_vehicle=permit, bicycle=permit, foot=yes
>
> access=permit, foot=yes
> ?
>
>
>
> OK?
>
> Counter:
> In the page of
> https://wiki.openstreetmap.org/wiki/Proposed_features/access%3Dpermit
> the small counter counts only "access=permit" tag, but these roads
> doesn't have this tag.
> Can be converted it to "*=permit" or sg like this? If I change all the
> roads, it will not look.
>
> Wiki:
> When I mentioned the wiki, I meant this page below it:
> https://wiki.openstreetmap.org/wiki/Key:access  -  Access tag values
> Can not you put this access value there?
>
> Thanks,
>
> Szem
>
> 2018.08.12. 23:30 keltezéssel, Graeme Fitzpatrick írta:
>
> On 13 August 2018 at 06:50, Kevin Kenny 
> wrote:
>
>>
>> On Sun, Aug 12, 2018 at 9:48 AM Szem  wrote:
>> > I begun to use the "permit" tag, what is the correct tagging for these
>> categories?
>> >
>> > - Roads found in Waterworks area (You could get permit only for biking
>> and walking, no cars except for their own ones)
>> > access=private, motor_vehicle / vehicle = private ? bicycle=permit,
>> foot=permit, horse=no
>>
>> Sounds right; no need to tag motor_vehicle separately, since 'access'
>> covers all transportation modes that aren't called out separately.
>>
>> > - Roads on the embankments (By any motor vehicle without permission is
>> forbidden, except for their own ones, other access is free)
>> > access= private, motor_vehicle / vehicle =permit ? foot=yes, horse=yes,
>> bicycle=yes,
>>
>> If permission is readily obtainable, then 'permit'. If permission
>> happens on a case-by-case basis, 'private' is probably closer.
>>
>
> In cases when only official vehicles (National Parks, Water supply etc)
> are allowed, I've always called that vehicles=no, working on " *no* – No
> access for the general public."?
>
> > - Roads managed by Hunting Association, wildlife conservation areas
>> (Crossing by any vehicle without permission is forbidden, except for their
>> own ones):
>> > access= private, motor_vehicle / vehicle = permit, foot=yes,
>> horse=permit, bicycle= permit
>>
>> Once again, if it's "access granted if you comply with the
>> formalities", then 'permit', otherwise 'private'.  The Hunting
>> Association one sounds as if it restricts access to its own members?
>> In that case, it's definitely "private."
>
>
> & yes, I'd agree that Members only is "private"
>
> Thanks
>
> Graeme
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] undersea tourist route

[Javier Sánchez Portero]

I think that location=underwater is more exact that surface=water. With the
second I expect to walk over the water like Jesus.

Javier

El mié., 8 ago. 2018 a las 1:13, Warin (<61sundow...@gmail.com>) escribió:

> On 08/08/18 09:01, marc marc wrote:
> > Le 08. 08. 18 à 00:26, Warin a écrit :
> >> A scuba or snorkel route - some concrete drums with a chain between then
> >> and signs for people to follow. Like an under sea path.
> > highway=path + location=underwater ? :)
>
> Humm
>
> highway=path
>
> layer=-1
>
> surface=water
>
>
> ___
> 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] Missing access value (access=license / authorization?)

[Javier Sánchez Portero]

+1 for access=permit
I support it

Regards, Javier

El mar., 7 ago. 2018 20:38, Paul Allen  escribió:

> On Tue, Aug 7, 2018 at 8:26 PM, Szem  wrote:
>
>> Thanks. I have three problems: it's a huge amount of texts :( and I do
>> not speak english so good :(( and I do not understand truly the correlation
>> of this method and writing the wiki :(((
>> So what's the next?
>>
>
> Feed the text through google translate.  Because it's what you were asking
> for.  He used
> "permit" rather than "licence" or "authorization" but he explains why.
> That page is what you wanted to
> write.  Everything has already been done.  Two years ago.  And gone
> nowhere.
>
> There is no point you writing a proposal because that proposal already
> exists.  So try to drum up support for
> that existing proposal or forget about the whole idea.
>
> --
> Paul
>
> ___
> 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] place nodes for continents?

[Javier Sánchez Portero]

El mar., 7 ago. 2018 a las 10:33, Warin (<61sundow...@gmail.com>) escribió:

> But "Officially, there is no centre of Australia." So say the experts.
> Probably because they cannot reach consensus, sounds familiar :)
>

We are extending on the "centre" problem, but there aren't even a consensus
in the number of continents.

https://commons.wikimedia.org/wiki/File:Systemes_de_continents.gif
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] place nodes for continents?

[Javier Sánchez Portero]

Maybe I'm extending the fork, but only a mention to consider. While there
are only 8 uses of place=continent, there are 179996 (whow!) uses of
is_in:continent=* that will be orphaned in that case.

https://taginfo.openstreetmap.org/keys/is_in:continent

El mar., 7 ago. 2018 a las 10:15, Eugene Alvin Villar ()
escribió:

>
>
> On Tuesday, August 7, 2018, Javier Sánchez Portero 
> wrote:
> > The same applies to other place nodes like oceans, seas, natural bays,
> straits, etc.
>
> At the risk of forking this discussion to another topic, I'd like to point
> out that at least for oceans and major seas, bays, and straits, the
> International Hydrographic Organization has defined them as specific
> delimited areas.
>
> For continents, nobody could even agree whether to treat North and South
> America as separate continents or as just one continent named the Americas.
> Not to mention whether to call the smallest continent as Australia,
> Australasia, or Oceania. (And let's not forget the geological debate about
> Zealandia.) On a more general note, are we talking about continent as a
> geopolitical entity (Europe vs. Asia), or as a geological entity (Eurasia)?
>
> I am in favor of removing these continent nodes. They are "simple" and few
> enough that people who make maps and apps can decide how to treat them
> themselves. ___
> 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] place nodes for continents?

[Javier Sánchez Portero]

El mar., 7 ago. 2018 a las 9:33, althio () escribió:

> I agree this position is debatable and finally arbitrary.
>

Hi Althio

Then should we delete this node or abstain to create place nodes for
continents? Or should we give a try to the debate and move to a better
position? The same applies to other place nodes like oceans, seas, natural
bays, straits, etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] place nodes for continents?

[Javier Sánchez Portero]

Hi Frederik

You can find many examples of places that are verifiable by its boundary,
some countries, provinces, municipalities, but most of the names in
geography refers to diffuse places, from towns to the Amazon Forest (cross
link to Wikidata tag thread). Can't we map them in OSM? For such places,
the exact position of the node should not be a matter of conflict and if so
resolve it with consensus as usual here.

Javier


El mar., 7 ago. 2018 a las 9:21, Frederik Ramm ()
escribió:

> Hi,
>
> On 07.08.2018 10:04, Ilya Zverev wrote:
> > It is a strange question, which can be applied to virtually anything in
> > OSM. Potholes — are they useful?
>
> Ok, I'll re-word:
>
> How is a continent node verifiable, especially with regards to its
> position? What is our plan if two people should start edit-warring about
> whether the continent node should be at 51.002, -109.002 (as it
> currently is), or rather at 51,-109 or at 50,-108?
>
> Representing a tree or a pothole with a node is not exact either, but
> it's more or less within the accuracy of our available measurement
> devices. Representing a city with a node is much less accurate, but
> people seem to agree for most cities, placing the city node in the heart
> of the old city, or where the city hall is, or some such.
>
> Do we really want to approximate whole continents with a point, and if
> we do, where is that point to be placed?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=clearing

[Javier Sánchez Portero]

El sáb., 4 ago. 2018 a las 7:29, Martin Koppenhoefer (<
dieterdre...@gmail.com>) escribió:

>
>
> sent from a phone
>
> > On 4. Aug 2018, at 01:43, Warin <61sundow...@gmail.com> wrote:
> >
> > As this is not a 'landuse' but a landcover I think moving it to
> landcover=clearing would be a good first step.
>
>
> -1, “clearing” is neither a landuse nor a landcover.
>
> cheers,
> Martin
>

I agree. If you can't map the full forest as a multipolygon relation, map
the real landuse/landcover/natural areas inside the clearing.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Javier Sánchez Portero]

That sounds right but would not be clearer to use spacename instead of
underscore? Like maxspeed:mph=25
That way you have to deal with main keys instead of split them into one key
per unit.

El lun., 30 jul. 2018 0:22, Martin Koppenhoefer 
escribió:

>
>
> sent from a phone
>
> > On 29. Jul 2018, at 09:57, Javier Sánchez Portero 
> wrote:
> >
> > To avoid problems when querying, in case of explicitly add units, I
> would prefer to use a separate tag like maxspeed:units=mph, for example.
>
>
> spreading the information over 2 tags creates another point of possible
> failure: units and tag value getting out of sync.
>
> Moving the unit into the key would work better in some way: height_m=3
> maxspeed_mph=25
> It would enable differing values in different units, but at least these
> would be evidently wrong (e.g maxspeed_kph=30 and ...mph=25 on the same
> object), and of course you shouldn’t add both anyway (unless they would
> both be legally correct)
>
> cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Javier Sánchez Portero]

To avoid problems when querying, in case of explicitly add units, I would
prefer to use a separate tag like maxspeed:units=mph, for example.

Javier

El sáb., 28 jul. 2018 10:30, Mark Wagner  escribió:

> On Fri, 27 Jul 2018 22:33:10 +0200
> François Lacombe  wrote:
>
> > Well okay
> > Given problem is how can we query maxspeed like :
> > [Maxspeed>25] ?
> >
>
> Which situation do we want to optimize for?  The rare case, or the
> common case?
>
> It's common to want to document legal restrictions such as "speed limit
> 25 miles per hour", "no trucks over 2.5 meters tall", or "maximum
> weight 3500 kilograms".  It's rare to want to query ranges of speeds,
> heights, or weights, particularly without regard to the units in use in
> a given country.
>
> We should make it easy for people to enter and interpret these legal
> restrictions, and if it means query software gets a bit more
> complicated, so be it.  For every person who wants to find roads
> worldwide with speed limits greater than 25 km/h, there are probably
> a thousand who don't want to deal with making sure the rounding is
> correct when displaying US speed limits in miles per hour.
>
> --
> Mark
>
> ___
> 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] Missing access value (access=license / authorization?)

[Javier Sánchez Portero]

What's about access=license? For me it has the same meaning. It has 245
uses and is documented
https://wiki.openstreetmap.org/wiki/Tag:access%3Dlicense.

Javier


2018-07-27 6:22 GMT+01:00 Mateusz Konieczny :

> 27. Lipiec 2018 03:38 od t...@fitchdesign.com:
>
>
> My take is to toss an idea/problem into the list and see if there is
> anything that comes back in the first few days that alters your opinion on
> how to tag. Sometimes there are good suggestions that can improve your
> thinking on how something should be tagged so it is worth submitting.
>
>
> Tagging mailing list is not a decision making comiite. It is a place to
> get a feedback.
>
>
> I remember some cases with "this is a bad idea" consensus, for some really
> poor ideas.
>
> ___
> 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] waterway=fish_pass consistency

[Javier Sánchez Portero]

Actually I'm not familiar with fish passes. Could any one provide more
sample images? And one question: Could a fish pass look like a short and
very narrow canal like the images in this pages?

https://en.wikipedia.org/wiki/Levada
https://es.wikipedia.org/wiki/Acequia

2018-07-19 9:15 GMT+01:00 Warin <61sundow...@gmail.com>:

> The 'fish passes' I am familiar with are all man made, they provide fish a
> way around weirs, dams and locks.
> They certainly are not intended for human transportation and should not
> provide a lot of water flow.
> They are different from spillways, canals and other man made waterways,
> they are not a sub class to them.
> If they are not to be considered part of the waterway key then possibly
> they can be added to the key man_made.
>
>
>  On 19/07/18 17:57, Javier Sánchez Portero wrote:
>
> Hello
>
> I personally prefer a few main values in the waterway to define the
> general cases and subtags for specific cases like this, of the type of
> usage = fiss_pass. If I am in front of an infrastructure of this type,
> its physical characteristics will allow me to distinguish if it is a
> channel, ditch or brook. If it was built for the purpose of fish passing
> it is a separate issue. Are a fish_pass different in nature to any other
> waterway? Waterway different in it's construction nature could be used as a
> fish_pass? If the answers to this questions are no and yes, put the
> fish_pass value apart of the main waterway key. This form seems simpler
> and more versatile to me.
>
> By the way: in the table of values added to the wiki there is a strange
> blank gap between the blue cells of ditch/brook and pressurised. Also the
> culvert cell is misaligned with respect to the cave cell and others. Is
> this intentional and has a meaning or an error when constructing the table
> that can be corrected?
>
> Regards, Javier
>
> 2018-07-19 8:30 GMT+01:00 Mateusz Konieczny :
>
>> In case of waterway=fish_pass I think that a new waterway is OK as
>>
>> - it is drastically different from other defined waterways
>> - is not a navigable waterway
>> - is not redefining already mapped objects
>>
>> 17. Lipiec 2018 23:04 od fl.infosrese...@gmail.com:
>>
>>
>> Hi all,
>>
>> A discussion has recently started about waterway=fish_pass here :
>> https://wiki.openstreetmap.org/wiki/Talk:Tag:waterway%3Dfish_pass
>>
>> While writing https://wiki.openstreetmap.org
>> /wiki/Proposed_features/Hydropower_water_supplies it was asked to not
>> clutter waterway=* with spillway since it was a specific usage of a man
>> made canal.
>> Such ideas lead to separate waterway nature, usage and sometimes
>> supporting infrastructure to get a tagging model with 3 different
>> corresponding keys.
>> A comprehensive table of waterways natures has been set here :
>> https://wiki.openstreetmap.org/wiki/Key:waterway#Values
>>
>> May it be great to consider usage=fish_pass with waterway=* (canal,
>> presumably) for sake of consistency?
>>
>> Feel free to read and comment on the Talk page
>>
>> All the best
>>
>> François
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=fish_pass consistency

[Javier Sánchez Portero]

Hello

I personally prefer a few main values in the waterway to define the general
cases and subtags for specific cases like this, of the type of usage =
fiss_pass. If I am in front of an infrastructure of this type, its physical
characteristics will allow me to distinguish if it is a channel, ditch or
brook. If it was built for the purpose of fish passing it is a separate
issue. Are a fish_pass different in nature to any other waterway? Waterway
different in it's construction nature could be used as a fish_pass? If the
answers to this questions are no and yes, put the fish_pass value apart of
the main waterway key. This form seems simpler and more versatile to me.

By the way: in the table of values added to the wiki there is a strange
blank gap between the blue cells of ditch/brook and pressurised. Also the
culvert cell is misaligned with respect to the cave cell and others. Is
this intentional and has a meaning or an error when constructing the table
that can be corrected?

Regards, Javier

2018-07-19 8:30 GMT+01:00 Mateusz Konieczny :

> In case of waterway=fish_pass I think that a new waterway is OK as
>
> - it is drastically different from other defined waterways
> - is not a navigable waterway
> - is not redefining already mapped objects
>
> 17. Lipiec 2018 23:04 od fl.infosrese...@gmail.com:
>
>
> Hi all,
>
> A discussion has recently started about waterway=fish_pass here :
> https://wiki.openstreetmap.org/wiki/Talk:Tag:waterway%3Dfish_pass
>
> While writing https://wiki.openstreetmap.org/wiki/Proposed_features/
> Hydropower_water_supplies it was asked to not clutter waterway=* with
> spillway since it was a specific usage of a man made canal.
> Such ideas lead to separate waterway nature, usage and sometimes
> supporting infrastructure to get a tagging model with 3 different
> corresponding keys.
> A comprehensive table of waterways natures has been set here :
> https://wiki.openstreetmap.org/wiki/Key:waterway#Values
>
> May it be great to consider usage=fish_pass with waterway=* (canal,
> presumably) for sake of consistency?
>
> Feel free to read and comment on the Talk page
>
> 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] Sample tagging for highways with no lane markings

[Javier Sánchez Portero]

Hi Jose

The facts of be able (or not) to overtake and drive in the middle (as Paul
says) are interesting but not necessary relevant for the discussion (IMO).

Anyway, for your example of the LR-333 road, most of the time it isn't
enough wide for two cars to pass comfortably (see here
https://goo.gl/maps/6PC2Wfkfw7A2 like the van has to put the wheel in the
border line and probably stop). In this case, lanes=1, oneway=no is the
best tagging. Would you tag the same in GC-210 road?:
https://www.mapillary.com/map/im/v_G65XwwVnjf0u3i0RxRqA

What I suggest is that the tagging division=no is correct for examples like
this.

2018-05-23 7:07 GMT+01:00 José G Moya Y. :

> @Martin:I don't want to be a troll, but I feel there is some inconsistence
> between answers in this thread and answers in cycle:lanes last week.
>
> @javier, yopaseopor: I don't drive, but I think you can overtake a Guardia
> Civil car in two-way roads where there are one lane.
> The cycle:lane thread told much about what is and isn't to be marked as
> lane, and one case came to my mind.
>  Think of the road from Villoslada de Cameros, Rioja, Spain and Montenegro
> de Cameros, Soria, SameCountry. Rioja side is a two-fake-lanes road ("line
> between lanes just mark centre of road") while Soria side is a two way one
> lane road (markings at sides of the road). The width of the road is the
> same.
>
>
>
> P.D. Enviado desde un móvil (celular). Disculpe las erratas. No veo bien
> la pantalla...
>
> El 23/5/2018 7:16,  escribió:
>
>
>
>
>
> *From:* yo paseopor 
> *Sent:* Wednesday, 23 May 2018 04:11
>
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] Sample tagging for highways with no lane markings
>
>
>
> oneway=no
>
> lanes=1
>
> https://www.mapillary.com/map/im/jYQQwOGMPC6imwyGhMHMCg
>
>
>
>
>
> I would consider that wrong.
>
>
>
> lanes=1
>
> oneway=no
>
>
>
> is a road that is so narrow that opposing traffic can only pass by slowing
> down and making use of shoulder/verge to pass each other. Or maybe even has
> the need to look for a https://wiki.openstreetmap.
> org/wiki/Tag:highway=passing_place to be able to pass each other (like
> the example image shown on that page).
>
>
>
> What your image above shows is pretty clearly a lanes=2, which you can see
> very well by just following the street a few meters:
>
>
>
> https://www.mapillary.com/map/im/6QXgHLK26FTMlmovwuaxfg
>
>
>
> as you can see, there are clear road markings establishing two lanes.
>
>
>
>
>
> Here is an example of the roads I mean that should be tagged with
>
>
>
> lanes=2
>
> divider=no
>
> (oneway=no is normally implicit, so no need to tag it when there is no
> reason to wrongly assume a road should be oneway)
>
>
>
> https://www.mapillary.com/map/im/KQjnvNHHcOLKZj2P4pB2WQ
>
>
>
> You can see that the roads generally have no marked lanes, but at the
> T-intersection there are markings that make it clear the road is intended
> to be a two lane road.
>
>
>
> Cheers,
>
> Thorsten
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Sample tagging for highways with no lane markings

[Javier Sánchez Portero]

I'm not completely sure of what you want tou express. When you say "a
oneway one-wide-lane", I think you refers to a oneway=yes, lanes=1 (correct
me if not). I'm referring to a two way road (oneway=no) with enough width
for two approaching cars to pass each other without having to slow down or
use the shoulder.

In this kind of way, having enough space) you could leagally overtake any
vehicle if there isn't a restriction sign, even if it's a police one. I
have many examples of this around.

Regards, Javier

El mar., 22 may. 2018 19:31, yo paseopor  escribió:

> Javier, I don't know if it has enough sense to use a new tag to tag
> something we have already tagged or not. But try it in Spain, overtake a
> Guardia Civil de tráfico car or motorbike in a oneway one-wide-lane and
> expect it ;)
>
> Salut i marques viales
> 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

Re: [Tagging] Sample tagging for highways with no lane markings

[Javier Sánchez Portero]

I agree with the solution mentioned by Thorsten. The keys oneway=no +
[lanes=2] + division=no have much more sense to me than tagging lanes=1 +
oneway=no for this kind of highway (just the same width that a two lanes
way but without division).

A proper value could serve to indicate also that the division was present
once ago but actually are blured, as Martin suggested.

I would like a proposal for the division key and a clarification in they
key lanes wiki.

Cheers, Javier


El mar., 22 may. 2018 18:46,  escribió:

> Personally, I tend to tag roads that are wide enough for 2 lanes (two cars
> can pass each other without noticeably slowing down) and which are clearly
> meant to be two lane (one lane each direction) roads with:
>
> lanes=2
> divider=no
>
> Yes, I know that is in violation of the strict reading of the wiki, but I
> feel it makes sense, and as far as I can determine, tagging roads that are
> meant to have two lanes with lanes=2 even in the absence of such road
> markings seems to be pretty widespread practice. (The use of the divider
> tag isn't very widespread, but again, I feel it makes sense in this
> context.)
>
> Cheers,
> Thorsten
>
> > -Original Message-
> > From: Tod Fitch 
> > Sent: Wednesday, 23 May 2018 01:18
> > To: Tag discussion, strategy and related tools
> > 
> > Subject: [Tagging] Sample tagging for highways with no lane
> > markings
> >
> > In reviewing the wiki in preparation to fixing some of my older
> > mapping, it seems there is an inconsistency in how to tag a road
> > that is wide enough to two lanes of traffic but is lacking lane
> > striping.
> >
> > In the lanes description [1] it says "the lanes=* key should be
> > used to specify the total number of marked lanes of a road." But in
> > the out of town highway tagging sample page [2] with a photo
> > described as "smaller road, maybe tertiary with appropriate
> > administrative status" it shows a lane count on a road with no
> > markings.
> >
> > Am I correct in believing that the example photo should have its
> > tagging changed, dropping the lanes=2 and adding a width tag (if
> > the width is known or can be reasonably estimated)?
> >
> > My current interest is in fixing the tagging for residential roads
> > that are wide enough for bi-directional traffic with legal parallel
> > parking but have no markings on the pavement. I don't see a exact
> > match to that in either the urban [3] or rural highway [2] tagging
> > example pages.
> >
> > To use the street I live on as an example, am I correct that a
> > residential road with bidirectional traffic and parallel parking
> > with no markings should be tagged as:
> >
> > highway=residential
> > surface=asphalt
> > parking:lane:both=parallel
> > width=40’0"
> > maxspeed=25 mph
> >
> > If, and only if, a center strip is added then lanes=2 should be
> > added. (I actually measured the width in this case but for hope to
> > be able to use the measurement tool on aerial imagery in JOSM for
> > most cases).
> >
> > Is my current understanding correct? If so, I will update the wiki
> > pages for both the urban and rural highway tagging examples to
> > reflect that and will take some photos of the roads in my area to
> > make additional examples.
> >
> >
> > [1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
> > [2]
> > https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/out_of_
> > town
> > [3]
> > https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-11 14:04 GMT+01:00 Martin Koppenhoefer <dieterdre...@gmail.com>:

> sent from a phone
>
> > On 11. May 2018, at 14:35, Javier Sánchez Portero <javiers...@gmail.com>
> wrote:
> >
> > similar for the other two streets. With the proposed relation, I would
> create a relation with this tags
> >
> > type=address
> > addr:housenumber=1-25
> > addr:postcode=10018
> > addr:street=West 33rd Street
>
>
> I would consider not adding the address tags to the relation because
>
a) you could have features with several postcodes (imagine entrances on
> different streets)
>

Then you will have different relations, one per entrance.


> b) addr:housenumber=1-25 is not telling you which housenumbers it contains
> (better would be a list of all housenumbers)
>

It tells you what you find labelled in the entrance, what you can check on
place. If you have some features with individual housenumbers use the
addresses relation to avoid repeat the common tags and you can form the
(probably incomplete) list of house numbers for that entrance from the
addr:housenumber present in the members. If you only look at the entrance
and see "1-25" you can't know if it refers to 1,3,5,...,25 or 1,2,3,...,25.
In this case, if you don't have features inside that repeat partially or
fully the address you don't need the relation. Put the tags in the entrance
and done.


> c) it is duplicating the addresses with respect to the individual plaques
>

There is no duplicate. What I want to express is that the common addr:*
tags of the features with that address and the entrance/plaque will be in
the relation and NOT in the members. The members will have the addr:tags
that differs (usually none, in some cases addr:housenumber maybe addr:unit
or addr:door). Refining a bit the example the addr:housenumber=1-25 could
be in the entrance node instead of the address relation (easier for the
renderer).


> The address should be inherited from the members
>

This don't resolve the inconsistency problem. See the three different
postalcode values for the number 350 of the 5th Avenue in the query below.

https://overpass-turbo.eu/s/yJ0

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

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-11 10:53 GMT+01:00 Martin Koppenhoefer :

> May be it would be good to have a relation to keep in only one place an
>> address and link there the affected elements: entrances, buildings, POI's
>> and area for this address. This would be necessary only for some cases like
>> a building with many addresses/POI's. The simplest use cases would be done
>> as usual. Looking the history of the associated_street and street relation
>> may be this idea is too controversial so opinions are appreciated.
>>
>
> We could add relations to model which addresses belong to which POI (and
> this would also work for multiple addresses for one POI), but it really
> isn't the same as stating the address the POI is _using_, because it might
> "have" several entrances (and windows) with addresses but use only part of
> them (i.e. we would need roles to say which addresses lead to the POI, and
> which is the "official" address of it, the one on it's website, business
> register, receipt, advertising etc.). This would be a lot of relations for
> something that can be easily modelled by adding the address property as
> used by the POI to the object and be done. From the relation you will not
> be able to construct actual address strings like "Foo Street 33-35" because
> this could mean things like "33A, 33B, 33C, 35" or "33, 34, 35", or "33,
> 35", etc.
>
> Even for simple cases, I would like to tag whether they are representing
> an entrance (entrance=yes/main or barrier=gate) or not (entrance=no, these
> are either windows or former entrances now closed or potential future
> entrances, and on top of this, situations that shouldn't get a housenumber
> according to current legislation, but already have one). I am also
> interested in adding details like level=1 (I see the absence of level as
> level=0 and the default, but add level=1 for first floor entrances. This is
> useful to understand situations where the sequence of numbers seem "odd" on
> the map, but actually are accurate).
>
> Cheers,
> Martin
>


The kind of relation I have in mind is a type=address relation with the
usual tags for an address (addr:*). A quick sketch of the members could be

* role=plaque, cardinality=0-1 for a node near where the house number
plaque is located. This member will be present only if exists a plaque with
the number. This node could have the entrance=*, barrier=*, door=*,
wheelchair=*, etc. tags if the plaque is associated to an entrance or not,
like in [1]
* role=to define, cardinality=0-many for the features related to this
address. This could be buildings, features like shops, a landuse area, etc.

Generally the current schema will still be used. The address relation will
be necessary only for this:

* If you have many features associated to an address and you can't draw the
actual limits of a enclosing area to put the address or you want to use a
node for the reasons mentioned. Then we will have one relation.
* If you have many addresses for a feature. Then you will have as many
relations as plaques found. The case of the official address you mention
could be stated in the role.

Lets see a real world example, like the Empire State Building [2]. We have
one address in the building footprint and many others in nodes you can see
inside the footprint (and even two of them outside, making it hard to
associate them). The 350 of 5th Avenue it's repeated in many POI's. This
give to inconsistency: **there are three different addr:postcode values**.
It would be solved moving the addr:* tags to one relation with the POI's as
members.

The building have the number 2 in the West 34th Street, with the next
building having the 22 housenumber. Similar for the West 33rd Street, and
in the 5th Avenue the building is between 326 and 362 housenumbers, so I
think that the building have many housenumbers associated in each street.
Only to clarify the example, we can confirm this at [3], this entrance give
access to housenumbers 1 to 25. With the actual scheme, to improve this I
would move the address node [4] to this point with the entrance=main tag
and using addr:housenumber=1-25 and similar for the other two streets. With
the proposed relation, I would create a relation with this tags

type=address
addr:housenumber=1-25
addr:postcode=10018
addr:street=West 33rd Street

With the entrance, building and POI's (when present) as members. Each POI
could have tagged their individual addr:housenumber=n. The consumer will
get the full address for a POI from:

* The addr:housenumber of it (only present the addr:* tags that differs
from the parent address relation
* The addr:* tags of the parent address relations
* Can complete it with the name or addr:housename of the building if it's
only one.

The final number of relations needed will be one for entrance with plaque.
I think it could be possible three, one for each street.

[1] https://goo.gl/maps/yTDHWbVuRWF2
[2] https://www.openstreetmap.org/way/34633854
[3] 

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-09 22:41 GMT+01:00 Martin Koppenhoefer :

> Is there a way to indicate a housenumber is a feature, vs. a property?
>
> In many places, housenumbers refer to buildings or sites, and you might
> omit addresses on contained features (because you can hope for inheritance
> from the containing address object). Unfortunately the situation in Italy
> is a bit different in this regard, as housenumbers are assigned to
> entrances (either site or building) and even potential entrances.
>
> This leads to the common situation that the same housenumber appears
> multiple times (on the entrance as a feature and on the contained features
> like businesses as an address property). Businesses being accessible
> through different housenumbers is not a rare exception but rather common.
> They deal with it differently: while some list all or a bunch of the
> numbers as their address, others choose one (often but not always the main
> entrance).
>
> If you map the POI as an area, you might often be able to represent the
> numbers that are part of the area (unless they are not on the ground floor,
> or the building is not directly on the street hence the number is typically
> at a gate on the site perimeter). Still most people (including myself)
> don’t map small businesses in shared buildings as areas, so duplicated
> address information is common.
>
> Some of my fellow mappers are dealing with this by adding the poi
> information to the entrance, but this is unsatisfactory because of several
> reasons:
>
> - it can only deal with cases where one number is for one business, it
> doesn’t work for multiple entrances or numbers and it doesn’t work for
> shared entrances (one number for several pois)
>
> - it is topologically wrong (the poi is not on the perimeter, neither
> inside nor outside, it is inside). The poi is also not the same as the
> entrance, if you add entrance=* it is an entrance and should not get other
> tags for a different object (the poi) like name etc.
>
> Thoughts?
>
> Cheers,
> Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


In Spain, there isn't a relation one-to-one between entrances and
addresses, but it's pretty common to have a building with more than one
address. They may be a building with access from different streets or a
building (maybe with a housename) and some consecutive numbers (even or
odd) in the same street. For this reason many people (me included) are
mapping addresses as nodes pinpointing the house number plaques found at
street level. Most of the time they are associated to an entrance, but not
always. We put a node in the building footprint (if it's only one) or in
the parcel limit when many buildings share the address and there are a
visible barrier as delimiter. I think that this method reflect best the
reality, gather more information and is best for micromapping.

I don't like the duplication of information, prone to be inconsistent
between the address in the entrance and in the multiple POI's that could be
inside the building or area. May be it would be good to have a relation to
keep in only one place an address and link there the affected elements:
entrances, buildings, POI's and area for this address. This would be
necessary only for some cases like a building with many addresses/POI's.
The simplest use cases would be done as usual. Looking the history of the
associated_street and street relation may be this idea is too controversial
so opinions are appreciated.

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

Re: [Tagging] Difference between building=grandstand and leisure=bleachers

[Javier Sánchez Portero]

2018-04-04 9:30 GMT+01:00 Philip Barnes <p...@trigpoint.me.uk>:

>
>
> On 4 April 2018 08:44:08 BST, "Javier Sánchez Portero" <
> javiers...@gmail.com> wrote:
> Bleachers are open structures, usually associated with American High
> School and University sports.
>
> I understand that the
> >tag
> >leisure=bleachers is discouraged for not being British English.
> Why? As a native speaker of British English I can see nothing wrong with
> Bleachers, there is no word in BE to describe these as they are not
> suitable for a Northern European climate.
>
> I think the key difference is a building v open frame structure.
>
> Phil (trigpoint)
>
>
I'm not a native speaker, but that is what says the red warning in

https://wiki.openstreetmap.org/wiki/Tag:leisure=bleachers

The open frame structure type is very common where I live (28ºN) and I
suppose that in many other parts of the world. In this definition

https://www.merriam-webster.com/dictionary/grandstand

It says a structure with seats without implying if it's a building or an
open frame. Maybe the correct use could be building=grandstand and
leisure=grandstand deprecating leisure=bleacher

Otherwise, the warning should be removed from leisure=bleacher because it
discourages to use this tag.

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

Re: [Tagging] Difference between building=grandstand and leisure=bleachers

[Javier Sánchez Portero]

The definition of the tag building=grandstand says that they are "usually"
roofed, this implies that not always are roofed. I understand that the tag
leisure=bleachers is discouraged for not being British English.

Javier

2018-04-04 8:27 GMT+01:00 Tomasz Wójcik :

> Reading descriptions of these two tags:
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dgrandstand
>
> https://wiki.openstreetmap.org/wiki/Tag:leisure=bleachers
>
> the conclusion is that grandstand have a roof above and bleachers doesn't.
> Do I understand it correctly? If yes, I want to emphasize it in the Wiki
> documentaton.
>
> ___
> 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] Attendant on amenity=fuel

[Javier Sánchez Portero]

2018-03-30 11:37 GMT+01:00 :

> Based on the information provided here:
>
>
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Service
>
>
>
> and what was stated in previous posts on the mailing list, I would guess
> that the correct tags would be:
>
>
>
> Only serviced by attendant:
>
>
>
> self_service=no
>
> full_service=yes
>
>
>
> Self service always available, attended only during the day:
>
>
>
> self_service=yes
>
> full_service=no
>
> full_service:conditional=yes @ 06:00-18:00
>
>
>
> (following the recommendation in the wiki to specify the default value
> explicitly when it’s not obvious)
>
>
>
> Self service only available at night when no attendant is present:
>
>
>
> self_service=yes
>
> full_service:conditional=no @ 06:00-18:00
>
> full_service=no
>
> full_service:conditional=yes @ 06:00-18:00
>
>
>
>
>
> The expectation for the default values of self_serivce and full_service
> will probably vary greatly from location to location, so it’s probably best
> to always explicitly specify both to take the guessing out of it.
>
>
>
>
>
>
>
Hello. Good abstract.

I have added this to

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Attendant on amenity=fuel

[Javier Sánchez Portero]

El vie., 30 mar. 2018 8:54,  escribió:

> While it has never been used before, the logical key to me would be
> self_service:conditional following the usual rules for conditional keys.
>
I agree. It will require only a minor change in the conditional
restrictions wiki.

Javier

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

Re: [Tagging] Attendant on amenity=fuel

[Javier Sánchez Portero]

El vie., 30 mar. 2018 8:13, Stephan Knauss <o...@stephans-server.de>
escribió:

> Hello Dave,
>
> As this is a thing country specific, people typically expect the norm. So
> no need to tag this explicitly.
>
> Question is how to tag it.
>
> self_service sounds like the right key to tag exceptions from the norm. It
> can also be used with the same meaning for example for car wash. These come
> as well as stations where you insert coins in a machine to get pressurized
> water or with staff doing the car wash for you, eg while you are shopping
> in the supermarket.
>
> Stephan
>
>
> On March 30, 2018 12:08:44 PM GMT+07:00, Dave Swarthout <
> daveswarth...@gmail.com> wrote:
>>
>> In the U.S. almost all service stations are unattended these days. The
>> pumps are automated and accept only credit cards. Persons needing to pay
>> cash have to go to a separate office or shop to pay. Oregon used to be the
>> only state I visit regularly in which customers were not allowed to fuel
>> their vehicles. Attendants did everything; filled the tank, cleaned the
>> windshield, checked the oil. IIRC, that law just recently changed.
>>
>> Dave
>>
>> On Fri, Mar 30, 2018 at 7:44 AM, Stephan Knauss <o...@stephans-server.de>
>> wrote:
>>
>>> It is the norm that you have an attendant coming and filling up the tank
>>> for you.
>>>
>>> Some places will always clean the windscreen while waiting for the
>>> refill, but don't this is something to tag special as you can always ask
>>> the attendant to clean them.
>>>
>>> In some countries it differs, so I suggest to tag things not following
>>> the norm of the country.
>>>
>>> Stephan
>>>
>>>
>>> On March 29, 2018 5:58:51 PM GMT+07:00, "Javier Sánchez Portero" <
>>> javiers...@gmail.com> wrote:
>>>>
>>>> Sorry, english is not my first languange and I'm not sure of have been
>>>> used the correct word in the subject. I'm looking for a key to denote if
>>>> you have to refuel by your self or not. I meant if the station operates on
>>>> self service mode.
>>>>
>>>> Didn't found nothing in the wiki or taginfo.
>>>>
>>>> I'm confused also about the use of Key:tenant. The description in the
>>>> wiki is to short for a non native English speaker. Could any one give me
>>>> further details?
>>>>
>>>> Thank you, Javier.
>>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/taggin
> <https://lists.openstreetmap.org/listinfo/tagging>g


In some countries the norm is to fill the tank by self service, in other
with attendants, but in many you can find both classes of stations so there
aren't a default value there.

I think this is important for disabled drivers to have to go down the car
to fill or not.

Javier

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

Re: [Tagging] Attendant on amenity=fuel

[Javier Sánchez Portero]

2018-03-29 15:22 GMT+01:00 Javier Sánchez Portero <javiers...@gmail.com>:

> 2018-03-29 13:14 GMT+01:00 Michal Fabík <michal.fa...@gmail.com>:
>
>> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
>> <javiers...@gmail.com> wrote:
>> > Sorry, english is not my first languange and I'm not sure of have been
>> used
>> > the correct word in the subject. I'm looking for a key to denote if you
>> have
>> > to refuel by your self or not. I meant if the station operates on self
>> > service mode.
>> >
>> > Didn't found nothing in the wiki or taginfo.
>> >
>> > I'm confused also about the use of Key:tenant. The description in the
>> wiki
>> > is to short for a non native English speaker. Could any one give me
>> further
>> > details?
>> >
>> > Thank you, Javier.
>>
>> Hi,
>> I can't really tell what the tenant tag is intended for either. In any
>> case, there's the tag self_service:
>> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
>> attendant is the right word.)
>>
>> --
>> Michal Fabík
>>
>
> Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't
> see it. Thank you.
>
>
BTW. How would you tag if the station usually have attendants but operates
in self service mode in nightly hours. I think in the conditional postfix,
like this:

self_service:conditional = yes @ (22:00-06:00)

With no uses in taginfo. An alternative is opening_hours:self_service=*
with only two uses.

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

Re: [Tagging] Attendant on amenity=fuel

[Javier Sánchez Portero]

Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't see
it. Thank you.

2018-03-29 13:14 GMT+01:00 Michal Fabík <michal.fa...@gmail.com>:

> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
> <javiers...@gmail.com> wrote:
> > Sorry, english is not my first languange and I'm not sure of have been
> used
> > the correct word in the subject. I'm looking for a key to denote if you
> have
> > to refuel by your self or not. I meant if the station operates on self
> > service mode.
> >
> > Didn't found nothing in the wiki or taginfo.
> >
> > I'm confused also about the use of Key:tenant. The description in the
> wiki
> > is to short for a non native English speaker. Could any one give me
> further
> > details?
> >
> > Thank you, Javier.
>
> Hi,
> I can't really tell what the tenant tag is intended for either. In any
> case, there's the tag self_service:
> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
> attendant is the right word.)
>
> --
> Michal Fabík
>
> ___
> 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] Attendant on amenity=fuel

[Javier Sánchez Portero]

Sorry, english is not my first languange and I'm not sure of have been used
the correct word in the subject. I'm looking for a key to denote if you
have to refuel by your self or not. I meant if the station operates on self
service mode.

Didn't found nothing in the wiki or taginfo.

I'm confused also about the use of Key:tenant. The description in the wiki
is to short for a non native English speaker. Could any one give me further
details?

Thank you, Javier.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag this area

[Javier Sánchez Portero]

I would tag the entire place between buildings as place=square, the flat
surfaces as highway=pedestrian+area=yes, the steps as area steps [1] and
the bleachers as leisure=bleachers.

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps

Javier

El 26 ene. 2018 22:36, "OSMDoudou" <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> escribió:

> Hello,
>
> I can't find how to properly tag this place. [1]
>
> No name pops to mind to represent its purpose: forum, amphitheatre,
> pedestrian, speakers corner, etc. don't correspond to suitable tags.
>
> I see a "circle area made of steps where you can sit and meet people", but
> that won't make a good tag... :-)
>
> What do you see there ? How would you tag it ?
>
> Thx.
>
> [1] https://goo.gl/maps/toZ8QvVUB7w
>
>
>
> ___
> 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] Surface value for portuguese pavement

[Javier Sánchez Portero]

El 15 ene. 2018 8:51, "Martin Koppenhoefer" 
escribió:



2018-01-15 8:54 GMT+01:00 OSMDoudou <19b350d2-b1b3-4edb-ad96-
288ea1238...@gmx.com>:

> generally a "painting". I'd rather subtype the surface value to something
> specific like paving_stones=portugese_pavement
>

+1

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

Re: [Tagging] tagging for decaying features

[Javier Sánchez Portero]

2018-01-04 3:05 GMT+00:00 Kevin Kenny :

> On Wed, Jan 3, 2018 at 9:52 PM, Kevin Kenny 
> wrote:
>
>> By contrast, adding 'historic' and adjusting tagging to current use
>> is already a common practice among those who fix repurposed
>> features from the GNIS import. I didn't invent it.
>>
>>
> Oh, and I oughtn't have needed to, but I just checked, and at least
> one of the buildings in question is on the National Register of Historic
> Places.  I'm guessing that in itself will not satisfy Warin as to its
> 'historic' nature, but I'm not sure what authority or combination of
> authorities would.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
Hello

As it is included in a register for historic place, I suggest to use the
Key:heritage [1]. Where I live, the heritage is defined by law as any thing
with *historical*, architectural, artistic, archaeological, ethnographic,
palaeontological, scientific or technical interest.

building=detached
heritage:building=school

[1] https://wiki.openstreetmap.org/wiki/Key:heritage
Regards, Javier
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Would any one support a proposal for a new tag building:part:levels=* to
separate the levels of the building from the part as in this case:

way1 {building=residential, building:part=yes, building:levels=4,
building:part:levels=3}
way2 {building:part=yes, building:levels=4}
way2 is inside way1

This will be needed only using horizontal slices model in buildings with
nested parts.

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

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Hello Tobias and Cristian

2017-08-18 17:41 GMT+01:00 Tobias Knerr :

> On 18.08.2017 10:01, Tom Pfeifer wrote:
> > If e.g. the lower floors of the apartment building is wider than the
> > upper floors, you can tag the outline with both, building=apartments and
> > building:part=yes and the appropriate 3D-properties, and the narrower
> > upper floors with building:part=yes and 3D-properties, but without
> > building=*.
>
> It's not a good idea to use building and building:part tags on the same
> way. Doing so typically gives incorrect information to data consumers,
> because the number of levels for the building as a whole is not the same
> as the number of levels for the building part.
>
> In your example, the building part for the lower levels would be tagged:
>
> building:apartments
> + building:part = yes
> + building:levels = 
>

But in the other case, I end up with this:

way1: building = apartments + building:levels = 4
way2: building:part = yes + building:levels = 3
way3: building:part = yes + building:levels = 4
way1 == way2
way3 is inside way1

Josm validation will raises a warning for duplicated ways (way1 and way2).
If I use the open ways + MP relations schema mentioned by Christian, the
situation is almost the same. I will end up with three MP relations instead
of closed ways and Josm validation will raises a warning for relations with
the same members.


> And as you said, one important function of the building outline is
> backwards compatibility for non-3D-applications. Such an application
> will conclude that this building has  levels,
> which is not the case.
>
> Tobias
>

I accept this, although is not clearly expressed in
http://wiki.openstreetmap.org/wiki/Key:building:levels
Does everyone agree that building:levels refers to the maximum number of
building levels?

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

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

2017-08-18 9:01 GMT+01:00 Tom Pfeifer <t.pfei...@computer.org>:

> On 18.08.2017 02:30, Clifford Snow wrote:
>
>> On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero <
>> javiers...@gmail.com <mailto:javiers...@gmail.com>> wrote:
>> * In the wiki [1] says that the outline should be tagged with
>> building:levels and height, but
>> this, if the parts cover the whole outline, is a duplication since
>> these tags will always be in
>> some of the parts. Could I delete the part(s) whose labels match
>> those of the outline?
>>
>> If you use a multipolygon, then the multipolygon would contain the levels
>> and height.
>>
>
> The building outline represents the "footprint" of the building on the
> ground, and provides all non-3D properties such as building type (e.g.
> building=apartments), address, overall height, etc.
> Thus it provides backward compatibility for a data consumer who does not
> want to evaluate building:part.
>
> If e.g. the lower floors of the apartment building is wider than the upper
> floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower upper
> floors with building:part=yes and 3D-properties, but without building=*.
>
> tom
>


Thank you. This clarifies me a lot because I had not thought to use both
building=* and building:part=* in the footprint.

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

Re: [Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Sorry, I should have taken time to give some examples. Please read below (I
rev.

2017-08-18 1:30 GMT+01:00 Clifford Snow <cliff...@snowandsnow.us>:

>
>
> On Thu, Aug 17, 2017 at 4:12 PM, Javier Sánchez Portero <
> javiers...@gmail.com> wrote:
>
>>
>> I am thinking in ways to reduce the complexity that introduces the
>> mapping of parts of buildings. For example:
>>
>
I have reversed the order of the points

* In the wiki [1] says that the outline should be tagged with
>> building:levels and height, but this, if the parts cover the whole outline,
>> is a duplication since these tags will always be in some of the parts.
>> Could I delete the part(s) whose labels match those of the outline?
>>
>
> If you use a multipolygon, then the multipolygon would contain the levels
> and height.
>

I'm refering to 3D modeling of building height and levels, according to
[1]. For example, this building [2] have two heights and should be drawn
two parts inside the building footprint, one with (building:part=yes,
building:levels=1, height=3) [3], and another one with (building:part=yes,
building:levels=2, height=6). As the building footprint [2] could have the
levels and height tags I put them in it avoiding to draw one part. I meant,
the building area is not entirely covered by building:part areas. All the
building in this village was drawn according to this.

I take the rule to put in the building:levels and height tags of the full
building those of the level wich parts sum a greatest area instead of the
maximum values. For a example see the adjacent building to the left [4]. It
have (building:levels=1, height=3) instead of the maximum values
(building:levels=2, height=6) of the building:part [5]. This way I avoid to
draw two parts inside the building. I consider that the maximum
building:levels and height could be calculated by a consumer from the
building and its parts instead. I'm wrong with it? But it's against what
says the wiki [6].


> * If one part is inscribed within a larger one, can I use simple ways
>> overlapped and leave to the render decide how to draw them or should I
>> create a multipolygon for the larger part with the smaller part with inner
>> role? I'm prone to the first.
>>
>
> An example would help. If the building has an inner court yard, then a
> multipolygon would be appropriate, with the inner court yard with an inner
> role.
>

I'm not referring to buildings with holes but to nested building:part
areas. Consider this building [7] with a big one-story part and a smaller
two-story part [8] within it. If I use the full detailled schema I will
need a multipolygon relation for the one-story part, but I avoid this
putting the tags in the footprint (violating the rule of maximum levels and
height in it). I don't have real example at hand, but supposes another
three-story part inscribed inside the two-story part [8]. should I use a
multipolygon for the two-story part to fully separate it area from the
three-story part area? Or could I just draw the inner three-story part,
overlapping both areas?

[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
[2] http://www.openstreetmap.org/way/459549932
[3] http://www.openstreetmap.org/way/459550128
[4] http://www.openstreetmap.org/way/459549958
[5] http://www.openstreetmap.org/way/459550129
[6] https://wiki.openstreetmap.org/wiki/Key:building:part
[7] http://www.openstreetmap.org/way/215569626
[8] http://www.openstreetmap.org/way/459573978
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Simplify building:part areas

[Javier Sánchez Portero]

Hello.

I am thinking in ways to reduce the complexity that introduces the mapping
of parts of buildings. For example:

* If one part is inscribed within a larger one, can I use simple ways
overlapped and leave to the render decide how to draw them or should I
create a multipolygon for the larger part with the smaller part with inner
role? I'm prone to the first.

* In the wiki [1] says that the outline should be tagged with
building:levels and height, but this, if the parts cover the whole outline,
is a duplication since these tags will always be in some of the parts.
Could I delete the part(s) whose labels match those of the outline?

[1] https://wiki.openstreetmap.org/wiki/Key:building:part

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

Re: [Tagging] Power Tower Landuse = ?

[Javier Sánchez Portero]

I'm also using landuse=industrial for towers, substations and all the
related gear despite being in a rural area.

2017-06-30 4:37 GMT+01:00 John Willis :

> Which landuse is appropriate for power towers?
>
> http://www.tepco.co.jp/pg/electricity-supply/operation/
> images/img_substation_04.jpg
>
> here is a picture of some of the towers I am talking about. In this case,
> most are in or adjacent to a substation.The giant red-white towers in the
> picture are common in my area, and run across our region. they use a large
> 25mx25m piece of land for their base. I am talking about these towers when
> they are by themselves, in farmland or residential areas.
>
> The giant power towers have a mappable (usually fenced) landuse - the
> tower bases are usually near some kind of access road, and the land for
> towers is as large as a housing plot. Farmers do not farm under the base,
> even if there isn’t a fence, making it a separate landuse from whatever is
> around it.
>
> Somewhat related, micromapped solar panel installations:  the panels
> themselves are the power generators, but it seems wrong to tag the landuse
> of a field of solar panels as a “power plant” - as solar panels (and wind
> farms) are very distributed and could be mixed land use, and are passive -
> they don’t seem to be “power stations” in the way that coal, oil, nuclear,
> or even solar-thermal stations are), and although I have been usng
> landuse=industrial, it seems to not fit really well. Perhaps that is an
> incorrect choice, but I don’t know what to use.
>
> https://www.openstreetmap.org/way/504120713
> https://www.openstreetmap.org/way/503938829
> https://www.openstreetmap.org/way/504121156
>
> Similar to landuse=highway and landuse=railway, there are landuse values
> for the areas used by part of a system -  but not an important or active
> part of the system, like the train tracks between stations.
>
> Is there a landuse=power? there are currently 9 landuse=power uses in OSM.
> the one in Japan is surely a mis-tag. But maybe landuse=power as a
> catch-all for land used by passive generation and transmission is a good
> idea.
>
> advice?
>
> Javbw
>
>
> ___
> 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] Services provided by a travel agency

[Javier Sánchez Portero]

The services offered are very similar to a travel agency, but for local
services instead of remote ones. Maybe shop=tourism_agency?

2017-06-29 23:13 GMT+01:00 Graeme Fitzpatrick :

> I won't disagree with you about shop=tourism as no, I've never heard of a
> tourism shop either (& we live in a tourist-oriented area)!
>
> Maybe it's another term that doesn't translate internationally, but here
> in Australia at least, "travel agencies" don't handle day-to-day tourist
> matters like boat rides, walking tours etc either. Travel agencies are
> where you sit down with a travel agent a few months prior to leaving on
> your trip, to plan your itinerary, work out which flights you need to catch
> & book them, book your cabin on a cruise ship etc.
>
> We do have tourism information centres, where they hold stocks of
> brochures etc telling tourists what attractions there are in the area, what
> the opening hours of the local museum are & so on, but, once again, they
> don't usually book ferry rides, tours & so on - that's left up to the
> tourist to do either online or by phone?
>
> I don't know what you would call the type of "shop" that Volker originally
> described, but maybe tourism=information woud cover it?
>
> Thanks
>
> Graeme
>
>
> On 30 June 2017 at 01:09, Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> On 28. Jun 2017, at 23:46, Graeme Fitzpatrick 
>> wrote:
>>
>> There is a tag for bicycle rental: http://wiki.openstreet
>> map.org/wiki/Tag:amenity%3Dbicycle_rental.
>>
>>
>>
>> +1, although this will probably not lead to a compatibile tagging scheme,
>> because I'd expect many of the things in the amenity key .
>>
>>
>>
>>
>> Maybe just shop=tourism together with that?
>>
>>
>>
>> don't like this tag, IMHO too generic, not well distinguishable from
>> travel agencies, no clear meaning (ever heard someone saying: I'm going to
>> the tourist shop? What would you think if you heard this? I would likely
>> ask 'where?'). It isn't really a category (of what they sell) rather than a
>> category for whom it is (i.e. it can be used to disqualify a shop as
>> "mostly for tourists " (locals who know the situation won't go there), but
>> not to qualify the kind of things they offer).
>>
>> Cheers,
>> Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Combined use of addr:place and addr:street

[Javier Sánchez Portero]

I edited the wiki and tried to improve the text a bit. As English is not my
native langauge any additional correction will be appreciated.

Best regards.

2017-06-23 10:18 GMT+01:00 Martin Koppenhoefer <dieterdre...@gmail.com>:

>
> 2017-06-23 10:01 GMT+02:00 Javier Sánchez Portero <javiers...@gmail.com>:
>
>> Regarding to the use of addr:place together with addr:street, I see a
>> discrepancy between [1] which says: "Should not be used together with
>> addr:street=*"
>>
>> And [2], which says: "Use addr:place additional to addr:street=* for such
>> building, whose numbers belong not to street, but to some other object. It
>> is proposed to delete addr:street=* from such houses in the future"
>>
>> I will like to correct this with a unified criterion in both places.
>> Which one is the prefered criterion for you? I think that the addr:place
>> tag should be used when there isn't a street with name to assign to the
>> address so I don't see corret to use addr:street together with addr:place.
>> What is your opinion?
>>
>
>
> I agree with you, either use
> addr:place
>
> or use
> addr:street
>
> As the reason for using addr:place is that there isn't a street to which
> the address refers, I also don't see which street should go into
> addr:street, it makes no sense.
>
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Combined use of addr:place and addr:street

[Javier Sánchez Portero]

Hello

Regarding to the use of addr:place together with addr:street, I see a
discrepancy between [1] which says: "Should not be used together with
addr:street=*"

And [2], which says: "Use addr:place additional to addr:street=* for such
building, whose numbers belong not to street, but to some other object. It
is proposed to delete addr:street=* from such houses in the future"

I will like to correct this with a unified criterion in both places. Which
one is the prefered criterion for you? I think that the addr:place tag
should be used when there isn't a street with name to assign to the address
so I don't see corret to use addr:street together with addr:place. What is
your opinion?

Regards, Javier Sanchez

[1] https://wiki.openstreetmap.org/wiki/Key:addr
[2] https://wiki.openstreetmap.org/wiki/Key:addr:place
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Place areas

[Javier Sánchez Portero]

2017-06-19 14:15 GMT+01:00 Frederik Ramm :

> If you can't point to a sign on the ground, don't map topoynms.
>

-1. May be in some urban areas it's usual to find signs for toponyms, but
more frequently -mainly in rural and wild areas- the toponyms are in the
knowledge of the local people, not in signs. Especially for that reason
they must be collected in the maps.

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

Re: [Tagging] dispersed settlements / scattered settlements

[Javier Sánchez Portero]

2017-06-16 19:52 GMT+01:00 Dudley Ibbett :

> I’m slightly confused by this discussion.  I live in a “hamlet” which is
> within a “dispersed settlement”.  “Dispersed settlement” describes the
> pattern of isolated dwellings, farmyards, hamlets, villages etc. on a
> much larger scale.
>
>
>
> We don’t really seem to have tags that currently describe settlement
> patterns.  If we did then we would need “linear” & “nuclear” as well as
> “dispersed”.
>
>
>
> The “hamlet” has a name (which is used in the address) but the “dispersed
> settlement” doesn’t as it is just describes a pattern of buildings,
> hamlets, farmyards etc.
>
>
> Regards
>
>
> Dudley
>
>
That not a pattern everywhere. There are places where a "dispersed
settlement" don't have a "hamlet" inside. The hamlet tag description don't
fit because it could have more than 100-200 inhabitants and not necessary
should be strictly isolated. Anyway, it has a name.

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

Re: [Tagging] dispersed settlements / scattered settlements

[Javier Sánchez Portero]

Also note that, at least here in Spain, in a dispersed settlement the
'streets' usually have no name and the postal address of the building is
given by the name of the settlement and a housenumber. So this is a valid
postal address "Lugar Anocheza, 10" where "Lugar" means place.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] dispersed settlements / scattered settlements

[Javier Sánchez Portero]

Hello

I would like to say that here, in Spain, we are in the same case. The
goverment office for population census give in [1] for each unit
(settlement) two values refering to the nucleus population and to the
dispersed population. Very frequently, there are units with only dispersed
population and no central nucleus. They usually correspond to an area with
a mix of residential and agricultural landuses with disperse buildings that
receives a common name.

Any of the two proposals, a new tag or change place=locality, will be fine.

Greetings, Javier Sanchez

[1] http://www.ine.es/nomen2/index.do


2017-06-15 12:35 GMT+01:00 mbranco2 :

> Martin began this thread after a discussion in the Italian List [1] .
> Problem arise because we've official toponyms (they are used in addresses,
> in scarcely inhabited areas, where roads have not an official name).
> These toponyms are not strictly related to the (few) dispersed houses, but
> also to the surrounding woods, meadows, fields, etc
> There aren't official borders for these areas, so we'd use just only a
> node, not a closed way to identify the zone.
>
> To show an example, in this screenshot [2] you can read several toponyms
> related to this area [3] : coloured dots are buildings with related toponym
> being in their addresses.
>
> You can find (several times) the same issue in the discussion page for
> place=locality [4] : in my opinion, place=locality could resolve this issue
> if we change "unpopulated place" with "unpopulated or scarcely inhabited
> place".
>
> Ciao,
> Marco
>
> [1] http://gis.19327.n8.nabble.com/Cantone-contrada-
> localita-regione-tp5897927.html
> [2] https://drive.google.com/open?id=0B65acVCG5NRQTVZ1MFg0aF9jSDQ
> [3] https://www.openstreetmap.org/#map=15/45.5461/7.9607
> [4] https://wiki.openstreetmap.org/wiki/Talk:Tag:place%3Dlocality
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging