[Tagging] aeroway=runway - wiki fiddling

[Martin Koppenhoefer]

I have noticed that there is a lot of change happening on the runway
wikipage.

Up to some months ago, the longstanding definition for a runway was:
"A strip of land kept clear and set aside for airplanes to take off from
and land on."

This was changed to "Runway of an airfield"

Another main aspect concerns the mapping as linear feature and or as area.
There used to be a paragraph stating:
Mapping aeroway =runway as
areas is disputed. You can join the discussion here
 and
here

.

Sometimes *in addition* the outline of the runway is mapped as [image: Area]
 area with aeroway
=runway + area
=yes
.


This is also reflected in the data, where area=yes is still a used
combination with this tag, but the whole paragraph was removed some time
ago and today also the "area"-object was removed from the "mapped as"
property.

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

Re: [Tagging] aeroway=runway - wiki fiddling

[Austin Zhu]

Well, maybe there is someone who thinks mapping runway as area is wrong? I
think that both way and area are OK, because the way element matches the
way we map taxiways. So it is useful when others need to guide their plane
using osm data(maybe in flight simulator softwares). Mapping as area can
show the width of the runway and thus is more realistic. The best method
should be using both elements. Just like highway objects. Obviously, the
wikipage needs some edit or restoration.

Another thing I want to say is that should the overrun section be a part of
the runway? I saw some users deleted or split the overrun section from a
runway object. The runway article on Wikipedia includes that overrun in
"Sections of a runway" part. So I'm thinking if I can address it clearly on
the wikipage. Tell me what you think about it! (Kind of diverted from the
discussion)

Regards,
Austin Zhu


On Fri, Mar 9, 2018, 17:13 Martin Koppenhoefer 
wrote:

> I have noticed that there is a lot of change happening on the runway
> wikipage.
>
> Up to some months ago, the longstanding definition for a runway was:
> "A strip of land kept clear and set aside for airplanes to take off from
> and land on."
>
> This was changed to "Runway of an airfield"
>
> Another main aspect concerns the mapping as linear feature and or as area.
> There used to be a paragraph stating:
> Mapping aeroway =runway
> as areas is disputed. You can join the discussion here
>  and
> here
> 
> .
>
> Sometimes *in addition* the outline of the runway is mapped as [image:
> Area]  area with aeroway
> =runway + area
> =yes
> .
>
>
> This is also reflected in the data, where area=yes is still a used
> combination with this tag, but the whole paragraph was removed some time
> ago and today also the "area"-object was removed from the "mapped as"
> property.
>
> 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] discrepancy in shop definition and "wholesale" value

[Paul Johnson]

On Mar 9, 2018 00:17, "Johnparis"  wrote:

Typically they will, for example, sell detergent in boxes of 5 kg instead
of 1 kg. Or a liter of ketchup. Hence the (USA) term "big box". So they are
"wholesale-sized" but not wholesale in the sense of their sales mechanism.
(The wholesale=* tag is for wholesalers.)


Big box refers to the building form factor.  Costco is a big box.  But so
is Lowe's, Walmart Supercenter, Home Depot, Office Depot, Dick's, Staples,
Kohl's, Sam's Club, Best Buy, Petco, Target…pretty much anything that would
occupy an anchor slot or larger if it were in a traditional mall and favors
generic, big, boxy, windowless buildings.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] aeroway=runway - wiki fiddling

[Paul Johnson]

On Mar 9, 2018 03:49, "Austin Zhu"  wrote:

Well, maybe there is someone who thinks mapping runway as area is wrong? I
think that both way and area are OK, because the way element matches the
way we map taxiways. So it is useful when others need to guide their plane
using osm data(maybe in flight simulator softwares). Mapping as area can
show the width of the runway and thus is more realistic. The best method
should be using both elements. Just like highway objects. Obviously, the
wikipage needs some edit or restoration.


