Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-20 Thread Eugene Alvin Villar
Thanks, Brian, for taking the lead on this. I generally agree with the
overall direction of the proposal. There's a lot of details on the proposal
page but I guess we can discuss them on the wiki talk page.

On Sun, Dec 20, 2020 at 10:58 PM Brian M. Sperlongano 
wrote:

> A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is
> now open for comments.
>
> This proposal:
>
>   1. Deprecates landuse=reservoir
>   2. Provides definitions for:
>  a. water=reservoir
>  b. water=lake
>  c. water=pond
>
> It is clear from various multiple discussions on this topic that there are
> still open questions from the original 2011 water=* proposal, as well as
> the exact definition of a reservoir, and how they differ from lakes and
> ponds.  Previous discussions indicated that there is community support for
> maintaining a distinction between lake and pond, rather than eliminating or
> merging these concepts.
>
> The definitions posed in this proposal were developed with the help of
> considerable community input over the last week, and I want to thank the
> numerous folks that collaborated on this.  The real world presents many
> edge cases that make it challenging to come up with clear definitions, but
> that should not prevent us from trying.
>
> The goal in these definitions is to *describe* rather than *prescribe* how
> reservoir, lake, and pond are actually tagged.  This necessarily involves
> some degree of subjectivity between the categories, and the proposed
> definitions leave it to mappers to make these subjective decisions when a
> body of water exhibits some characteristics of more than one of these terms.
>
> As this topic has been discussed ad nauseam for nearly a decade, I hope
> that this proposal, discussion, and subsequent vote will allow us to put
> this issue to rest, and/or document the level of community support that
> exists for different tagging schemes.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> ___
> 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] Deprecate water=pond?

2020-11-11 Thread Eugene Alvin Villar
There are lots of tags in OSM that have fuzzy borders with respect to size
or importance. Some that I can think of are waterway=river/stream and
place=island/islet. Although the island/islet tag does have a hard boundary
at least in the JOSM validator and an approximate boundary in the OSM wiki
("about 1 square kilometre"). That doesn't mean that the distinction is
useless for lake/pond.

On Wed, Nov 11, 2020, 7:23 PM OSM,  wrote:

> Maybe there is no clear-cut between a lake and a pond - but for me there
> is at least a clear impression by size of a pond or a lake beyond the
> transition zone.
> I never would call a natural small water or a 'Gartenteich' (garden
> pond) a lake.
>
> --
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.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] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

2020-02-20 Thread Eugene Alvin Villar
On Thu, Feb 20, 2020 at 9:13 PM Joseph Eisenberg 
wrote:

> Oh, here in Indonesia you can find motorcycle taxis (ojek) everywhere,
> including in all the towns where bicycle rickshaws / pedicabs operate.
>
> For example, all of the markets in my town have a pangkalan ojek
> (motorcycle taxi stand) and a separate pangkalan becak (pedicab
> stand), usually near the main entrance.
>
> I prefer the pedicabs when I have luggage, since there is a nice wide
> bench which can carry more cargo than can fit on a motorcycle, and
> they are quiet and slower. But the motorcycles are faster, so if you
> are in a hurry or have a long trip, they are the better choice.
>

Hmmm. It seems that your ojeks are a different sort of public
transportation to our tricycles/pedicabs in the Philippines. If I
understand your description correctly, ojeks seem to be like regular
4-wheeled taxis in many respects except for the use of motorcycles, but in
the Philippines, tricycles/pedicabs are never used for long-distance travel
and are usually used for the "last-mile" travel typically to get to a
particular house from a main highway (or to get from the house to the
highway). These tricycles/pedicabs usually have "service areas" (often a
gated subdivision, or a village, or a close cluster of hamlets) and they
only provide transportation within that area and cannot bring you anywhere
unlike regular taxis.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

2020-02-20 Thread Eugene Alvin Villar
On Thu, Feb 20, 2020, 8:32 PM Joseph Eisenberg, 
wrote:

> > I think using "motorcycle_taxi" as a tag value would be confusing.
>
> Unfortunately, the English language terminology for these things is
> not very established, since they are not used in Britain or North
> America (except for the tourist pedicabs as mentioned), which makes it
> harder to pick a good tag value which will work everywhere.
>
> Are you aware of any alternative phrase or word which would be clearer?
>

Well, in Philippine English (English is an official language in the
Philippines), the standard English term is "tricycle" as can be seen in
everyday usage and in laws that regulate these forms of public
transportation. Unfortunately, I know that "tricycle" is ambiguous if you
look at global English usage so I have no real good alternative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

2020-02-20 Thread Eugene Alvin Villar
On Thu, Feb 20, 2020, 8:28 PM Martin Koppenhoefer, 
wrote:

>
>
> Am Do., 20. Feb. 2020 um 13:21 Uhr schrieb Eugene Alvin Villar <
> sea...@gmail.com>:
>
>> The only difference is one is human-powered while the other is
>> engine-powered.
>>
>
>
> IMHO, if we distinguish automobile taxis from motorcycle taxis, we should
> also distinguish both from human powered vehicles. They may all fulfill
> similar necessities, but from this "only difference" there are following
> many consequences (speed, noise, range, etc.) so it would definitely be
> worth make a distinction.
>

Just to clarify, these public transport services are either exclusively
using motorcycles or exclusively using bicycles in a particular locale. As
a commuting passenger, you generally have no choice whether you want the
bicycles instead of motorcycles or vice versa. So the difference (human vs.
engine) is a pedantic difference instead of a practical difference. That
said, it is perfectly fine to use different secondary tags or subtags to
differentiate between the two, just not have different top-level tags.

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


Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

2020-02-20 Thread Eugene Alvin Villar
As a person from the Philippines who uses these "motorcycle taxis" (we call
them tricycles here and they are basically motorcycles with an attached
sidecar for passengers), I am in favor of having a new top-level tag for
these "taxi" stations. The reason why we used "taxi" here is that this was
the closest comparable equivalent tag for such public transport amenities.

However, I would prefer a value that is something else than
"motorcycle_taxi" and that is because in some other areas, instead of
motorcycles, they use (pedaled) bicycles instead. These are called pedicabs
(but in other parts of the country, tricycles may be called pedicabs as
well) and are effectively equivalent to the traditional motorcycle
tricycles as a form of public transportation. The only difference is one is
human-powered while the other is engine-powered.

Furthermore, we actually have "real" motorcycle-based ride-hailing taxi
services here (one such service is called Angkas: https://angkas.com/ ) and
I think using "motorcycle_taxi" as a tag value would be confusing.


On Thu, Feb 20, 2020 at 3:50 PM Joseph Eisenberg 
wrote:

> I would like to formally request comments on the proposal for
> amenity=motorcycle_taxi:
>
> "A place where motorcycle taxis wait for passengers"
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi
>
> In many countries, motorcycles for hire are much more common than
> automobile taxis.
>
> In these places, motorcycle drivers wait at stands, often with a small
> shelter, and they can be hired to take one or more passengers to
> various destinations. A fare is paid for a one-way trip. The passenger
> usually rides behind the driver. In some countries two or even three
> passengers can be carried on one motorcycle "taxi".
>
> Motorcycle taxis are also known as "motos" or "bike taxi", or by other
> local names, such as "ojek" here in Indonesia and in Singapore,
> "boda-boda" in Uganda, and "okada" in Nigeria.
>
> While some have proposed using amenity=taxi plus additional tags for
> motorcycle taxi stands, this is quite confusing for travelers who
> generally expect a "taxi" to be 4-wheeled motorcar capable of carrying
> 4 people and luggage. So a different tag is proposed to avoid
> confusion and more precisely tag these features.
>
> - Joseph Eisenberg
>
> ___
> 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] Active volcanoes

2020-01-30 Thread Eugene Alvin Villar
FWIW, here is a query results map showing all volcanoes (805 of them) in
Wikidata that already have the GVP ID:
https://query.wikidata.org/embed.html#%23defaultView%3AMap%0ASELECT%20DISTINCT%20%3Fvolcano%20%3FvolcanoLabel%20%3FGVPID%20%3Fcoords%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3Fvolcano%20wdt%3AP31%2Fwdt%3AP279%2a%20wd%3AQ8072%3B%20wdt%3AP1886%20%3FGVPID%3B%20wdt%3AP625%20%3Fcoords.%0A%7D%0A

On Thu, Jan 30, 2020 at 7:26 AM Paul Allen  wrote:

> On Wed, 29 Jan 2020 at 23:16, Clifford Snow 
> wrote:
>
>>
>> Can you explain how that would work? Take the example of Mount Baker. It
>> has a wikidata Q code of  Q594387. GVP has a volcano number of 321010. What
>> would a tag look like? Please excuse my ignorance of Wikipedia. I can read
>> articles and maybe understand some, but how Wikidata works is beyond my
>> comprehension :)
>>
>
> Go to https://www.wikidata.org/wiki/Q594387 and search the page for
> "smithsonian."   You see Smithsonian volcano ID 321010.  Dunno if that's
> been there for a long time or somebody just added it in response to your
> post
> here.
>
> Explaining how to add those iDs to other Wikidata volcanoes is beyond the
> scope of this response. :)
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Active volcanoes

2020-01-29 Thread Eugene Alvin Villar
Wikidata already has the GVP property:
https://www.wikidata.org/wiki/Property:P1886

So it's just a matter of ensuring that all volcanoes tracked by the GVP is
present in Wikidata and has the correct P1886 value.

On Thu, Jan 30, 2020 at 4:20 AM Clifford Snow 
wrote:

>
>
> Sent from my Android phone.
>
> On Wed, Jan 29, 2020, 12:14 PM Jez Nicholson 
> wrote:
>
>> Work with Wikidata to link the GVP article to their record on the
>> volcano, and only have the Wikidata link in OSM.
>>
>
> Any Wikipedians on here want to take this suggestion on?
>
>> ___
> 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] New page "Approval status" for "de facto", "in use", "approved" etc

2019-07-28 Thread Eugene Alvin Villar
On Sat, Jul 27, 2019 at 10:20 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Please take a minute to review the new page
> https://wiki.openstreetmap.org/wiki/Approval_status
>

Overall, this looks pretty good! I am in favor of documenting the status of
tags and this wiki page is a good start to explain what those statuses
mean. Mappers may quibble about the exact or specific meanings of
particular values, but at least this wiki page provides a central place to
collect such discussions (via the talk page) instead of or in addition to
this mailing list.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subtag for place=locality?

2019-04-16 Thread Eugene Alvin Villar
On Tue, Apr 16, 2019 at 10:00 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> I added some comments to the talk page of your "type=group" relation
> proposal.
>
> I would recommend simplifying the proposal to just be for groups of
> nodes, because there are already relations for multipolygons (areas)
>

I disagree. I think a group of areas is semantically different from a
multipolygon. If I will relate this to GeoJSON concepts, the first is like
a GeoJSON FeatureCollection where individual Features are
Polygons/MultiPolygons, while the second is just a GeoJSON MultiPolygon.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] start_date variants

2019-02-18 Thread Eugene Alvin Villar
On Tue, Feb 19, 2019 at 4:28 AM Richard  wrote:

> It would also be interesting to be able to tag the start of construction -
>> often construction starts many years before the building is finshed:
>> Airport BER in Berlin, Germany or La Sagrada Familia in Barcelona, Spain
>> are famous examples. How to tag this? Maybe: construction:start_date?
>>
>> Any thoughts on this?
>>
>
> you could map what was there at any particular time but I think it is
> better to provide the link to Wikipedia. Ordinary users will ever look at
> OSM data close enough to find out this details.
>

+1 (but link to Wikidata instead of [or in addition to] Wikipedia)

Most OSM data users only care about what is located where. Very few OSM
data users would be interested in historical information such as when a
building, a basilica, or an airport began and finished its construction.
The actual people who would be interested in such information would look
elsewhere instead of OSM and I think Wikidata is an excellent place to
document such rich types of information. For example, see the Wikidata item
for the Sagrada Família: https://www.wikidata.org/wiki/Q48435
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The actual use of the level tag

2019-01-22 Thread Eugene Alvin Villar
On Mon, Jan 21, 2019 at 4:11 PM Simon Poole  wrote:

> [...] addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>

I rechecked the two main OSM Wiki pages[1][2] on addr:*=* tags and
addresses in general and there is no indication there that such tags are
only intended to encode postal addresses (aside from the specific
addr:postcode=* tag). Personally, I use addr:*=* tags in any scenario where
addresses can be used, such as in contact/location addresses which is used
when the general public (and not just the postman/mailman) wants to go to
an office, shop, or an establishment. For example, the Consulate-General of
Japan in Hong Kong lists their location where they can be reached[3] as
"46-47/F, One Exchange Square, 8 Connaught Place, Central, Hong Kong". I
could then encode this as:

addr:floor=46-47/F
addr:housename=One Exchange Square
addr:housenumber=8
addr:street=Connaught Place
addr:place=Central (tag probably unnecessary if Central is already a
boundary)
addr:city=Hong Kong (probably unnecessary since HK already has a boundary)

As for level=*, I don't know whether this building skips any floor numbers
(4th? 14th? 24th? etc.) so I would hold off on tagging level=* until I get
to see their elevator buttons.