Map the runways and taxiways as linear (who knows, someone might want to
have a routable model for flight simulators or similar games), and map the
negative space (grass infields, etc) as areas?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] aeroway=runway - wiki fiddling

[Christoph Hormann]

On Friday 09 March 2018, Martin Koppenhoefer wrote:
> I have noticed that there is a lot of change happening on the runway
> wikipage.
>
> Up to some months ago, the longstanding definition for a runway was:
> "A strip of land kept clear and set aside for airplanes to take off
> from and land on."
>
> This was changed to "Runway of an airfield"

Noticed that too - to complete the self referential circle you would now 
just have to edit

https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Daerodrome

And change it to "the area around a runway". ;-)

> Another main aspect concerns the mapping as linear feature and or as
> area. [...]

This is a topic that seems to turn up every few months or so.  The basic 
facts are:

* For runways the two node way with optionally a width tag is by far the 
dominating way to map them.  A variety of other methods and suggestions 
exist (linear way + polygon with the same tag, polygon only, linear 
way+ polygon with other tag) but none of them has found consistent use 
so far.
* A four node polygon transports no additional information for a runway 
compared to a two node way with a width tag.
 
-- 
Christoph Hormann
http://www.imagico.de/

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

[Tagging] Different postal codes in each side of the street

[Fernando Trebien]

In Brazil some streets have a different postal code on each side.
There seems to be no officially defined tag to represent this on ways.
Nominatim supports [1] US TIGER tags tiger:zip_left and
tiger:zip_right, even though those could be replaced with postal code
boundary relations [2] in the future since they are areas [3]. It
doesn't seem to make sense to recommend using them outside the US.
Over here we could perhaps use a large number of postal code boundary
relations, or painstakingly add a postal code to every address.

What would you recommend in this situation? Perhaps we should adopt
postal_code:[side] and ask Nominatim developers to support that?

[1] 
https://github.com/openstreetmap/Nominatim/blob/master/utils/tigerAddressImport.py
[2] https://wiki.openstreetmap.org/wiki/Tag:boundary=postal_code
[3] http://www.zipmap.net/

-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [Tagging] Different postal codes in each side of the street

[Paul Johnson]

On Mar 9, 2018 14:10, "Fernando Trebien"  wrote:

In Brazil some streets have a different postal code on each side.
There seems to be no officially defined tag to represent this on ways.
Nominatim supports [1] US TIGER tags tiger:zip_left and
tiger:zip_right, even though those could be replaced with postal code
boundary relations [2] in the future since they are areas [3].


TIGER uses US Census zips, not US Postal Service.  US Census zips aren't
used in addresses, and may not necessarily match the Postal Service zips.
tiger:zip*=* can probably be removed as pointless.

Furthermore, while Census zips do describe areas, Postal Service zips do
not, boundaries are not applicable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Different postal codes in each side of the street

[Philip Barnes]

That is quite a common thing. I tag the buildings, or addressed nodes,
with the appropriate postcode. So building one side will have one
postcode and on the other side they will have a different postcode.

The postman doesn't deliver mail to the street and large users will
have their own postcode.

Phil (trigpoint)


On Fri, 2018-03-09 at 17:08 -0300, Fernando Trebien wrote:
> In Brazil some streets have a different postal code on each side.
> There seems to be no officially defined tag to represent this on
> ways.
> Nominatim supports [1] US TIGER tags tiger:zip_left and
> tiger:zip_right, even though those could be replaced with postal code
> boundary relations [2] in the future since they are areas [3]. It
> doesn't seem to make sense to recommend using them outside the US.
> Over here we could perhaps use a large number of postal code boundary
> relations, or painstakingly add a postal code to every address.
> 
> What would you recommend in this situation? Perhaps we should adopt
> postal_code:[side] and ask Nominatim developers to support that?
> 
> [1] https://github.com/openstreetmap/Nominatim/blob/master/utils/tige
> rAddressImport.py
> [2] https://wiki.openstreetmap.org/wiki/Tag:boundary=postal_code
> [3] http://www.zipmap.net/
> 

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

Re: [Tagging] Different postal codes in each side of the street

[marc marc]

Le 09. 03. 18 à 21:08, Fernando Trebien a écrit :
> In Brazil some streets have a different postal code on each side.

the same happend in a lot of country.
in Belgium, they create postal_code boundary but Nominatim don't use
the location of the house, it use the location of the street witch is of 
course not in one-only boundary.
they also create 2 associatedStreet, one for each side,
but nominatim doesn-t use it.
I open a issue a few month ago, problem is that somebody need
to take some time to code it
https://github.com/openstreetmap/Nominatim/issues/897

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

Re: [Tagging] Different postal codes in each side of the street

[Paul Allen]

On Fri, Mar 9, 2018 at 8:08 PM, Fernando Trebien  wrote:

> In Brazil some streets have a different postal code on each side.
> There seems to be no officially defined tag to represent this on ways.
> Nominatim supports [1] US TIGER tags tiger:zip_left and
> tiger:zip_right, even though those could be replaced with postal code
> boundary relations [2] in the future since they are areas [3]. It
> doesn't seem to make sense to recommend using them outside the US.
> Over here we could perhaps use a large number of postal code boundary
> relations, or painstakingly add a postal code to every address.


Here in the UK we often painstakingly add a postal code to every address.
Because in the UK
it isn't as simple as one postcode per street, or one postcode per side of
street.  That would
be far too easy. :)

In my part of the UK I've mapped the following peculiarities:

1) Buildings with high volumes of post getting their own postcode.
Government offices.
Banks (they don't get much post these days, but 30 years ago there were a
lot of cheques
that had to be returned to the relevant branch).

2) A large building gets demolished.  Several new ones go up in its place.
That
would disrupt the numbering scheme, so there is a sub-level of street, such
as

1 Quay Street, SA43 1HU
  , 2 Quay Street, SA43 1HU
New Life Church, SA43 1HU
1 Rock Terrace, Quay Street, SA43 1HS
2 Rock Terrace, Quay Street, SA43 1HS
...
5 Rock Terrace, Quay Street,.SA43 1HS
1 Royal Oak, Quay Street, SA43 1HR
2 Royal Oak, Quay Street, SA43 1HR

It's all Quay Street.  It's very confusing for anyone who doesn't
understand what's
there because there are no signs saying Rock Terrace or Royal Oak.  So you
see
numbers 1 and 2 on Quay Street 3 times.  Hence the different postcodes all
on
the same side of the street.  Just to confuse matters, the other side of
the street has
numbers 16 to 26 (all SA43 1HU).

3) Different postcodes on opposite sides of the street.  It bifurcates (a Y
junction)
and all three arms are North Road.  I assume the postal delivery round also
bifurcates.

4) High rises.  None of those near me, but they merit their own postcode
both
to segregate mailbags and to ensure that 1, Big Tower, Long Street gets a
different postcode from 1, Long Street.

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

Re: [Tagging] Different postal codes in each side of the street

[Andre Engels]

In the Netherlands having the same postal code on both sides of the
streets is a great exception. We always put all address information on
the individual address.

On Fri, Mar 9, 2018 at 9:08 PM, Fernando Trebien
 wrote:
> In Brazil some streets have a different postal code on each side.
> There seems to be no officially defined tag to represent this on ways.
> Nominatim supports [1] US TIGER tags tiger:zip_left and
> tiger:zip_right, even though those could be replaced with postal code
> boundary relations [2] in the future since they are areas [3]. It
> doesn't seem to make sense to recommend using them outside the US.
> Over here we could perhaps use a large number of postal code boundary
> relations, or painstakingly add a postal code to every address.
>
> What would you recommend in this situation? Perhaps we should adopt
> postal_code:[side] and ask Nominatim developers to support that?
>
> [1] 
> https://github.com/openstreetmap/Nominatim/blob/master/utils/tigerAddressImport.py
> [2] https://wiki.openstreetmap.org/wiki/Tag:boundary=postal_code
> [3] http://www.zipmap.net/
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
André Engels, andreeng...@gmail.com

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