[1] https://wiki.openstreetmap.org/wiki/Key:addr
[2] https://wiki.openstreetmap.org/wiki/Addresses
[3] https://www.hk.emb-japan.go.jp/itpr_en/opentime.html

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


Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Eugene Alvin Villar
On Mon, Jan 21, 2019, 2:38 AM Tobias Zwick  2. no calculating forth- and back between level "indices" and real names
>for the levels (for neither the software nor the mapper) because this
>effectively eliminates the concept of indices
>

I use level=* for the machine-readable zero-based level/floor of an object
and addr:floor=* for the real name or human-readable value. Currently, many
mappers treat both tags as synonyms but I like how I use both for different
audiences.

https://taginfo.openstreetmap.org/keys/?key=addr%3Afloor

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


Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Eugene Alvin Villar
On Sun, Jan 20, 2019, 9:50 PM Tobias Zwick  Region| likely zero-based | likely one-based
> --|---|-
> Washington, Philadelphia, NY  | 3 |2
> Silicon valley, Los Angeles   | 4 |4
> Quebec, Montreal, Ottawa  | 6 |0
> Moscow|23 |   51
> Tokyo |14 |   16
> Seoul | 0 |2
> Bangkok   | 8 |5
> --|---|-
>
> For comparison:
> whole Phillipines |23 |4
> whole Netherlands |11 |2
> Berlin|19 |2
>
> *likely zero-based: there was at least one shop tagged with level=0
> *likely one-based: there was no shop tagged with level=0 but shops at at
>least two different other levels
>

A note: the Philippines is actually a one-based system (first floor =
ground floor) because our economy follows the U.S. as a result of being a
territory of the U.S. before and during WWII. The fact that you get more
zero-based level=* tagging in OSM for the Philippines is because of mappers
like me who actually do read the wiki and inform other new mappers of OSM's
system.

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-18 Thread Eugene Alvin Villar
Side discussion:

On Sat, Jan 19, 2019 at 6:31 AM Paul Allen  wrote:

> One could argue that place=island should be natural=island.
>

And then we go into the discussion that not all islands are natural, like
the artificial islands in Dubai. Then again, not all things currently
tagged natural=water is natural, so...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Imagery variations/misalignments in iD - which to use?

2019-01-11 Thread Eugene Alvin Villar
On Sat, Jan 12, 2019 at 8:26 AM John Willis  wrote:

> The issue I am facing is that, even after some adjustment of the angle of
> bing imagery, there seems to be some distortion. things don’t line up well
> between the Bing and ortho maps in some places, and are much closer in
> others.  a *lot* of the mapping aligns with the bing imagery, but there are
> areas of obvious 2-3m distortion in places (the road is wavy), but other
> areas of newer/clearer imagry align with the ortho imagry.
>

I also encounter this "wavy" roads in imagery. I think they are the result
of improper orthorectification by the imagery provider. Satellite imagery
is often off-nadir (not photographed straight down) so providers correct
for differences in terrain elevation by rectifying them based on available
elevation models. Unfortunately, many elevation models like SRTM cannot
distinguish between buildings and hills and so roads are often distorted
around tall buildings in many parts of the world.

I don't have any good solution for this aside from trying to get access to
better imagery so I just try to map things as best as I can. It may also
help to avoid micromapping unless you are sure that the imagery is really
good.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Eugene Alvin Villar
On Wed, Jan 9, 2019 at 11:35 PM Phake Nick  wrote:

> I believe many time the boundary of a peninsula are politically defined,
> for instance most would often see the Iberia peninsula end at where Spain
> meet France
>

So is Andorra within or outside the Iberian peninsula?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Building names, historical/original owner?

2018-12-14 Thread Eugene Alvin Villar
On Fri, Dec 14, 2018 at 11:36 PM Adam Franco  wrote:

> What are folks thoughts about these historical-owner building names when
> they aren't well-known? Should they go in a `description=
> ` tag, `alt_name=
> `, or some other tag?
>

If there is only a single old name and it is different from the current
name, we have the established tag old_name=* as explained here:
https://wiki.openstreetmap.org/wiki/Key:old_name
This wiki page also suggests other formats like old_name:1921-1932=* if the
name is valid in a particular period.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Can OSM become a geospacial database?

2018-12-06 Thread Eugene Alvin Villar
On Thu, Dec 6, 2018, 11:58 PM Eugene Podshivalov  But in Belarus for example we call our settlements "город" (can be city or
> town), "городской посёлок" (can be town or village),
> "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
> When people use the maps created form OSM database they don't care about
> the generic OSM categorization of settlements. They need their local
> category names.
> So what tag should be put those local category names in?
>

If these settlement types are legally-defined types in your country, you
could use the designation=* tag with your country-specific values alongside
the usual place=* tags.

See: https://wiki.openstreetmap.org/wiki/Key:designation

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


Re: [Tagging] Add some tag to identify disputed borders

2018-11-26 Thread Eugene Alvin Villar
On Mon, Nov 26, 2018 at 5:44 PM Martin Koppenhoefer 
wrote:

> Am Mo., 26. Nov. 2018 um 10:34 Uhr schrieb Eugene Alvin Villar <
> sea...@gmail.com>:
>
>> can you give a definition for de jure?
>>
>>> Which law applies?
>>>
>>
>> Maybe there is a better word or phrase than "de jure" but I would
>> classify these as borders where both countries are in agreement because of
>> a treaty or a similar legal document. For example, this role could be
>> applied to more than 99% of the Canada-United States border (there are
>> still some minor disputes between the two).
>>
>
> maybe "confirmed" (=both parties confirm the border)
> or "agreed"?
>

I think "agreed" is better. "confirmed" may imply that the border has been
surveyed/marked on the ground, which is not necessarily the case.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Add some tag to identify disputed borders

2018-11-26 Thread Eugene Alvin Villar
On Mon, Nov 26, 2018 at 4:37 PM Martin Koppenhoefer 
wrote:

> > On 23. Nov 2018, at 17:33, Eugene Alvin Villar  wrote:
> >
> > We should be therefore able to repurpose the roles in a type=boundary
> relation to store information about claimed, "de facto", and "de jure"
> borders
>
> can you give a definition for de jure?
> Which law applies?
>

Maybe there is a better word or phrase than "de jure" but I would classify
these as borders where both countries are in agreement because of a treaty
or a similar legal document. For example, this role could be applied to
more than 99% of the Canada-United States border (there are still some
minor disputes between the two).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - landuse=governmental

2018-11-23 Thread Eugene Alvin Villar
On Sat, Nov 24, 2018 at 12:45 AM Allan Mustard  wrote:

> Well, a central bank is a bank, after all, whether it is owned by the
> government or is a "private" parastatal organization.  I would tag it as
> amenity=bank since it is a bank.  Not all banks offer consumer services, so
> the fact that an individual cannot open an account in a central bank
> doesn't disqualify it.  Individuals cannot open accounts in the Bank for
> International Settlements, either, but it is a bank.  A central bank is a
> specialized bank that serves the government (controls the monetary system)
> and the commercial banking sector.  That's why it is called a "central"
> bank.
>
> >  It also wouldn't be tagged as a bank, because it doesn't have accounts
> & you can't go in & deposit / withdraw cash, or take out a loan.
>
> Maybe you and I cannot, but the commercial banks in that country can.
> It's a bank.
>

While central banks are certainly banks in and of themselves, I think
tagging central banks as plain amenity=bank *without other qualifying tags*
is a tricky one, and might constitute as expanding the definition of what
amenity=bank is on the OSM wiki. The OSM wiki states that an amenity=bank
feature is a  "financial establishment where customers can, among other
services, deposit and withdraw money, take loans, make investments and
transfer funds". I would think that the word "customer" in OSM is intended
to refer to people and regular businesses, and this is why such
establishments are under the amenity=* key. Unlike regular banks, central
banks usually only have other banks and their government as their sole
customers and in many countries, central banks act as a regulatory agency
for banks and other financial institutions, set country-wide fiscal
policies like interest rates, and print/mint their countries' currencies.
It therefore makes sense to tag central banks somewhat differently from
other banks.

I would also like to note that in my country, we do have a central bank,
but we also have two 100%-government owned commercial banks, established by
law, that I would not hesitate to tag as amenity=bank because they offer
financial services to the public at large.

As for the current proposal, in my country, we currently tag central bank
land as landuse=commercial. It might make sense to switch this to
landuse=governmental (or some other keyword as may be decided by OSM) if
this proposal pushes through.

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


Re: [Tagging] Add some tag to identify disputed borders

2018-11-23 Thread Eugene Alvin Villar
On Wed, Nov 14, 2018 at 5:30 PM SelfishSeahorse 
wrote:

> 1. 'inner' roles (and thus 'outer' roles too) are still needed in case a
> country has enclaves.
>

Even if a country has exclaves and/or has enclaves within it, you still
don't need to have "inner" and "outer" roles at all in order to make sense
of the (multi)polygon. They are there as a hint to fix hopelessly broken
multipolygon relations, but if such a relation is not broken, the "inner"
and "outer" roles are actually superfluous. For instance, the program
osm2pgsql actually has a check function named "check_inner_outer_roles"[1]
to identify relation member ways having the wrong roles in a
type=multipolygon or type=boundary relation. It is able to do this check
precisely because it is able to analyze a multipolygon relation and be able
to infer the correct roles for itself.

We should be therefore able to repurpose the roles in a type=boundary
relation to store information about claimed, "de facto", and "de jure"
borders.

[1]
https://github.com/openstreetmap/osm2pgsql/blob/93b73e5f5c3b20e80027ecf272f553d26f49f2e8/contrib/libosmium/osmium/area/detail/basic_assembler.hpp#L172
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Eugene Alvin Villar
I have been following this discussion with interest since I would also like
to have bays and straits represented by some sort of polygon/area instead
of just nodes. However, I also agree that having overlapping relations
containing hundreds to thousands of natural=coastline ways would tax many
data users, and be prone to getting errors from mappers who edit coastlines.

As a sort of compromise at least for bays (gulfs, inlets, fjords, coves),
how about we just map them as a single way across the mouth of the bay and
not as a way-polygon nor type=multipolygon relation? And then we set the
direction of the way such that the right-hand side of the way points to the
bay-side (just like the right-hand side of natural=coastline ways point to
the seaward side).

I know that some people would not like this at all because this is mapping
an arbitrary and fuzzy water boundary. But this avoids creating overlapping
relations and reduces the technical problem to just maintaining a single
way per bay. And for map users and renderers that care about the polygonal
extent of bays, either for labeling purposes or other applications (like
calculating approximate areas), constructing the approximate polygon for
the bay is an easier GIS operation (just concatenate that single way with
the adjacent bay-side coastline ways) than trying to guess that polygon
from a possibly poorly placed node.

If people think this is a good idea, we can even extend this to straits:
just map the ends of the strait with two such ways and combine them into a
relation and tag that relation with natural=strait. (At least this relation
will just contain 2 or a few simple ways instead of also including many
coastline ways.) I guess we would also need to have a new type=* for these
relations, perhaps type=water_extent or something else?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Add some tag to identify disputed borders

2018-11-12 Thread Eugene Alvin Villar
On Mon, Nov 12, 2018 at 9:23 PM Noémie Lehuby  wrote:

> Should we consider the dispusted=yes tag on boundary ways as a *de facto*
> standard and uniformize a few borders ? Should we create a proposal about
> this tag ?
>
> The borders data do not fit the doc and the statement from the Foundation
> and are not really usable right now...
>

My thinking on this is we should re-purpose the relation roles for this
sort of tagging. Right now we just copy the roles from type=multipolygon
relations (inner, outer) when we should be using something like the
following:

Hypothetical but real-life example:
Country A and Country B are disputing Territory C but currently Country A
controls it.
- The borders (ways) between A and B that are not in dispute should be
tagged with role=de_jure in both countries' boundary relations
- The line of control (so the border between B and C) should be tagged with
role=de_facto in both countries' boundary relations.
- The claimed border of B (so the "border" between A and C) should be
tagged with role=claimed in Country B's relation.

So if you want to draw borders as we currently draw them in OSM, just
pick-up the de_jure and de_facto role ways in the relations to build up the
boundary polygons.

But if you're from Country B and you want your claimed borders, just
pick-up the de_jure and claimed role ways in the relations to build up
Country B's boundary polygon.

The point is, "inner" and "outer" are really superfluous and can be
inferred from the geometry itself. So we should be using the relation role
to tag these sorts of things. And we can even use it to tag even more
complicated situations like if Territory C is split in control between A
and B.

I am open to alternatives to my suggested role names, by the way
("de_jure", "de_facto", "claimed").
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

2018-11-10 Thread Eugene Alvin Villar
Just a suggestion. Under the "Additional tags routinely used would include"
section, name=* and country=* are listed. I think the target=* tag (for the
receiving country) should also be included since it is already documented
in the amenity=embassy page. (I am not sure if "target" is a good term for
this tag but it is already in use so it might be okay to just adopt it as
is.)

On Sat, Nov 10, 2018 at 1:25 PM Allan Mustard  wrote:

> Kind folks,
>
> Comments on the proposal tapered off after Eugene's November 4 post, so
> I plowed through the comments and have rewritten and moved the
> amenity=consulate proposal to office=diplomatic.  You may find the
> rewritten proposal here:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
>
> Now, unless there is consensus that we need another two weeks of
> comment, I intend within the next two days to submit this proposal for a
> vote.  If you object to this and believe we need another two weeks of
> comments since amenity=consulate was moved to office=diplomatic, please
> say so!  I'm happy either way, and thank you all for your interest,
> ideas, and comments.
>
> Very best regards to all,
> apm-wa
>
> ___
> 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] visa offices tags

2018-11-07 Thread Eugene Alvin Villar
On Thu, Nov 8, 2018 at 9:29 AM Warin <61sundow...@gmail.com> wrote:

> On Nov 7, 2018, at 7:12 AM, Warin <61sundow...@gmail.com> wrote:
>
> 1) this is a commercial firm - not a government
> authority/branch/department/etc
> 2) it 'assist' people to obtain a visa
> 3) it is not at an airport/seaport/boarder
> 4) the visa is obtained before travel commences.
>
>
> It is an office you go to. You present documents, they ask questions, you
> answer, you pay a fee,
> the office fills out forms using that information provided (and they then
> send it off to an embassy/consulate)
> and then some time later you get a visa back from the office (but the visa
> itself is actually from the embassy/consulate).
>
> In the above situation, what is wrong with office=visa ? You apply to the
> office, they (usually) get you a visa.
>

Here, the Japanese consulate never accepts direct visa application and
instructs people to only submit visa applications through accredited travel
agencies.

On the other hand, many European consulates here contract a 3rd-party visa
processing company such as the aforementioned VFS Global to handle all visa
applications. These companies even have equipment to collect biometric data
such as photographs and fingerprints that will be forwarded to the
consulates together with the visa applications.

I would think that the first case should be tagged like other travel
agencies because visa handling is just one of their services (they also
arrange tours and purchase airline tickets). For the second case, they do
nothing else besides processing visa applications on behalf of the
contracting consulates. So they are not travel agencies. I think they
should indeed be tagged with something like office=visa or better yet
office=visa_processing so it is clearer.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging for an office of the local representative to parliament

2018-11-07 Thread Eugene Alvin Villar
On Nov 7, 2018 11:22 PM, "Allan Mustard"  wrote:

I like constituency_office.


+1

FWIW, Wikidata has settled on the term "constituency" for this political
concept (aka parliamentary seat, electoral district, legislative district,
etc.): https://www.wikidata.org/wiki/Q192611
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-11-01 Thread Eugene Alvin Villar
On Fri, Nov 2, 2018 at 3:12 AM Eugene Alvin Villar  wrote:

> On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard  wrote:
>
>> * shift to office=diplomatic and use the existing diplomatic=* additional
>> (secondary) tag to specify whether embassy, consulate, or other, then use
>> embassy, consulate and other as additional (tertiary) tags to specify
>> further the type of diplomatic or non-diplomatic mission as needed.
>>
>
> This is my preferred option for the following reasons:
> 1. It reuses the existing office=* primary key, which is already in use
> (for example, by the main OSM tile layer), as opposed to introducing
> diplomatic=* as a primary key. Furthermore, I am in favor of not having too
> many top-level primary keys unless they make a lot of sense (like
> healthcare=* which is a really broad category, so it makes sense to break
> this off as a primary key).
> 2. It does not clutter the overused amenity=* key and allows renderers and
> users to treat diplomatic and quasi-diplomatic objects in the same way and
> in a simpler way as opposed to tagging amenity=[embassy, consulate,  yet unspecified value>].
> 3. The three values for the secondary tag diplomatic=[embassy, consulate,
> other] plus adding further details to [embassy, consulate, other]=* makes
> it easy for mappers to add the level of detail they are comfortable with.
> If a mapper is unsure what the object is, they can just tag it as
> office=diplomatic. Then other slightly more knowledgeable mappers can
> specify diplomatic=*, which seems enough for most casual map users. Then
> other really knowledgeable mappers can further add [embassy, consulate,
> other]=* for even more detail and more specialized mapping applications.
>
> My second preferred option is amenity=diplomatic + subtags if people are
> really not too keen on office=diplomatic.
>

My first preferred option has another good reason (especially compared to
my second-preferred option):
4. It allows a backwards-compatible migration path for existing objects
that are already tagged with amenity=embassy: just add the
office=diplomatic and diplomatic=* tags and then we can delete
amenity=embassy once enough tools and map renderers have support for the
new tagging scheme. This is much less disruptive than moving things to
amenity=diplomatic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-11-01 Thread Eugene Alvin Villar
On Thu, Nov 1, 2018 at 11:14 AM Allan Mustard  wrote:

> * shift to office=diplomatic and use the existing diplomatic=* additional
> (secondary) tag to specify whether embassy, consulate, or other, then use
> embassy, consulate and other as additional (tertiary) tags to specify
> further the type of diplomatic or non-diplomatic mission as needed.
>

This is my preferred option for the following reasons:
1. It reuses the existing office=* primary key, which is already in use
(for example, by the main OSM tile layer), as opposed to introducing
diplomatic=* as a primary key. Furthermore, I am in favor of not having too
many top-level primary keys unless they make a lot of sense (like
healthcare=* which is a really broad category, so it makes sense to break
this off as a primary key).
2. It does not clutter the overused amenity=* key and allows renderers and
users to treat diplomatic and quasi-diplomatic objects in the same way and
in a simpler way as opposed to tagging amenity=[embassy, consulate, ].
3. The three values for the secondary tag diplomatic=[embassy, consulate,
other] plus adding further details to [embassy, consulate, other]=* makes
it easy for mappers to add the level of detail they are comfortable with.
If a mapper is unsure what the object is, they can just tag it as
office=diplomatic. Then other slightly more knowledgeable mappers can
specify diplomatic=*, which seems enough for most casual map users. Then
other really knowledgeable mappers can further add [embassy, consulate,
other]=* for even more detail and more specialized mapping applications.

My second preferred option is amenity=diplomatic + subtags if people are
really not too keen on office=diplomatic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-27 Thread Eugene Alvin Villar
On Sat, Oct 27, 2018 at 12:52 PM Allan Mustard  wrote:

> If my sense of growing consensus is correct, I suggest that diplomatic=*
> would include only [embassy, consulate, non-diplomatic].
>

Tagging something as office=diplomatic then diplomatic=non-diplomatic
sounds silly and oxymoronic. Why not simply diplomatic=other? Also we
should allow diplomatic=yes if the mapper doesn't know the exact type.
Therefore diplomatic=[embassy, consulate, other, yes]. (So
diplomatic=embassy applies to regular embassies, Commonwealth of Nations'
high commissions, Vatican apostolic nunciatures, etc.)


> It also offers a potentially neat solution for dealing with the
> non-diplomatic representations of Taiwan and the United States in each
> others' countries
>

I think we should call a spade a spade. While the Taipei Economic and
Cultural Representative Office (TECRO) in the U.S. and the American
Institute in Taiwan (AIT) are not de jure embassies in order to adhere to
the so-called "One China" policy, these offices are de facto embassies with
their head officers having (I think) ambassadorial rank with largely the
same rights and privileges. Since OSM mapping the mainland Chinese
territory is already an illegal activity w.r.t. the PRC's laws, I don't
think assigning the diplomatic=embassy tag to the ROC-related diplomatic
representative offices would make things worse and would cause a diplomatic
incident. (Well, you as a diplomat, probably cannot say so because you are
bound by your Department of State's adherence to the One China policy, but
almost every other mapper isn't a diplomat so we are free to map however we
want. [I can already see the BuzzFeed headline: "U.S. envoy to Turkmenistan
admits Americans have diplomatic relations with Taiwan".])


> and other non-diplomatic representations, such as the Taliban office in
> Doha.
>

(This sounds interesting! *[Goes and browses the "Taliban in Qatar"
Wikipedia article]*)


> I think limiting the number of options for diplomatic=* to three would
> simplify mapping (and avoid confusing mappers not steeped in the lore of
> diplomacy); the particular type of diplomatic mission is in any case
> reflected in the name=* tag and needs not be duplicated in the diplomatic=*
> tag (e.g., "High Commission of Malaysia", "Embassy of Poland", "U.S.
> Interests Section", "Consulate General of Japan").  If the status of a
> mission changes (e.g., the upgrade of the U.S. Interests Section in Havana
> to an embassy), changing the name would suffice; no re-tagging would be
> necessary.
>

I generally agree with this idea, but with the Taiwanese caveat I mentioned
above.


> P.S.  Regarding the question posed overnight as to whether one may simply
> drop in on an ambassador's residence, any of you who are contributing
> substantively to this discussion are welcome to drop by my residence in
> Ashgabat any time you are in town :-)  Just please call ahead to make sure
> I'll be home.
>

That's a great offer! Although I probably would not be visiting Central
Asia in the foreseeable future; my passport is in the bottom half of the
Henley Passport Index so I don't have as much opportunities to travel as
citizens in other countries. :)

BTW, for other people on this thread who are not aware: yes, Allan, the
U.S. ambassador to Turkmenistan, is an active OSM mapper and has
substantially contributed to mapping Turkmenistan in OSM outside of his
official duties. https://wiki.openstreetmap.org/wiki/Turkmenistan
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Standardizing Mapillary tags and keys

2018-10-26 Thread Eugene Alvin Villar
On Sat, Oct 27, 2018 at 6:34 AM Christopher Beddow <
christop...@mapillary.com> wrote:

> Is there any critique of these ideas?
>

I think these tags are only appropriate as changeset tags and never as tags
on actual map objects (nodes, ways, relations).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Eugene Alvin Villar
On Sat, Oct 27, 2018 at 4:32 AM Daniel Koć  wrote:

> W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze:
>
>
> On the other hand. diplomatic offices and services encompass a range that
> is much too narrow such that I don't think having diplomatic=* as a primary
> key seems appropriate. I would prefer if we just have the office=diplomatic
> + diplomatic=* tag combination instead. This nicely parallels and
> complements the office=government + government=* tag combination[1] that we
> already have, but instead applying to foreign governments.
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:office=government
>
>
> It matches nicely, indeed, but on the other hand this is probably not an
> office:
>
> https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Dambassadors_residence
>

True, this is not an office. An ambassador/diplomat's residence enjoys the
same extraterritorial rights and privileges as other diplomatic facilities
like embassies and consulates.

But this actually implies that diplomatic=* itself is not a good primary
key. You really do not expect citizens of either the host or the sending
country to just visit an ambassador's residence unannounced and without
invitation. (Maybe you can visit it if the ambassador is hosting a party
and you're invited.) Therefore, such residences should be rendered
differently from embassies and consulates and more like how other notable
residences are rendered (maybe like the White House or Buckingham Palace).
This implies that using diplomatic=ambassadors_residence needs a different
primary tag than office=diplomatic depending on the actual form of the
residence. The residence can be a manor (historic=manor) such the U.S.
ambassador's residence in Buenos Aires[1], a regular house (building=house)
such as the Argentinian ambassador's residence in London[2], or a hotel
suite (tag nonexistent, unless we use the Simple Indoor Tagging scheme)
such as the U.S. ambassador to the UN's residence in New York[3].

[1] https://en.wikipedia.org/wiki/Bosch_Palace
[2] https://en.wikipedia.org/wiki/49_Belgrave_Square
[3]
https://en.wikipedia.org/wiki/Residence_of_the_United_States_Ambassador_to_the_United_Nations
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Eugene Alvin Villar
office=government
On Sat, Oct 27, 2018 at 2:53 AM Paul Allen  wrote:

> If you can come up with a better value than "diplomatic" then do so.  If
> you don't like it being under
> the office key, maybe have diplomatic=* as the primary key rather than a
> secondary key under
> office (although that may well contravene OSM naming conventions I've
> never heard of).  But if
> we can have healthcare=doctor as an alternative to amenity=doctors or
> office=doctor then I don't see why
> diplomatic=embassy would be a bad idea.
>

In my opinion, having healthcare=* as a primary key makes a lot of sense
because the medical and healthcare profession and services encompasses a
really wide range of "amenities" from doctor's offices where you can visit
for consultations, to dentists, to hospitals with emergency and surgery
facilities, to dialysis centers, to veterinarians, and even to alternative
medical facilities like acupuncture clinics if we really want to go down
that path.

On the other hand. diplomatic offices and services encompass a range that
is much too narrow such that I don't think having diplomatic=* as a primary
key seems appropriate. I would prefer if we just have the office=diplomatic
+ diplomatic=* tag combination instead. This nicely parallels and
complements the office=government + government=* tag combination[1] that we
already have, but instead applying to foreign governments.

[1] https://wiki.openstreetmap.org/wiki/Tag:office=government
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-26 Thread Eugene Alvin Villar
On Fri, Oct 26, 2018 at 10:27 AM Warin <61sundow...@gmail.com> wrote:

> In OSM I would expect the term government not to be a foreign government
> but a resident one.
>

Uniquely, Italy hosts its own embassy to the Holy See (aka Vatican City).
So technically, you could use "government" for that single embassy. ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

2018-09-23 Thread Eugene Alvin Villar
On Mon, Sep 24, 2018, 7:52 AM Martin Koppenhoefer, 
wrote:

> I’ve recently used building=fast_food_restaurant
> but it is not used very often yet.
>

Can you care to explain why building=retail is not enough detail? I would
think that a combination of building=retail + amenity=fast_food (whether on
the same polygon or on separate polygon + interior node) is already
sufficient.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Topographic Prominence for Peaks

2018-09-23 Thread Eugene Alvin Villar
On Mon, Sep 24, 2018, 9:29 AM Bill Ricker,  wrote:

> Is the OSM primary DB the right repository for this?
> Have we accepted being the repository for everything that anyone wants to
> map?
> (I don't remember hearing a change from "no".)
>

If people are already mapping whether an amenity=fuel is dispensing a
particular octane of fuel, then mapping topographic prominences is surely
acceptable, especially since prominence is certainly a more geospatial
concept than fuel octanes.

One thing I am quite sure of that is true in OSM is that we (within reason)
don't prevent people mapping the things they are interested in whether they
are peak baggers interested in mountain height stats, pet lovers mapping
dog-friendly amenities inside public parks, or conservationists mapping
species=* for individual notable trees.

But if you insist that this prominence data is out-of-scope for the OSM DB,
then at least consider advocating that these peaks and mountains be tagged
with their corresponding Wikidata items via the wikidata=* tag. Most
Wikidata items on peaks and mountains already have their topographic
prominence encoded as can be seen for this Wikidata item for the Matterhorn
(prominence is 1031m): https://www.wikidata.org/wiki/Q1374

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


Re: [Tagging] addr:street=* combined with place=square, name=*

2018-08-16 Thread Eugene Alvin Villar
On Thu, Aug 16, 2018 at 3:45 PM Martin Koppenhoefer 
wrote:

> I know in the US there are distance based housenumbers, and also in Rome
> there is one single street which has distance based numbering, still the
> vast majority of distance based address indications around here are _not_
> housenumbers.
>

So how would you tag these distance-based numbers in OSM without using
addr:full? addr:housenumber seems to me to be the best fit and without
needing to introduce yet another tag. I have certainly used
addr:housenumber to tag these types of numbers in my country and I am glad
to read that people in other countries think the same, which makes me think
that, while this is not 100% logically correct, it makes sense, in a way.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] place nodes for continents?

2018-08-07 Thread Eugene Alvin Villar
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


Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Eugene Alvin Villar
On Tue, Jun 19, 2018 at 6:20 AM, Paul Allen  wrote:

> On Mon, Jun 18, 2018 at 10:27 PM, Frederik Ramm 
> wrote:
>
> Others have qualms about signing up to an American social network platform
>> just
>>
> to participate in OSM discussions (remember - if the product is free, you
>> are the
>
> product).
>
>
> From what I have read, others in the IT community have qualms about
> keeping their
> repos on github now it's been bought by Microsoft.  See, for example,
> https://www.theregister.co.uk/2018/06/04/microsoft_buys_github/ and the
> associated
> comments (almost all negative, some so vituperative they would make Linus
> Torvalds blush).
>
> It remains to be seen how many of those are willing to walk the walk as
> well as talk
> the talk.  However, I suspect a significant number have at least
> duplicated their
> repos elsewhere.  Some claimed they were going to copy their repos
> elsewhere
> and poison the copies on github to leave a nice surprise should Microsoft
> try
> to harvest their work.
>
> I'm not saying Microsoft will screw up github (although history shows
> that's what
> usually happens to their acquisitions).  I'm not saying Microsoft will
> steal people's
> work (they could do that without buying github), although I remember
> Stacker's
> Doublespace product and what happened to it.  I'm not saying Microsoft will
> embrace, extend and extinguish github, but they have a history of doing
> that.  I'm
> just pointing out that people have other reasons for avoiding github these
> days,
> and its alternatives don't have such sophisticated comments/discussion
> capability,
> so maybe that's another reason to move as much discussion as possible to
> the
> mailing list.
>

Just to comment on the Microsoft side angle here. Inasmuch as history has
been very unkind to Microsoft with respect to their treatment of open
source communities and technologies in the past (Linux, Mozilla, etc.),
there is reason to believe that they will do good with their acquisition of
GitHub moving forward and will not screw it up like the way Oracle screwed
up the Sun Microsystems acquisition. But don't take it from me, take it
from the Executive Director of the Linux Foundation himself:
https://www.linuxfoundation.org/blog/microsoft-buys-github-the-linux-foundations-reaction/

And here in OSM, the community has greatly benefited from using Microsoft's
Bing satellite imagery since 2010, and Microsoft has even recently granted
use of their Streetside imagery for use in OSM as well (no doubt to
continue countering Google). And Microsoft's Bing has been a Gold Corporate
Member of the OSM Foundation since 2017. So this doubt heaped upon
Microsoft is hopefully no longer without basis.

(But yeah, keep discussions on mailing lists as much as possible.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] brand=* necessary?

2018-05-10 Thread Eugene Alvin Villar
This whole discussion reminds me of the following passage from Lewis
Carroll's Through the Looking-Glass:

The name of the song is called ‘Haddocks' Eyes.’”
>
> “Oh, that's the name of the song, is it?" Alice said, trying to feel
> interested.
>
> “No, you don't understand,” the Knight said, looking a little vexed.
> “That's what the name is called. The name really is ‘The Aged Aged Man.’”
>
> “Then I ought to have said ‘That's what the song is called’?” Alice
> corrected herself.
>
> “No, you oughtn't: that's quite another thing! The song is called ‘Ways
> And Means’: but that's only what it's called, you know!”
>
> “Well, what is the song, then?” said Alice, who was by this time
> completely bewildered.
>
> “I was coming to that,” the Knight said. “The song really is ‘A-sitting On
> A Gate’: and the tune's my own invention.”
>


On Thu, May 10, 2018 at 3:44 PM, Leon Karcher 
wrote:

> Hello,
>
> While I was filling up this list
>  on the wiki with
> information, someone on the talk page asked why I was adding brand=* to
> every object. His argument was that the brand tag is a duplicate of the
> name tag in most cases and I should only add it if the name differs. (see
> example ) I kind of see
> his point, but what do you think? Should we only add a brand tag if it
> differs from the name?
>
> I thought adding brand= to all 'branded' objects would be helpful because
> it goes hand in hand with brand:wikidata= which I would add to all of them.
>
> Greetings,
> Leon.
>
> ___
> 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] Coastal beach definition for mapping.

2018-04-04 Thread Eugene Alvin Villar
On Tue, Apr 3, 2018 at 9:22 PM, Martin Koppenhoefer 
wrote:

> the coastline should represent the limit of the sea, in case of a river
> flowing in, people look at the level of salt in the water and whether the
> level of the river is influenced by tides (afaik)
>

It seems some mappers go to the extreme opposite and map the coastline
across the mouth of an estuary that is clearly part of the ocean:

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


Re: [Tagging] Tagging request: unnecessary admin_level tags

2018-03-10 Thread Eugene Alvin Villar
On Sun, Mar 11, 2018 at 12:41 AM, André Pirard 
wrote:

> Hi all,
>
> Please all, take a very attentive look at this.
> Please note the subject change: unnecessary.
> Please note the disambiguation boundary vs borderline.
>
> The problem with admin_level tags is that numbers need to exist to *be **
> able* to nest boundaries and hence that only administrative boundaries
> are nestable.
> That problem does not exist with subarea relation roles [...]
>

Subareas will not work for my country. We generally have the following
hierarchy: region > province > city/municipality.

However, we have two cases where a city inside a province is part of a
different region from the rest of the cities and municipalities of that
province. In this case, using admin_level=* to properly indicate the
administrative boundaries in type=boundary + boundary=administrative
relations is unavoidable.

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


Re: [Tagging] part_of:wikidata key

2017-11-28 Thread Eugene Alvin Villar
On Wed, Nov 29, 2017 at 4:29 AM, Kevin Kenny 
wrote:

> Given that the Overpass API exists, do we have a worked example
> here to demonstrate that external tools have a ready way of accessing
> 'wikidata' tagged items within OSM?
>

This is quite easy to implement using the Overpass API. In fact, I
developed a web map of Philippine heritage sites that pulls data from
Wikidata and uses the Overpass API to query the wikidata=* tags in OSM to
display the actual geometry of the heritage sites on the web map. Here's an
example: https://wmph.github.io/eph-heritage-sites-map/#Q40734701
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] part_of:wikidata key

2017-11-28 Thread Eugene Alvin Villar
On Wed, Nov 29, 2017 at 6:29 AM, Christoph Hormann  wrote:

> This is just a question on editors managing that.  Right now the
> inheritance of IDs is usually not a conscious choice of the mapper but
> if this is deemed desirable this could be changed.
>
> [...]
>
> OSM recruits mappers to map the verifiable
> world, we do not require them to also research secondary source
> references in wikidata to make sure they correctly maintain wikidata
> IDs.
>

So you want us to develop OSM tools and improve editors to preserve and
manage OSM ID inheritance/permanence. But this is not a simple problem to
solve.

On the other hand, you deem maintenance of Wikidata IDs in OSM a huge
bother. But we can create OSM tools and improve editors as well to help
manage this. I imagine that this is a simpler problem to solve than the
first problem of OSM ID permanence.

Also, we don't require mappers to add wikipedia=* tags to objects they map
in OSM, or to maintain these Wikipedia tags so that they remain accurate
and updated. Other mappers are free to update and maintain these tags. This
is accepted practice and there is no huge outcry against adding more
wikipedia=* tags.

This accepted practice with respect to wikipedia=* tags can be equally
applied to wikidata=* tags. We won't require mappers to do research to add
this tag, but other mappers are free to add/maintain these as well. I see
no huge problem with this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] part_of:wikidata key

2017-11-28 Thread Eugene Alvin Villar
On Tue, Nov 28, 2017 at 11:02 PM, Christoph Hormann  wrote:

> > * Wikidata is definitely not suited as an universal meta-database
> > connecting OSM with other open data sets.  This is because of the
> > Notability concept
> > (https://www.wikidata.org/wiki/Wikidata:Notability) which practically
> > means the vast majority of the >500 million tagged features in OSM
> > will never be able to get a Wikidata ID and will therefore never be
> > able to be connected to other data sets through Wikidata.
>

I don't think this is a valid reason for avoiding linking to Wikidata. If
Wikidata will not (or never?) have an item corresponding to an object
mapped in OSM and that OSM-mapped object in turn has a corresponding item
in another database, then we could conceivably link to that database
directly from OSM via another tag. But I think this occurs only because
that OSM-mapped object is only referenced in that one other database. In
this case, I agree that linking to Wikidata provides not much value.

However, once two or more other authoritative databases refer to the same
object, then it already passes the Wikidata threshold for notability. In
this case, it makes better sense to create the Wikidata item for that
object, link the Wikidata item to the other databases by adding their
identifiers, and then have OSM link to the Wikidata item instead of OSM
linking to the other databases directly. Note that this database-linking is
just one value-add that Wikidata provides. Wikidata by itself can also
provide other data about the object itself and is not just a store for
linking other data sets.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] part_of:wikidata key

2017-11-28 Thread Eugene Alvin Villar
On Tue, Nov 28, 2017 at 10:36 PM, Kevin Kenny 
wrote:

> ... but I don't believe that I've ever actually seen an application that
> uses it, and don't have a real understanding of how it is used and what can
> be done with it that cannot be done without it.


Like OSM, you don't immediately see that an application uses Wikidata until
you read the fine print or dig deeper. For an example, the Moving Map
in-flight application of Eurowings "is powered by the magic of Wikidata":
https://pbs.twimg.com/media/DAkpeFQWsAApvKI.jpg

There are many other examples of applications, tools, and websites that use
Wikidata. You just won't see it at first glance.

To answer your second point, sure, you don't really need Wikidata and you
can directly go to the source databases that Wikidata links to, but
Wikidata is increasingly becoming a central hub for linking various
disparate databases together via their primary identifiers. In addition,
Wikidata is also increasingly becoming a go-to knowledge base in and of
itself. Google, in fact, shut down the Freebase project that they acquired
in favor of Wikidata.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Multiple offices at the same address - (Multiple values for one key)

2017-10-30 Thread Eugene Alvin Villar
On Mon, Oct 30, 2017 at 9:39 PM,  wrote:

> The main critisism is that we map the same address multiple times, but
> in fact they are different things, we have the "Postal Address" at the
> entry and then a node for each buisiness/shop at that address, they all
> share addresses, but represent different things.
>

I'm not sure how it is in your locality, but in my country, offices can be
further "addressed" by using addr:unit=* tags which specify which
unit/space/room the office occupies within the building. Furthermore, if
this is a multi-level building, we can further specify the floor number of
the office via the addr:floor=* (human-readable) and level=*
(machine-readable) tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Multiple offices at the same address - (Multiple values for one key)

2017-10-28 Thread Eugene Alvin Villar
On Oct 27, 2017 8:03 AM, "Colin Smale"  wrote:

Time for a more philosophical discussion... What is the function of this
thing we call "address"? Is it to identify a premises? Is it to describe a
premises? Does it refer to the whole premises, or just the bit with the
front door or letter box? Or is it "where to deliver post"?

This is a long-standing issue in OSM. An address is either (1) a feature
that can be mapped on its own right and therefore should only exist once on
the map, or (2) an attribute or property of some other feature in OSM and
therefore can be added to multiple objects that share the same address.
Both types of schemes exist on the map right now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] man_made=tunnel

2017-06-13 Thread Eugene Alvin Villar
On Mon, Jun 12, 2017 at 11:30 PM, Philip Barnes 
wrote:

> I would map those as separate tunnels and only map them as a single tunnel
> is multiple ways share the same bore.
>

I think this goes to the question of whether we want man_made=tunnel to map
a physical tunnel (that may contain a dual carriageway) or a tunnel system
(that is given just a single name).

To give a bridge analogy, how do you map the Hungerford Bridge and Golden
Jubilee Bridges system in London? The Hungerford Bridge is a railway bridge
flanked on two sides by the Golden Jubilee Bridges, which are a pair of
footway bridges. The three bridge carriageways are separate (you cannot
step from one bridge to the other). However, all three share the same
foundation piers, so in a sense, the whole structure is a single
"mega-bridge".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] OSM+Wikidata intro video

2017-06-07 Thread Eugene Alvin Villar
Please clarify the license of this combined database and any data returned
from a SPARQL query. I assume any data returned is under ODbL since it
contains data derived from the OSM database. But this is not indicated
anywhere in the Query Service and is not included as metadata in the
returned dataset.

If this is not corrected, this Query Service will unfortunately be listed
under the following page:
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution



On Wed, Jun 7, 2017 at 12:07 PM, Yuri Astrakhan 
wrote:

> The RDF/SPARQL database that has both OpenStreetMap and Wikidata data in
> the same table is alive and well, and getting considerable usage. To make
> it better understood by even wider community, I made an intro video with
> some examples.  This database mostly benefits the object tag validation and
> research at this moment, as its geometry support is still in the works.
>
> The wiki page has also seen a lot of cleanup, explaining how quality
> control can be done. I hope that other tools such as JOSM and especially
> MapRoulette will be able to use it directly. Also, please contribute your
> SPARQL queries to the wiki page.
>
> https://www.youtube.com/watch?v=KDiKzbuIhts
> https://wiki.openstreetmap.org/wiki/Wikidata_RDF_database
>
> ___
> 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] natural=bay on areas

2017-03-29 Thread Eugene Alvin Villar
On Thu, Mar 30, 2017 at 4:41 AM, Juan Pablo Tolosa Sanzana <
jptolosanz...@gmail.com> wrote:

> An exact limit between the open ocean and a sheltered coast is too
> arbitrary as natural feature. It seems a political issue. You can use
> boundary=maritime + border_type=baseline for excluding internal waters from
> the open ocean, according of laws of the country. Check the article
> https://en.wikipedia.org/wiki/Internal_waters
>

Speaking of maritime boundaries and bays and estuaries, the Rio de la Plata
estuary between Argentina and Uruguay is currently modeled in OSM as
*inside* the coastline. If you look at the OSM default carto layer at zoom
5 and lower, where inland waterbodies are not rendered, Montevideo and
Buenos Aires appear to be landlocked inland cities, which doesn't look
right.[1] (See the attached image.) The coastline there follows the UNCLOS
claimed baseline which isn't right because UNCLOS allows countries to
specify a baseline separate from the coastline that encloses parts of the
sea/ocean (thereby making those parts internal waters of the country) when
it meets certain geometric conditions. I think the coastline between
Argentina and Uruguay should include most of the Rio.

If we follow the practice of mapping the coastline along the claimed
baseline like in the Rio de la Plata elsewhere in the world, then the Gulf
of Sidra in Libya[1] would be considered as an inland waterbody, which does
not make sense. Note that the United States have protested as excessive
both the claimed baseline of Libya in the Gulf of Sidra (this resulted in
the Gulf of Sidra incident in 1981) and the joint claimed baseline of
Argentina and Uruguay in the Rio de la Plata.

[1] http://www.openstreetmap.org/#map=5/-35.335/-56.382
[2] http://www.openstreetmap.org/#map=5/31.961/17.249
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] address property of features

2017-03-19 Thread Eugene Alvin Villar
On Sun, Mar 19, 2017 at 12:56 AM, Tristan Anderson <
andersontris...@hotmail.com> wrote:

> Either tag the store or the entrance, not both.
>

This goes back to the long unresolved question on whether addresses are:
(1) features in themselves (so each address must be uniquely represented in
OSM and never duplicated), or (2) simply attributes of other OSM features
(so tag multiple objects with the same address if they have the same
address).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

2017-03-08 Thread Eugene Alvin Villar
On Thu, Mar 9, 2017 at 1:32 AM, Martin Koppenhoefer 
wrote:

> there are only 33 991 objects with a building:min_level tag now
>

I'm not now commenting on whether the proposal is good or not, but other
redefinition proposals have been shot down for numbers much less than the
number given in the argument above.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] self-service laudry machines a camp and caravan sites

2017-02-18 Thread Eugene Alvin Villar
>
> Laundromat:foobar=n  scheme.
>
> Laundromat:10kg_dryer=8
> Laundromat:20kg_dryer=2
> Laundromat:10kg_sidewasher=3
> Laundromat:20kg_sidewasher=1
> Laundromat:shoe_washer=1
> Laundromat:shoe_dryer=1
>

I'm not so sure that tagging minutiae like this is appropriate for OSM,
which is really a geo-database and not a business/services directory. This
is like tagging Italian restaurants with something like the following
(which I hope nobody thinks is a good idea):

pasta:spaghetti:tomato=yes
pasta:spaghetti:pesto=yes
pasta:ravioli=yes
pizza:crust=hand-tossed

I think it is enough just to indicate if a laundromat is self-service,
coin-operated, full-service, etc. and not bothering to classify the
available washing machines. I know tagging information like these is useful
but should these really be included in OSM? Maybe we ought to have an
OpenBusinessDirectory sister project or something:
https://wiki.openstreetmap.org/wiki/Open_Business_Directory
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Non-geometrical ways in boundary relations

2017-01-26 Thread Eugene Alvin Villar
On Thu, Jan 26, 2017 at 8:02 PM, Colin Smale  wrote:

> Tom, I think we need to have consensus about what we mean by admin centre.
>
+1

In my area, a local mapper also had the idea of adding the town hall
building into the boundary relation. I did not revert this even though this
resulted in the default map layer seemingly showing the town hall as an
enclave within the administrative area due to the aforementioned catch-all
rendering.

Three things to discuss:

1. I think we need to discuss what the admin_centre relation role is
intended for. I would generally prefer this to be used exclusively for the
place=* node owing to existing tagging practices and software support.

2. I also agree that the current default map layer catch-all rendering
instead of whitelisting should be updated. If ever we add new accepted
relation roles for the boundary relation that accepts ways, then the
catch-all rendering would become wrong. But this discussion should be done
at the openstreetmap-carto GitHub repository.

3. Finally, I do think it is valuable to explicitly relate the city/town
hall or state/province capitol building (or some other relation/way/node
representing the administrative area's main office or seat of
administration) with the boundary relation. As mentioned by Colin, there
are cases where the city/town hall is not located within the administrative
area so you cannot do some sort of spatial query to link them together
outside of OSM. Currently, OSM does not have a tagging system to uniquely
tag all administrative areas so that you can link the boundary relation and
the city/town hall only by tagging alone as opposed to adding the city/town
hall as a member of the boundary relation (or adding both into a super
relation representing the administrative unit as an abstract entity).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Landuse=grass - boots on change to wiki

2017-01-09 Thread Eugene Alvin Villar
On Mon, Jan 9, 2017 at 9:28 AM, Warin <61sundow...@gmail.com> wrote:

> If the grassed area needs to be tagged then tag WHAT IS THERE ...
> landcover=grass (or natural=grass) ... the land is use in a highway
> situation to provide safety for the highway users .. it is not for the use
> of the grass!
>

I agree with not using landuse=grass when tagging grassy land cover.
landcover=grass should be perfect for this.

Unfortunately, landuse=grass is rendered in the default OSM map layer while
landcover=grass isn't. So to encourage proper tagging, we should make sure
that landcover=grass is being rendered. Taginfo says that no project uses
landcover=grass:
https://taginfo.openstreetmap.org/tags/landcover=grass#projects
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coworking space: amenity vs. office ?

2017-01-04 Thread Eugene Alvin Villar
On Thu, Jan 5, 2017 at 8:05 AM, Greg Troxel  wrote:

> Arguably, if the coworking space intened to accomodate professional
> carpenters who worked for different companies, maybe that would be
> coworking.  But really coworking is about something that feels like an
> office with coworkers and support services, but is shared by poeple that
> work for different companies or are perhaps self-employed.   To me, a
> core part of coworking space is that most(?) of the people using it view
> it as the physical location of their main employment.
>

+1

I've visited a couple of coworking spaces in my country and have looked at
websites of several others. Coworking spaces are targeted towards
white-collar office desk jobs, usually for freelancers who are into graphic
design, software development, or other online-based outsourcing jobs.
Students who need a place to study or do projects also go to coworking
spaces. Clients of coworking spaces typically need a desk, Wi-Fi Internet
access, and probably coffee or tea for refreshment. You can typically rent
a desk or a small office space by the month, or just rent a desk for the
day, hot-desking-style.

I can find arguments favoring either amenity=* or office=* so I don't
really care which of the two is used. But I think *=coworking is better
than *=coworking_space since coworking is really tied to the definition of
renting some office desk space in order to study or work. Plus it's shorter
to type.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Artworks inside the Louvre

2016-07-23 Thread Eugene Alvin Villar
My initial reaction, and one that you've mentioned, is to add indoor=yes.
But then, you need to make some specific rules on which objects tagged
indoor=yes get hidden in rendering (like artworks?) and those that still
probably deserve to be rendered (like cinemas inside shopping malls?).

On Sun, Jul 24, 2016 at 6:42 AM, Daniel Koć  wrote:

> We are on the way to render artworks on osm-carto (default map layer on
> main website), but during testing phase I've found that in Louvre they are
> tagged not only on the exterior, but also some of them are inside the
> building (as part of the permanent exposition, I guess).
>
> This made me think if - and how - should we tag such features? Current
> definition is laconic and does not help in this case ("A tag for public
> pieces of art"). Should we just add "indoor=yes" (currently 67k+ uses),
> find new tagging scheme or just introduce a policy which doesn't let
> tagging them?
>
> It is important for a rendering strategy - we're not able to recognize
> which are visible outside and which are not and it creates a visual mess:
>
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/2236#issuecomment-234687333
>
> --
> "Low, low, low..." [M. Kempa]
>
> ___
> 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] importance=* tag (for transportation etc)

2016-03-21 Thread Eugene Alvin Villar
On 3/22/16, Janko Mihelić  wrote:
> ned, 20. ožu 2016. 04:55 John Willis  je napisao:
>
>>
>> This entire subject about mountains is the most infuriating topic I have
>> ever dealt with as an OSM mapper.
>>
>
> You actually already have all the data you need, and it's on Wikidata. Just
> look at the number of articles about each peak, and render them according
> to that. More articles=rendered at lower zooms. Problem solved, and you
> don't have to put vague tags in OSM.

I'd like to note that Nominatim already uses Wikipedia via the
wikipedia=* tags as an indicator of relevance or importance (by
counting Wikipedia article links) and there is a proposal to also
eventually include Wikidata too:
https://github.com/twain47/Nominatim/issues/299

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


Re: [Tagging] [OSM-talk] If a school is a shelter when a disaster happens...

2015-12-31 Thread Eugene Alvin Villar
On Thu, Dec 31, 2015 at 3:59 PM, Martin Koppenhoefer  wrote:

> besides the precise tagging (social facility or emergency), I just want to
> point out that you can have 2 main tags for the same area (overlapping),
> just not on the same object.
> You could for instance have a way tagged as school and have this same way
> as an outer member for a multipoligon relation which gets the shelter tags.
>

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


Re: [Tagging] Lights other than highway=street_lamp

2015-12-15 Thread Eugene Alvin Villar
Try the following proposed light source tagging scheme:
http://wiki.openstreetmap.org/wiki/Proposed_features/Key:light_source

The scheme's primary key, light_source=*, is currently used 2854 times:
http://taginfo.openstreetmap.org/keys/light_source

On Wed, Dec 16, 2015 at 7:28 AM, Mike Thompson  wrote:

> How are lights other than street lights, such as those  used to illuminate
> the playing field at stadiums, tagged?
>
> Mike
>
> ___
> 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] Named junctions

2015-11-05 Thread Eugene Alvin Villar
This has been discussed somewhat last year:
https://lists.openstreetmap.org/pipermail/tagging/2014-July/018517.html
https://lists.openstreetmap.org/pipermail/tagging/2014-September/019338.html

See also this tagging proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named


On Thu, Nov 5, 2015 at 11:32 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> I've learned that in some countries each junction has a name/ref and
>
> that these are used for navigation.
>
> At small junctions you may just find a node with a name tag,
>
> but at larger junctions or roundabouts I see all kinds of "tricks"
>
> to place an object with a name.
>
>
> I'd suggest to use a node tagged
>
> place=junction
>
> with name=* or ref=*
>
> for this. What do you think?
>
>
> Gerd
>
> ___
> 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] Adding floor location information

2015-09-29 Thread Eugene Alvin Villar
On Tue, Sep 29, 2015 at 7:38 PM, Warin <61sundow...@gmail.com> wrote:

> On 29/09/2015 9:10 PM, Eugene Alvin Villar wrote:
>
>> On 9/29/15, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
>>
>>> b) indicating floor level in the mall is useful, and looking at the wiki
>>>> shows that the tag addr:floor=* is suggested - but it only has 158 uses
>>>> -
>>>> which is amazingly small. is this the right key to indicate what floor a
>>>> shop is on?
>>>>
>>> addr:floor is about the address, "level" is used more often.
>>>
>> When addr:floor=* was first proposed a few years ago, it had almost
>> the exact same semantics as level=*.
>>
>> Now, I'm using addr:floor=* to indicate the human-readable floor
>> information while level=* is used for the machine-readable number. For
>> example: addr:floor=Mezzanine Level and level=0.5
>>
>>
>>
> That is interesting. I like some of it.
>
> However .. do you have to have addr:floor= and level= on all the features?
>
> Would it not be better to have one declared relationship between the two,
> and then use whatever the mapper finds most convent on the individual
> features?
>
> The eventual render would then present the user with the add:floor  for
> their information and use the level= for routing (up/down/same level).
>

It would be hard to pin down a declared relationship. You might have to do
that on a building-by-building basis. For example, some buildings don't
have a 13th floor. Others don't have a 4th floor. And you also have
differing conventions per country: in the United Kingdom, the 1st floor is
the equivalent of the 2nd floor in the United States although both are
level=1. Furthermore, the human-readable information may be presented in
different ways. For example, a building may have a "Level 8" but on the
next building it would be "Eighth Floor".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding floor location information

2015-09-29 Thread Eugene Alvin Villar
On 9/29/15, Martin Koppenhoefer  wrote:
>> b) indicating floor level in the mall is useful, and looking at the wiki
>> shows that the tag addr:floor=* is suggested - but it only has 158 uses -
>> which is amazingly small. is this the right key to indicate what floor a
>> shop is on?
>
> addr:floor is about the address, "level" is used more often.

When addr:floor=* was first proposed a few years ago, it had almost
the exact same semantics as level=*.

Now, I'm using addr:floor=* to indicate the human-readable floor
information while level=* is used for the machine-readable number. For
example: addr:floor=Mezzanine Level and level=0.5

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


Re: [Tagging] Adding floor location information

2015-09-29 Thread Eugene Alvin Villar
On Wed, Sep 30, 2015 at 5:40 AM, John Willis  wrote:

> I think most business/dwellings don't have floor in their address, which
> is why its usage (152 for points) is so low.
>

Actually, Taginfo says that addr:floor is used 4314 times (3162 on nodes):
http://taginfo.openstreetmap.org/keys/addr:floor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding floor location information

2015-09-29 Thread Eugene Alvin Villar
On Wed, Sep 30, 2015 at 5:40 AM, John Willis  wrote:

> Isn't addr:* for its postal / legal location definition?
>
> What if the floor level is not part of its address? I think most
> business/dwellings don't have floor in their address, which is why its
> usage (152 for points) is so low. Most buildings hide that information in
> its room number (1222 =floor 12 room 22).
>

But in some countries, the floor information is actually part of the
address. Here are a couple of examples from my country:

*German Embassy Manila*
25/F Tower 2, RCBC Plaza, 6819 Ayala Ave (cor Sen. Gil Puyat Ave), Makati
City, Metro Manila
http://www.manila.diplo.de/Vertretung/manila/en/03/Oeffnungszeiten/Oeffnungszeiten.html

*Myanmar Embassy*
8th Floor, Xanland Centre, 152 Amorsolo Street, Legaspi Village, Makati
City, Metro Manila
http://www.visamyanmar.com/myanmar_embassies.htm

So addr:floor=* makes a lot of sense.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] waterway=derelict_canal

2015-08-26 Thread Eugene Alvin Villar
On Wed, Aug 26, 2015 at 9:16 PM, Chris Hill o...@raggedred.net wrote:

 To leave a tag that describes it as a pub (when it is not) then add
 another tag that says it is not a pub is plain daft.


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


Re: [Tagging] Disputed area

2015-07-22 Thread Eugene Alvin Villar
But that proposal intends to encircle disputed territories which is
different from specifying disputed parts of otherwise OK boundaries in
a normal boundary relation.

I have already considered the impact on current tools and my solution
is to introduce a new relation type: boundary=administrative_v2.

My idea is that by only getting the boundary relation for India, for
example, you are able to create a map similar to the following
(imagine without the state borders):
https://en.wikipedia.org/wiki/File:India-locator-map-blank.svg

On 7/22/15, Arch Arch 7h3.a...@gmail.com wrote:
 I think it would be better to create separate relations for disputed
 territories instead of introducing new roles. Your approach would break
 many existing applications.

 There's already a proposal:
 http://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories

 Am 21.07.2015 um 16:12 schrieb Eugene Alvin Villar:
 My idea is to replace the use of 'inner', 'outer' (and the deprecated
 'exclave', and 'enclave') roles in a type=boundary relation with
 'defacto' and 'dejure' (or 'claimed') roles. The 'inner' and 'outer'
 roles are very trivial to compute (assuming a relation is properly
 constructed) and are actually redundant information.

 ___
 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] How to tag a Driver and Vehicle Licensing Agency (US:DMV)

2015-06-11 Thread Eugene Alvin Villar
On Tue, Jun 9, 2015 at 7:12 PM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:

 that's why I suggested to use a multi tag approach. One tag to say it is a
 government office, one to say at which level (admin level) and then tags
 for the stuff you can do there (property list) or about the general
 classification (e.g. tax office, ministry of education, torture agency, ...)


+1

I prefer this approach.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)

2015-06-02 Thread Eugene Alvin Villar
On Jun 3, 2015 8:06 AM, pmailkeey . pmailk...@googlemail.com wrote:
 OSM's k=v design is completely a serious and unnecessary flaw. [...] OSM
is 90% argument, 5% dead-end discussions and 5% progress. The whole is not
a marketable product; it's not fit to be rated as 'beta'. Is this a
significant cause of ex-mappers ? It's a flipping brilliant project but
sadly lacking a great leader.

It seems you are deeply unsatisfied with how OSM works. And your broad
assertions such as that OSM is not fit or is 90% argument are
completely unfounded. Sure, OSM is not perfect but I seriously doubt that
the k=v design or some other point you have raised is the culprit.

Feel free to leave and create a separate project. You can even be the
great leader for that new project that you think OSM needs. If your ideas
are indeed better, then your project will succeed and you can then prove
OSM wrong.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OSM is a right mess (was: Craigslist OpenStreetMap Rendering Issue)

2015-06-02 Thread Eugene Alvin Villar
On 6/3/15, Steve Coast st...@asklater.com wrote:

 On Jun 2, 2015, at 6:22 PM, Eugene Alvin Villar sea...@gmail.com wrote:
 On Jun 3, 2015 8:06 AM, pmailkeey . pmailk...@googlemail.com
 mailto:pmailk...@googlemail.com wrote:
  OSM's k=v design is completely a serious and unnecessary flaw. [...] OSM
  is 90% argument, 5% dead-end discussions and 5% progress. The whole is
  not a marketable product; it's not fit to be rated as 'beta'. Is this a
  significant cause of ex-mappers ? It's a flipping brilliant project but
  sadly lacking a great leader.

 It seems you are deeply unsatisfied with how OSM works. And your broad
 assertions such as that OSM is not fit or is 90% argument are
 completely unfounded.


 I don’t know; there are a bunch of fairly key and active OSM people who
 unsubscribed from the lists precisely because they felt it was mostly
 circular argument.

Yes, people leave mailing lists because of the endless arguments and
constant bike-shedding. But that does not constitute 90% of OSM. I am
willing to bet that majority if not 90% of OSM activity is of mappers
actually mapping. Mailing list discussions is a really small slice of
the overall OSM activity.

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


Re: [Tagging] housenumber on node and area

2015-05-27 Thread Eugene Alvin Villar
On Thu, May 28, 2015 at 7:22 AM, pmailkeey . pmailk...@googlemail.com wrote:

 In the US where there are mailboxes with the little flags on them it seems 
 correct to put the address on the node for that box. Common sense really.

Mike, you keep on insisting that addresses should always be put on an
area and never on a node. Now here you say it's common sense and
correct to put it on a node (that represents the mailbox). What is
your position really?

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


Re: [Tagging] Wiki: Key:level: proposed rewrite

2015-05-25 Thread Eugene Alvin Villar
I, too, object. level=* is meant to be the numeric stacking order of
floors/levels in a building.

One redundant tag to level=* is addr:floor=*. This tag currently has the
same definition as level=* (with the same numbering convention). I propose
that we use addr:floor=* instead for your string level/floor name as that
fits better with addressing schemes.


On Mon, May 25, 2015 at 7:41 AM, pmailkeey . pmailk...@googlemail.com
wrote:

 Any objection if I 'rewrite http://wiki.openstreetmap.org/wiki/Key:level ?

 It seems to have been written with the misconception that floor names are
 numbers when they're not.

 A rewrite:

- Won't affect existing names that appear as numbers.
- Will encourage mappers to use correct names for floors (as found in
the building) rather than attempt to convert them to meaningless numbers.


 --
 Mike.
 @millomweb https://sites.google.com/site/millomweb/index/introduction -
 For all your info on Millom and South Copeland
 via *the area's premier website - *

 *currently unavailable due to ongoing harassment of me, my family,
 property  pets*

 TCs https://sites.google.com/site/pmailkeey/e-mail

 ___
 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] Deprecating wikipedia Tag

2015-05-25 Thread Eugene Alvin Villar
On Tue, May 26, 2015 at 5:18 AM, moltonel 3x Combo molto...@gmail.com
wrote:

 Speaking of stable ids, how does wikidata handle renames, merges and
 splits on the wikipedia side ? Even in the best-case scenario, it
 seems that an OSM wikidata tag can drift off-target following
 reorganisations that are correct from a wikimedia POV but not from an
 OSM POV.


At least for renames, Wikidata gets automatically updated (and the changes
in Wikidata are registered under the user account of the Wikipedian who did
the rename). In fact, many Wikipedians have Wikidata edits that they don't
realize they did because they have renamed articles.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - admin_title=*

2015-05-10 Thread Eugene Alvin Villar
On Sun, May 10, 2015 at 5:53 PM, Friedrich Volkmann b...@volki.at wrote:

 On 10.05.2015 10:38, Eugene Alvin Villar wrote:
  I prefer designation=* since it it already a widely used tag that fits
 the
  intended purpose of the proposed admin_title=* tag. The question on
 whether
  the value should be human-readable or machine-readable can be solved by
  using correspondence tables to link the two. Barring such a table, I
 don't
  see a catastrophic problem in automatically converting civil_parish to
  Civil Parish and vice versa, to use the example in the talk page.

 designation=* is widely used (193 293 times), but look at the values in
 taginfo. The only relevant value is civil_parish (3346 times). All other
 values are just a mess.


Then there should be an effort to standardize the possible values of
designation=* when applied to administrative entities. I think your current
proposal is a good time to discuss that.


 The automatic replacement of underscores and lowercase initials with blanks
 and uppercase initials would be easy, but no application developer will
 implement it, and the uppercase initials may be wrong in some cases.


Do you have any proof that application developers will not implement it,
other than just personal conjecture? And as I said before, such automatic
replacement, if wrong, is not a catastrophic problem.


 It would also be easy to put a conversion table in the wiki, similar to the
 tables we already have for implicit maxspeed and access values by highway
 type and country. But again, application developers will ignore those
 tables.


Again, why are you so sure that developers will ignore such tables? If a
tag such as designation=* when applied to administrative entities were to
be widely and consistently applied, and the documentation on the wiki is
clear, then developers will find value in supporting such tables.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - admin_title=*

2015-05-10 Thread Eugene Alvin Villar
I prefer designation=* since it it already a widely used tag that fits the
intended purpose of the proposed admin_title=* tag. The question on whether
the value should be human-readable or machine-readable can be solved by
using correspondence tables to link the two. Barring such a table, I don't
see a catastrophic problem in automatically converting civil_parish to
Civil Parish and vice versa, to use the example in the talk page.

On Sun, May 10, 2015 at 3:55 PM, Friedrich Volkmann b...@volki.at wrote:

 On 17.12.2014 16:25, I wrote:
  This is about a new attribute for administrative devisions.
 
  http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title

 So far there were 3 alternative suggestions, which all have their
 drawbacks:

 1) official_status: It remains unclear what the prefix means (country code?
 language code?) and why it is needed, see my entry from 29 December 2014
 17:33 on the talk page.

 2) designation: contains machine readable values instead of human readable
 values, see my entry from 23 December 2014 12:51 on the talk page. A
 proposal with machine readable values was already voted down
 (http://wiki.openstreetmap.org/wiki/Proposed_features/Designation).

 3) admin_centre role: I don't see that purpose documented anywhere, and it
 does not work for all countries, see Zverik's entry from 18 December 2014
 15:21 on the talk page.

 There's no more activity on the talk page, nor is here, so the only way to
 get this issue forward is by starting the voting phase, which is what I am
 doing now. Anyone who still prefers one of the alternatives will hopefully
 come out of the woodwork and append to the discussion.

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

 ___
 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] Paintball

2015-04-11 Thread Eugene Alvin Villar
Isn't shooting just aiming at non-living targets like what is seen in
the Olympics? If so, then paintball is definitely different.

On 4/12/15, Andreas Goss andi...@t-online.de wrote:
 There is still the question if it's sport=shooting + shooting=paintball
 or sport=paintball.

 They are both used to s similar amount.

 Hmm.. OK paintball it is. Thanks.

 __
 openstreetmap.org/user/AndiG88
 wiki.openstreetmap.org/wiki/User:AndiG88‎


 ___
 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] patron saints

2015-01-25 Thread Eugene Alvin Villar
On 1/26/15, Lukas Sommer sommer...@gmail.com wrote:
 I think this can be a useful new tag.

 And I think it makes sense to define explicitly some things in the
 documentation. Things like
 – use always (or use never) “Saint”: “Saint Paul” vs “Paul”.
 – write the name of the dedication always in the local language (Or
 always in latin? Could become very complicate ;-)

 The clearer these things are defined from the very beginning, the more
 useful will the tag be.

If you are going to use the local language in this tag, then the sort
of GIS queries suggested (most popular saint in a region, etc.) would
not be possible. In addition, do you tag Paul or Paul the Apostle
or Simon Peter? Do you tag Joan or Joan of Arc?

If this tag is to be useful (assuming it is the sort of thing OSM
should record), maybe using Wikidata should be considered through an
additional tag such as dedication:wikidata=Q33923 for Saint Peter
https://www.wikidata.org/wiki/Q33923

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


Re: [Tagging] Tagging a corner address with addr:street:corner=*

2015-01-17 Thread Eugene Alvin Villar
Hi Friedrich,

On Fri, Jan 16, 2015 at 6:28 PM, Friedrich Volkmann b...@volki.at wrote:

 Here in Austria, we sometimes use corner addresses informally, when
 verbally
 (e.g. on the phone) arranging an appointment, or when describing how to
 find
 a certain shop. But these discriptions are not considered addresses. They
 are never used officially. There are two reasons:
 - Corner addresses are much longer than street + housenumber.
 - Corner addresses are ambiguous if there's more then 1 building or estate
 adjacent to the junction. A T-shaped junction has 2 corners adjacent to it,
 a + shaped corner even 4.


These two reasons are valid. But imagine for a minute that you are back in
the 1990s (without GPS) in a third-world country and you only have a paper
map. If you are given a restaurant to visit with an address such as #45
Ayala Avenue, you would, in the worst case, go down the whole length of
Ayala Avenue looking for the correct house number. But if instead you were
given Ayala Avenue corner Makati Avenue, then you can go straight to the
intersection and just look around for the restaurant.


 I don't like the addr:street:corner key because it contains a second colon
 for no obvious reason. addr:street:corner is not really a subkey of
 addr:street. I would consider a tag name like addr:street_corner or just
 addr:corner or using a tag for each street (addr:street=* +
 addr:street1=*).
 However, it is probably too late to change that, given that the
 addr:street:corner key is already in use. So I suggest to just document it
 on http://wiki.openstreetmap.org/wiki/Key:addr, maybe with some reference
 to
 the Philippines concerning usage and origin of the tag.


I see your point about the double colons.

Given that it's only my local community that is using this key and there
are no known tools that use this undocumented tag, I don't think it is too
late to change the key.

I prefer addr:corner_street instead of addr:street_corner. After all, the
data to be recorded under the key is the name for a street, not a corner.
addr:corner is not quite easy to understand without the proper context.
addr:street1=* would potentially be confused with the addrN proposal. Would
you and others agree that addr:corner_street is the best choice? If yes,
I'll bring this topic up on our mailing list.

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


Re: [Tagging] waterway=wadi problem

2015-01-15 Thread Eugene Alvin Villar
Given the current discussion, I wonder if roads that are usually flooded
during heavy rainfall should be also be tagged as waterway=river/stream and
intermittent=yes. ;-)

On Fri, Jan 16, 2015 at 7:27 AM, John F. Eldredge j...@jfeldredge.com
wrote:

 I would recommend expanding the definition of intermittent streams to
 include not only streams that have a regular, seasonal water flow but also
 streams in desert areas that exist only when a rare storm comes along. The
 topography is the same, the tendency of water to run downhill is the same,
 only the frequency of rainfall is different.

 --
 John F. Eldredge -- j...@jfeldredge.com
 Darkness cannot drive out darkness; only light can do that. Hate cannot
 drive out hate; only love can do that. -- Martin Luther King, Jr.




 On January 15, 2015 3:13:38 AM Christoph Hormann chris_horm...@gmx.de
 wrote:

  On Thursday 15 January 2015, johnw wrote:
 
  A wadi is a place where flash floods occur. It is not an intermittent
  river - it isn’t really seasonally wet, and doesn’t provide any real
  expectation that water will be present (except deep underground) -
  because they are located in places where rain itself is unexpected
  for most of the year.

 Well - that would be a useful concept of a wadi but it has two problems:

 * current use of the tag is very different from that, you can see that
 quite well when you look at the taginfo map:

 https://taginfo.openstreetmap.org/tags/waterway=wadi#map

 the uses in Europe for example are probably almost always seasonal.

 * sporadic waterflow is very difficult to determine for the mapper.
 This is especially true for northern Africa where climate got a lot
 drier in the last few thousand years and as a result there are many
 permanently dry valleys that still look like being formed by waterflow
 but that have not seen significant waterflow in the last hundred years.

 My suggestion would probably be to stop rendering waterway=wadi in a way
 implying waterflow, encourage mappers to use intermittent/seasonal
 where this is known and reserve waterway=wadi - despite the then
 misleading key - for valleys where waterflow is unknown.

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

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


[Tagging] Tagging a corner address with addr:street:corner=*

2015-01-15 Thread Eugene Alvin Villar
Hello,

In my country (Philippines), many corner addresses are specified with the
intersecting street instead of (or in addition to) the house or building
number. This actually makes sense because the house numbers are not
immediately obvious when looking at a map, but intersections are quite easy
to spot leading to easier (manual) navigation.

Here are three examples of actual addresses (with the corner address part
highlighted):

1. New World Manila Bay Hotel[1]: 1588 *Pedro Gil cor. M.H. Del Pilar*,
Manila, Philippines, 1004

2. Security Bank - Malabon branch[2]: #2 *Rizal Avenue corner Manapat St.*
Metro Manila 1473

3. Ayala Museum[3]: *Makati Avenue corner De La Rosa Street*, Greenbelt
Park, Makati City 1224

In line with this, our local community has decided to mark the intersecting
street with the addr:street:corner=* tag (already in use more than 1200
times[4]) as a natural extension to the established addr:street=* tag.

I was wondering if the prevalence of corner addresses are also found in
other countries, and if so, what the OSM communities in those countries do
to tag these addresses. I hope that we can establish the use of the
addr:street:corner=* tag or something similar.

~Eugene

[1] https://manilabay.newworldhotels.com/en/contact-us/
[2] https://www.securitybank.com/map/?region=24
[3] http://www.ayalamuseum.org/contact-us/
[4] http://taginfo.openstreetmap.org/keys/addr%3Astreet%3Acorner
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - leisure=fitness_centre

2014-12-29 Thread Eugene Alvin Villar
On Mon, Dec 29, 2014 at 11:25 AM, Clifford Snow cliff...@snowandsnow.us
wrote:

 The only other tag that would work is amenity=fitness_centre. Taginfo
 would indicate that amenity is the most used.

 Taginfo results

 leisure=fitness_centre (and other spelling variations) = 452
 (leisure=fitness_centre is used 440 times.)
 amenity=fitness_centre (and other spelling variations) = 687
 (amenity=fitness_center is used 507 times.)


Well, the usage of amenity=fitness_centre over leisure=fitness_centre is
much too small that I think we can go with either option.

I myself prefer leisure=fitness_centre because amenity=* is overloaded and
I agree with the sentiment that fitness is more of a leisure thing that
people do when they have free time.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - admin_title=*

2014-12-21 Thread Eugene Alvin Villar
On Thu, Dec 18, 2014 at 6:23 AM, Colin Smale colin.sm...@xs4all.nl wrote:

 In the UK designation= is in wide usage for this.

+1

I think designation=* fits perfectly with what is intended by the OP's
proposal.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Various alt_name values?

2014-11-24 Thread Eugene Alvin Villar
+1

I agree with alt_name=name1;name2

On Mon, Nov 24, 2014 at 1:20 AM, Lukas Sommer sommer...@gmail.com wrote:

 Some time ago, there was a discussion on the “talk” mailing list about how
 to deal with the situation of more than one alt_name:

 https://lists.openstreetmap.org/pipermail/talk/2014-September/070838.html

 Most participants preferred the solution “alt_name=name1;name2” over
 solutions like “alt_name_1=name1”+“alt_name_2=name2”.

 However, the discussion didn’t lead to something “official”.

 I think it could be useful to have a clear documentation on the wiki about
 which solution is the preferred one.

 Would a feature proposal be a good way to get there?

 Lukas Sommer

 PS: Me to, I would prefer “alt_name=name1;name2” over other solutions.

 ___
 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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-20 Thread Eugene Alvin Villar
On 9/20/14, Dan S danstowell+...@gmail.com wrote:
 2014-09-19 15:52 GMT+01:00 Tobias Knerr o...@tobias-knerr.de:
 I still prefer (d) though if building=dormitory becomes widely
 accepted then I guess I shall have to swallow that loss for British
 english!

Wouldn't be the first time if ever:
http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer

That said, to me dormitories may also apply to other institutionalized
housing such as housing for staff of a manufacturing plant. Although I
admit that dormitories are primarily for students in my understanding.
This ambiguity can be resolved by careful definition in the Wiki if
ever people accept *=dormitory.

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


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-20 Thread Eugene Alvin Villar
On Sun, Sep 21, 2014 at 7:09 AM, p...@trigpoint.me.uk wrote:

 Dormitories are rooms with multiple beds, usually bunk beds and associated
 with youth hostels,  certainly not suitable for student accommodation where
 there is typically one student in a room, maybe two but they are certainly
 not dormitories.


What you're saying is British English usage. Here in the Philippines,
dormitories are understood to be buildings primarily for students.

For example, in the Ateneo de Manila University, we have the Cervini
Residence Hall for males and Eliazo Residence Hall for females: Note that
the Wikipedia article classifies these are dormitories in accordance to
local usage even if the official name uses Residence Hall:
https://en.wikipedia.org/wiki/Cervini-Eliazo_Residence_Halls

In the University of the Philippines, we have several dormitories such as
Kalayaan Hall, Ilang-Ilang Hall, Molave Hall, etc.

There are also private businesses that run student dormitories, usually
located very near universities such as Manila Dormitory across the
University of Santo Tomas: http://maniladormitory.com/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Religious landuse

2014-08-27 Thread Eugene Alvin Villar
Tom, I think you are interpreting the tag amenity=place_of_worship too
literally. In my opinion, this is not intended to only apply to the
specific place or building where the actual worshiping happens.

For one thing, we tag footways as highway=footway but footways are not
highways. And we tag city halls as amenity=townhall even though cities are
not towns (at least in many countries). It would be best to think of tags
as simply identifiers for a type/class of map features. Yes, the English
meaning of the keys and values of tags usually match the feature, but they
don't always have to match.

For another thing, we tag Scientology churches as amenity=place_of_worship
in OSM but scientologists do not really perform any practice that we would
call worship or devotion. So, going by your logic, tagging their
churches as amenity=place_of_worship is wrong. (The debate on whether
Scientology should be considered a religion or not is moot;
religion=scientologist is an established tag in OSM.)

Lastly, you mentioned about parking amenities and you think that these
should not be included in the area tagged as amenity=place_of_worship, but
that they could be included in a larger area tagged as landuse=religious.
But again, going by your logic, we should exclude all parking amenities and
other non-educational features from areas tagged as
amenity=school/college/university. But that is not the current practice.

To conclude, including the temple/mosque/church grounds—even if there is no
worshiping going on the grounds—in the area tagged as
amenity=place_of_worship is perfectly valid.


On Wed, Aug 27, 2014 at 4:54 PM, Tom Pfeifer t.pfei...@computer.org wrote:

 Eugene, I am not ignoring anything, I am arguing and listening.
 My 90% were labelled as a guess in a discussion (quite certainly),
 the 1/3 of them have building tags comes from taginfo.

 You give examples from 6 places where particular mappers use this
 style, this is also not a statistic. I have seen this style as well,
 and it only reinforces the need to find a solution that suits the
 different situations.

 If you have knowledge how the act of worshipping in a Buddhist temple
 differs from a Christian church or Jewish synagogue, in particular in
 being focussed on a particular building vs. practised in a more spatial
 manner on the religious campus, that contribution would be welcome.

 So far we have identified the following use cases / situations:

 1
 Building where worshipping ceremonies focus, surrounded by land which has
 a relation
 to the religion, and holds structures that are not used for the act of
 worshipping.
 The building often has architectural significance and stands out as a
 landmark.

 2
 Places of worshipping that are not focused on a particular building, the
 ceremony is performed in a spacial manner, potentially in open space.

 3
 Land which has a relation to the religion, holding e.g. administrative
 office
 buildings, seminar rooms, etc., but no particular building for worshipping
 ceremonies.

 4
 Buildings that were erected for worshipping, thus still have the
 architectural significance and landmark character, but are now used for
 secular purposes, such as concert theatres or climbing halls. Some could be
 reactivated for the religious purpose by bringing the altar back.

 I still find a landuse tag very suitable for case 1 and 3, where calling
 the land *=place_of_worship would be a misnomer for the lack of ceremony.


 On Tue, Aug 26, 2014 at 11:25 PM, Tom Pfeifer wrote:


 Thus the comparison with [amenity=school], that can be easily
 expanded to the
 whole campus, fails for [amenity=place_of_worship].

 To conclude, [amenity=place_of_worship] should not be expanded to the
 full campus, and [landuse=religious] is a suitable, multicultural
 tag for this land, comparable to [landuse=retail] or
 [landuse=commercial]

 [...]

 Thus amenity=place_of_worship is perfectly tailored to this
 particular
 building and its meaning should not be expanded to something it was
 not
 defined for initially. Keep in mind it is already used 611000 times,
 only
 1/3 of them has a building tag, but quite certainly 90% of them are
 buildings.


 Eugene Alvin Villar wrote, on 2014-08-26 23:34:

  This completely ignores the current practice all over the world
 (especially in Asia) where the landuse is already tagged with
 amenity=place_of_worship. Some examples:

 Buddhist temples in Tokyo, Japan: http://overpass-turbo.eu/s/4gi
 Catholic churches in Manila, Philippines: http://overpass-turbo.eu/s/4gj
 Buddhist, Hindu, Methodist, and Muslim places of worship in Singapore:
 http://overpass-turbo.eu/s/4gk
 Buddhist temples in Beijing, China: http://overpass-turbo.eu/s/4gl
 Hindu temples and Christian churches in Bangalore, India:
 http://overpass-turbo.eu/s/4gm
 Buddhist temples in Bangkok, Thailand: http://overpass-turbo.eu/s/4gn

 I would like to see how you came up with the 90% of them are buildings

Re: [Tagging] Religious landuse

2014-08-26 Thread Eugene Alvin Villar
On Tue, Aug 26, 2014 at 11:25 PM, Tom Pfeifer t.pfei...@computer.org
wrote:

 Thus the comparison with [amenity=school], that can be easily expanded to
 the
 whole campus, fails for [amenity=place_of_worship].

 To conclude, [amenity=place_of_worship] should not be expanded to the
 full campus, and [landuse=religious] is a suitable, multicultural
 tag for this land, comparable to [landuse=retail] or [landuse=commercial]

 [...]

 Thus amenity=place_of_worship is perfectly tailored to this particular
 building and its meaning should not be expanded to something it was not
 defined for initially. Keep in mind it is already used 611000 times, only
 1/3 of them has a building tag, but quite certainly 90% of them are
 buildings.


This completely ignores the current practice all over the world (especially
in Asia) where the landuse is already tagged with amenity=place_of_worship.
Some examples:

Buddhist temples in Tokyo, Japan: http://overpass-turbo.eu/s/4gi
Catholic churches in Manila, Philippines: http://overpass-turbo.eu/s/4gj
Buddhist, Hindu, Methodist, and Muslim places of worship in Singapore:
http://overpass-turbo.eu/s/4gk
Buddhist temples in Beijing, China: http://overpass-turbo.eu/s/4gl
Hindu temples and Christian churches in Bangalore, India:
http://overpass-turbo.eu/s/4gm
Buddhist temples in Bangkok, Thailand: http://overpass-turbo.eu/s/4gn

I would like to see how you came up with the 90% of them are buildings
statistic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] minus or underscore in attribute values?

2014-08-23 Thread Eugene Alvin Villar
On Sat, Aug 23, 2014 at 4:42 PM, Richard Z. ricoz@gmail.com wrote:

 Hi,

 another mapper metnioned to me that it is unusual to have
 attribute values with a minus, like
   bridge:structure=cable-stayed

 On the other hand, it is an apporved proposal - what are the
 opinions on that?


Based on previous discussion in past there is no real preference to using
underscores versus hyphens.

Case in point:
http://taginfo.openstreetmap.org/keys/drive_through
versus
http://taginfo.openstreetmap.org/tags/service=drive-through
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Commons: mixed purposes

2014-08-17 Thread Eugene Alvin Villar
On Sun, Aug 17, 2014 at 7:45 PM, Andy Mabbett a...@pigsonthewing.org.uk
wrote:

 What should we sue to link to Wikimedia commons categories like:

https://commons.wikimedia.org/wiki/Category:St_Paul,_Birmingham

 I've previously used Wikimedia_Commons=, but that's verbose; and I
 seem to be alone in doing so.


Wouldn't linking using the wikidata=* tag be better as the Wikidata entry
for St Paul's Church in Birmingham should link to the appropriate page or
category on Wikimedia Commons?

So I would tag the OSM object representing St Paul's Church as
wikidata=Q915614
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Multistory medical office building

2014-07-31 Thread Eugene Alvin Villar
Is this a building completely separate from a hospital? I encounter these
buildings as part of a hospital complex and so include them in an area
tagged with amenity=hospital.


On Thu, Jul 31, 2014 at 9:54 AM, Hans De Kryger hans.dekryge...@gmail.com
wrote:

 Wondering how to tag a 2 story medical office building. It has many
 doctors offices. To many to place poi's one upon another on the building.
 In need of help?
 *Regards,*

 *Hans*


 *http://www.openstreetmap.org/user/TheDutchMan13
 http://www.openstreetmap.org/user/TheDutchMan13 *

 ___
 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] Religious landuse?

2014-07-18 Thread Eugene Alvin Villar
On Thu, Jul 17, 2014 at 4:46 PM, Pieren pier...@gmail.com wrote:

 I'm surprised about this discussion. Think that
 amenity=place_of_worship has to be treated like amenity=school. Nobody
 is asking to create a landuse=school because it is rendered properly
 on the main osm style. The problem is that amenity=place_of_worship is
 always rendered as a building even when it could be a bigger area
 (like for schools).


+1. I've always ignored the fact that the main rendering draws
amenity=place_of_worship in a really dark color and I tag the whole church
grounds as amenity=place_of_worship and tag the church building itself with
building=church. This is similar to how I tag the whole school grounds with
amenity=school.

I remember a discussion about a proposed tag landuse=institutional or
similar for things like these earlier this year:
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dinstitutional
https://lists.openstreetmap.org/pipermail/tagging/2014-March/016842.html
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Religious landuse?

2014-07-18 Thread Eugene Alvin Villar
On Fri, Jul 18, 2014 at 6:19 PM, Janko Mihelić jan...@gmail.com wrote:

 I'm not sure church grounds is a place of worship. People don't usually
 worship God in an organized manner besides the church.


There are actually a lot of churches where I am where the Catholic 14
Stations of the Cross are spread throughout the church grounds and these
are spots where churchgoers pray the Way of the Cross.

Besides, I don't think we need to be quite literal with place_of_worship
only being tagged for the actual specific object where one does worshiping.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Religious landuse?

2014-07-18 Thread Eugene Alvin Villar
On Fri, Jul 18, 2014 at 9:36 PM, Brad Neuhauser brad.neuhau...@gmail.com
wrote:

 Besides, I don't think we need to be quite literal with place_of_worship
 only being tagged for the actual specific object where one does worshiping.


 I hear what you're saying, but with a tag that's used 600K times (on 226K
 ways), we have to look at actual usage for part of our guidance. *Totally*
 unscientific, but I used overpass turbo to zoom in on multiple areas around
 the world and look at ways that are tagged amenity=place_of_worship, and
 the vast majority appeared to be building outlines. Using it for the
 grounds seems like an outlier. (if someone else wants to do more robust
 research, I'd be happy to see it! :)  So, while using place of worship for
 the grounds may be correct in certain case, in the majority of cases, the
 common usage seems to leave a question about how to tag the grounds.


Places where the grounds are tagged with amenity=place_of_worship and not
just the main building:

Tokyo, Japan: http://overpass-turbo.eu/s/4gi
Manila, Philippines: http://overpass-turbo.eu/s/4gj
Singapore: http://overpass-turbo.eu/s/4gk
Beijing, China: http://overpass-turbo.eu/s/4gl
Bangalore, India: http://overpass-turbo.eu/s/4gm
Bangkok, Thailand: http://overpass-turbo.eu/s/4gn

I don't know which areas around the world you have looked at but from my
point of view, tagging the grounds is clearly not an outlier method of
tagging but is completely valid.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] British English Spelling shop=jewelry

2014-07-18 Thread Eugene Alvin Villar
On Fri, Jul 18, 2014 at 11:55 PM, Jesse B. Crawford je...@jbcrawford.us
wrote:

 Something I've noticed as an American that works with many foreign
 nationals is that the majority of people who learn English in a foreign
 country seem to learn British English - my sample may be biased since I
 work with a lot of people from India, which is a former colony, but amongst
 people from China and Germany for example I am also used to seeing the
 British spellings.


FWIW, the Philippines is a former U.S. colony and we also use American
English spelling here (mostly).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subsequent wikipedia links

2014-07-01 Thread Eugene Alvin Villar
On Wed, Jul 2, 2014 at 2:48 AM, yvecai yve...@gmail.com wrote:

 I would find more logical to make links between databases with queries
 rather by adding external references in one or the other. The later looks
 like the poor man job (oversimplifying, I don't want to put down the great
 job done at Wikidata).


I disagree. If the goal is to make separate databases function as one big
normalized database[1] such that there is no overlap in data, then these
inter-database references are, in fact, necessary.

[1] https://en.wikipedia.org/wiki/Database_normalization
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] admin_level on nodes: wiki vs practice

2014-05-10 Thread Eugene Alvin Villar
I think an explicit tagging scheme that specifies the correspondence
between place=* tags and admin_level=* tags is a good thing.


On Sun, May 11, 2014 at 8:28 AM, Fernando Trebien 
fernando.treb...@gmail.com wrote:

 Hello everyone,

 We're having a little discussion in the Brazilian community about
 whether the node tagged with place=* that represents a city
 should/shouldn't have an admin_level=* tag. The wiki states, since at
 most 2010 [1], that the admin_level tag should not be used on nodes.
 However, both Berlin [2] and London [3] do include that tag. So what
 should we do? Update the wiki to state that the tag is allowed it on
 nodes? Mention a specific exception in the wiki for this type of
 nodes? Fix the mapping of London and Berlin (and probably hundreds of
 others)?

 [1]
 http://wiki.openstreetmap.org/w/index.php?title=Tag%3Aboundary%3Dadministrativediff=1000731oldid=552031
 [2] http://www.openstreetmap.org/node/240109189
 [3] http://www.openstreetmap.org/node/107775


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


Re: [Tagging] Feature Proposal - RFC - Wikidata

2014-04-02 Thread Eugene Alvin Villar
On Wed, Apr 2, 2014 at 1:47 AM, Janko Mihelić jan...@gmail.com wrote:

 2014-04-02 0:46 GMT+02:00 Eugene Alvin Villar sea...@gmail.com:


 I'm not so sure about operator:wikidata=* (or wikidata:operator=* as
 suggested on the wiki talk page) and the other similar tags like that. I
 think this should be discussed more since the current set of proposed
 supplementary tags seem like an arbitrary set. Why these (operator, brand,
 artist, etc.) and not others? If we can conceivably tag other properties
 with Wikidata entities, we should have a more generalized scheme for adding
 such tags.


 What do you suggest?

 I think these tags are essential because the wikidata tag should be used
 very carefully. People are probably going to start tagging McDonalds
 restaurants with wikidata=Q38076 https://www.wikidata.org/wiki/Q38076.
 That is (maybe not so obviously) wrong because that little restaurant isn't
 a multinational company. It's a restaurant that uses their franchise.

 That's why there should be several predefined tags so we don't end up with
 lots of bad data.

 operator:wikidata is better IMHO because you can also have
 operator:source, operator:webpage, and it makes more sense to do it in that
 order.


I would suggest that a requirement for a foo:wikidata=* tag (or
wikidata:foo=* tag) is that foo=* is already an established tag. After all,
the point of linking to Wikidata in the first place is we want a semantic
way of indicating an entity.

For example, there are lots of things named McDonald's and this makes
something like name=McDonald's or brand=McDonald's ambiguous. But by
linking to a particular McDonald's in Wikidata, we specify exactly which
McDonald's we are talking about.

Thus, I think that brand:wikidata=* or operator:wikidata=* is a semantic
version of brand=* and operator=*. So, foo:wikidata=* makes a lot of sense
if we already have foo=* in the first place.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Issues relating to URIs and tagging

2014-04-01 Thread Eugene Alvin Villar
On Tue, Apr 1, 2014 at 11:29 PM, Andy Mabbett a...@pigsonthewing.org.ukwrote:

 The model used there fails with Wikipedia links,
 expressed as en:Example, because the equivalent URL is
 https://en.wikipedia.org/wiki/Example. Any suggestions for dealing
 with that?

 [...] ambiguous keys (ref=1234 - ref in whose database?) [...]


I think you might be better off providing an algorithm to generally
handle such cases because specifying a URL pattern like 
http://openplaques.org/plaques/[value]; is too simple for the diverse ways
that people tag OSM objects.

For example, the algorithm will use capturing regexes to split the key
and/or value into parts. And then you can assemble the URI/URL depending on
the presence of other tags and on GIS-related aspects of the tagged object
(for example, if the object is inside the boundary relation for France).

For the wikipedia=* example, you can have:

tag_regex = ([^;]+):(.+)
 uri_algorithm = uri_pattern:https://$1.wikipedia.org/wiki/$2;


The uri_algorithm would have to be in the form of a switch or case
construct like for ref.

uri_algorithm =
case fr_highways:
   condition = has:highway=*  in polygon[has:type=boundary 
 has:admin_level=2  has:ISO3166-1=FR]
   uri_pattern = http://...$value...;


Now that I think about it, Apache's HTTP server mod_rewrite rules work
exactly like this. mod_rewrite takes an input URL (or a tag in our case)
and rewrites it to another URL by specifying RewriteCond and RewriteRule
elements that correspond to my condition and uri_pattern/tag_regex
example above respectively.

RewriteCond is quite flexible since you can match on any aspect of the HTTP
request such as requesting IP address, date and time of request, cookies,
etc. RewriteRules specify a regex on the input URL and then the resulting
URL pattern.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   >