Re: [Tagging] Different postal codes in each side of the street

[Kevin Kenny]

Oops, sent an earlier attempt from the wrong place:

TIGER:zip_left and zip_right were intended to be ZIP codes, because
they were there to help census workers find the houses who hadn't
returned census forms (which were sent out to postal addresses).
They were never entirely correct, though, and were based on an
incorrect mental model of "ZIP code as an area feature" rather than
"a set of discrete points where the truck delivers the mail". So
the whole idea was pretty screwy right from the start. (For instance,
my workplace has a unique five-digit ZIP code. When I started
here back in the day, it didn't have a building number, because
it was the only address in its ZIP code. Eventually the fire
brigade insisted that it have one, and it acquired a vanity
address: One Research Circle.)

When I'm entering a building address, I fill in number and street,
city, state and ZIP code - the entire tuple. I see very little value
to tiger:zip at this point.

If I'm moving down a street, entering address after address, JOSM
does handle things quite conveniently, with most of the fields
pre-filled. (I wish it had a custom increment value. A lot of the
streets in my community have building numbers that increment
by 4 instead of 1 or 2, so that there's a little room for expansion
if someone subdivides a building lot.)

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

Re: [Tagging] Different postal codes in each side of the street

[Paul Johnson]

Likewise, not everywhere in America has a postal zipcode, but the Census
invented ones for their own purposes.

On Mar 9, 2018 16:13, "Kevin Kenny"  wrote:

> Oops, sent an earlier attempt from the wrong place:
>
> TIGER:zip_left and zip_right were intended to be ZIP codes, because
> they were there to help census workers find the houses who hadn't
> returned census forms (which were sent out to postal addresses).
> They were never entirely correct, though, and were based on an
> incorrect mental model of "ZIP code as an area feature" rather than
> "a set of discrete points where the truck delivers the mail". So
> the whole idea was pretty screwy right from the start. (For instance,
> my workplace has a unique five-digit ZIP code. When I started
> here back in the day, it didn't have a building number, because
> it was the only address in its ZIP code. Eventually the fire
> brigade insisted that it have one, and it acquired a vanity
> address: One Research Circle.)
>
> When I'm entering a building address, I fill in number and street,
> city, state and ZIP code - the entire tuple. I see very little value
> to tiger:zip at this point.
>
> If I'm moving down a street, entering address after address, JOSM
> does handle things quite conveniently, with most of the fields
> pre-filled. (I wish it had a custom increment value. A lot of the
> streets in my community have building numbers that increment
> by 4 instead of 1 or 2, so that there's a little room for expansion
> if someone subdivides a building lot.)
>
> ___
> 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] Tagging request: missing admin_level tags

[Matthijs Melissen]

Hi all,

OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is
considering to change the mechanism for rendering admin boundaries.
The proposed rendering of admin borders will be based on admin
boundary ways rather than polygons. This has a number of advantages -
for example, it will make it possible to style maritime boundaries
differently.

The admin boundary ways are already in the database. However, in some
cases they are missing an admin_level tag. When the proposed style
change will be deployed, boundary=administrative ways without
admin_level tag will no longer be rendered. I would therefore suggest
to make sure admin_level tags are present on all
boundary=administrative ways.

A map showing admin boundary ways without admin_level tag (displayed
in gray) can be found here:
http://product.itoworld.com/map/2?lon=20.00736&lat=51.92203&zoom=6
As can be seen, most countries already do have admin_level on ways.
However, in for example Poland, Iran and Australia, this data seems to
be missing.

-- Matthijs

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