Re: [Tagging] wiki page for building=pavilion

2018-12-28 Thread Colin Smale
On 2018-12-28 22:52, Martin Koppenhoefer wrote:

> Generally, a pavilion will only have one floor (no basement, no upper 
> floors), will usually have sleeping possibilities, will not be big. MIght 
> also be just a roof. 
> I am not completely sure about this being a requirement, but I would expect 
> it to be a central-plan building (square, polygonal or round, not a long and 
> narrow rectangle).

Martin, I don't know which dictionary you referred to or otherwise what
your frame of reference is, but I (as a Brit) do not recognise the
qualifications you mention. Many outdoor sports clubs will have a
building (or part thereof) which everyone calls "the pavilion," and I
know quite a few which are both multi-storey and/or rectangular.
Sleeping possibilities? Possibly in a medical centre? 

These days the word "pavilion" refers mainly to the use to which the
building is put (dressing rooms, refreshments etc., especially for the
participants), rather than it being an obvious architectural style. 

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


Re: [Tagging] Benefits of namespaces

2018-12-20 Thread Colin Smale
On 2018-12-20 13:27, Xavier wrote:

> On Thu, Dec 20, 2018 at 01:00:20PM +0100, Sergio Manzi wrote:I *never *heard 
> of a transformer's /tertiary/, thus: try asking an electrical engineer...
> In general, a transformer can have 1..N primary windings and 1..N secondary 
> windings:
> 
> https://www.electronics-tutorials.ws/transformer/multiple-winding-transformers.html
> 
> The most common is the 1:1 (single primary, single secondary) transformer, 
> followed next by a 1:N style (one primary, multiple secondary, this is 
> usually used to provide plural output voltages from the same single 
> transformer).
> 
> But in the general case (which is what OSM would, at some point, want to be 
> able to cover), a transformer is N:N with each N being 1..X.

And then there was the auto-transformer which only has a single winding
with multiple taps.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Printing company for newspapers

2018-12-14 Thread Colin Smale
On 2018-12-14 15:23, Paul Allen wrote:

> Even so, the primary distinction between a jobbing printer and a 
> newspaper/book printer is not 
> the equipment used or the size of the operation but the type of output.  That 
> said, jobbing printers 
> tend to be smaller than newspaper/book printers and the older/smaller jobbing 
> printers tend to use letterpress rather than offset litho.

A better distinction would be that newspaper presses are web-fed (the
paper comes on huge rolls) not sheet-fed. They also have fully automated
collation and other post-press processing. 

Not sure about book printers... Most likely they use sheet-fed presses
for smaller runs, and web-fed for best sellers.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Railway tracks on highway

2018-12-12 Thread Colin Smale
On 2018-12-12 08:51, Markus wrote:

> On Mon, 10 Dec 2018 at 11:49, Colin Smale  wrote:
> Check out Sydney, where they are using APS for some urban parts of a light 
> rail system:
> 
> https://en.wikipedia.org/wiki/CBD_and_South_East_Light_Rail
> 
> Never say never... Even if it is uncommon, our tagging should be flexible 
> enough to handle it, do you agree?
> Thanks for the interesting link. I agree and try to be more precise in
> the future. :-)

Actually in this case I would say it would be a question of being less
precise and not specifying things which don't need to be specified, or
in other words keeping dimensions which are not intrinsically connected
out of each other's way. Type of power supply (overhead, 3rd rail etc)
has no connection to the class of the system (tram, light rail, metro,
heavy rail etc) - all combinations are possible, even if some
combinations are more popular than others. One does not imply the other.


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


Re: [Tagging] Feature Proposal - RFC - Railway tracks on highway

2018-12-10 Thread Colin Smale
On 2018-12-09 22:30, Markus wrote:

> Thank you, Mateusz and Colin, i haven't thought of curve radii and signalling.
> 
> By the way, i deliberately didn't mention the Bordeaux system because
> it's uncommon and not a metro (but some kind of tram).

Check out Sydney, where they are using APS for some urban parts of a
light rail system: 

https://en.wikipedia.org/wiki/CBD_and_South_East_Light_Rail 

Never say never... Even if it is uncommon, our tagging should be
flexible enough to handle it, do you agree?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Railway tracks on highway

2018-12-09 Thread Colin Smale


On 9 December 2018 17:37:21 CET, Markus  wrote:
>Hi!
>
>I'm still wondering if there is a technical difference between
>embedded tram, train and now metro rails (except for a third rail,
>which usually can't be embedded in a street).

It can and is popular in France.. Check out APS (alimentation par sol). 

A major difference between heavy rail and trams is signaling. Rail systems are 
heavy on safety interlocks whereas trams basically rely on the driver as they 
have to interact with city traffic. Points (switches) for trams are controlled 
by the drivers on demand, whereas for trains they are set for centrally 
determined paths. I suspect that point motors for trams are happier at being 
forced open at trailing junctions as well. Big train point motors take a dim 
view of that. 

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


Re: [Tagging] antenna use key to replace some of the antenna type

2018-12-01 Thread Colin Smale
On 2018-12-01 03:31, Graeme Fitzpatrick wrote:

> Yep, this 
> https://www.google.com/maps/@-28.1021508,153.4242644,3a,60y,177.95h,111.88t/data=!3m6!1e1!3m4!1sEcT3AiOK4QyKpuF45oC9Aw!2e0!7i13312!8i6656
>  is a 2-way radio antenna of some sort, & that's about all I'm qualified, & 
> interested :-), in saying!

How can you see it is 2-way? AFAIK that is not a function of the antenna
itself, but of the equipment connected to it, probably down in the
building below in this case.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] antenna type

2018-11-24 Thread Colin Smale
And just to add to the confusion, there are usually three antennas per
BTS, which cover ~120 degree sectors, so the RF power can be adjusted in
each sector individually to give the desired amount of overlap with
adjacent cells. 

So in terms of physical things to map, we have at least locations,
masts, cells, sectors, antennas, and base stations. And possibly
microwave backhaul equipment.

On 2018-11-24 19:47, Sergio Manzi wrote:

> So... how many tags will this node have, once you have tagged all of its 
> components? 
> 
> From [1 [3]]: 
> 
>> A BTS is usually COMPOSED OF: Transceiver (TRX) Provides transmission and 
>> reception of signals. It also does sending and reception of signals to and 
>> from higher network entities (like the base station controller [1] in mobile 
>> telephony). Power amplifier (PA) Amplifies the signal from TRX for 
>> transmission through antenna; may be integrated with TRX. Combiner Combines 
>> feeds from several TRXs so that they could be sent out through a single 
>> antenna. Allows for a reduction in the number of antenna used. Multiplexer 
>> For separating sending and receiving signals to/from antenna. Does sending 
>> and receiving signals through the same antenna ports (cables to antenna). 
>> Antenna This is the structure that the BTS lies underneath; it can be 
>> installed as it is or disguised in some way (Concealed cell sites [2]). 
>> Alarm extension system Collects working status alarms of various units in 
>> the BTS and extends them to operations and maintenance (O) monitoring 
>> stations. Control function Controls and
manages the various units of BTS, including any software. On-the-spot 
configurations, status changes, software upgrades, etc. are done through the 
control function. Baseband receiver unit (BBxx) Frequency hopping, signal DSP.
> 
> Mapping each component (_yes, the antenna too..._) separatly doesn't make 
> much sense to me... 
> 
> Sergio 
> 
> [1] https://en.wikipedia.org/wiki/Base_transceiver_station
> 
> On 2018-11-24 17:59, François Lacombe wrote: 
> "BTS" is another object and differ from antennas since the antennas are 
> connected to BTS/nodeB/eNodeB. 
> 
> Both can be mapped with telecom=* and BTS will often get 
> man_made=street_cabinet 
> 
> Recently reviewed Telecom=service_device is suitable for "BTS" cabinets with 
> telecom:medium=radio and aditional tags for 3GPP technology 2G/3G or LTE. 
> 
> Several antennas can be fed by a single radio cabinet  
> 
> François 
> 
> Le sam. 24 nov. 2018 à 15:51, Sergio Manzi  a écrit : 
> 
> I like it! 
> 
> To me it makes much more sense to tag telecom=BTS (Base Transceiver Station, 
> see [1 [3]]) than man_made:antenna + antenna:type=whatever. 
> 
> But BTS is not indicated as possible value for telecom=* in the wiki... 
> 
> Cheers, 
> 
> Sergio 
> 
> [1] https://en.wikipedia.org/wiki/Base_transceiver_station 
> 
> On 2018-11-24 15:22, François Lacombe wrote: 
> Hi all 
> It would be great to use telecom=* instead of man_made or communications 
> 
> Antennas is a difgicult topic to address in osm since there can be many of 
> them at the same time. They should be distinguished from mast and supports 
> since antennas are only devices 
> 
> All the best 
> 
> François 
> 
> Le sam. 24 nov. 2018 à 14:59, Joseph Eisenberg  a 
> écrit : I'd been thinking about this lately while working on towers and radio 
> telescopes. 
> 
> Towers can be tagged with tower:construction =dish and this is rendered as 
> "satellite" dish sending or receiving waves, in the Openstreetmap-Carto style.
> 
> Radio telescopes are now rendered as well.
> 
> But there are some satellite uplink dishes mistagged as radio telescopes.
> 
> Other tags in use are man_made=communications_dish and man_made=satellite_dish
> 
> But neither is very well documented, I recall.
> 
> I'd be happy to have a better way to tag these dishes.
> 
> On Sat, Nov 24, 2018 at 9:52 PM Paul Allen  wrote: 
> On Sat, Nov 24, 2018 at 1:48 AM Warin <61sundow...@gmail.com> wrote:
> 
> I was looking at the wiki for antennas 
> 
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dantenna 
> 
> I made some additions to the definition and added some photos etc. 
> 
> It is still rather sparse. I'd like to be able to further define what the 
> antenna is. 
> I have some pictures of various antennas in my area.  Well, they're pictures 
> of masts but the 
> antennas are sometimes discernible.  Any idea for a good place to dump them 
> so they can 
> contribute to antenna/mast examples that people can add to wiki pages as 
> appropriate? 
> 
> Worst case, you want me to mail them to you and you can decide what to do 
> with them? 
> 
> -- 
> Paul 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging 


Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)

2018-11-17 Thread Colin Smale
On 2018-11-17 16:35, Paul Allen wrote:

> On Sat, Nov 17, 2018 at 3:52 AM Graeme Fitzpatrick  
> wrote: 
> 
>> Should EU:NATO be a colon or a semi-colon?
> 
> According to the French, it should be EU;OTAN. :)

If you are going to pick nits, get it right... In French it is UE;OTAN
>)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-12 Thread Colin Smale
On 2018-11-12 22:00, Warin wrote:

> On 13/11/18 01:07, Allan Mustard wrote: 
> 
>> Not contrived at all in these days of tight budgets. I see no reason the 
>> inverse would not work. I'll add it.
> 
> I think there are too many things in the proposal. Keep it simple. Yes the 
> 'extras' might sound nice but they add complexity and each one is a point 
> that can lead to someone objecting to that specific thing and leading to 
> enough no votes that it fails.

At moments like this I like to invoke one of my heroes: Albert Einstein.
One famous saying attributed to him is: As simple as possible, but no
simpler. 

If you simplify complex realities too much, you lose valuable detail. If
it's complex, it's complex. If you want to leave out a level of detail,
such as being able to distinguish between the different types of
services provided on behalf of multiple "tenant" countries in a
diplomatic mission, then so be it, but let's discuss whether it is
desirable to leave that out, and whether the resultant ambiguity is
acceptable. Data modelling means constructing an approximation to
reality, and is all about what details to keep in and what to leave out.
Once it is left out, it cannot be reconstructed from the rest of the
data. (If it can, your data model is not properly normalised.) 

If OSM is being limited to being suboptimal because of politics and the
inability to reach consensus, I would rather the system was fixed
instead of condemning the whole business to eternal mediocrity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-11 Thread Colin Smale
On 2018-11-11 21:51, Graeme Fitzpatrick wrote:

> Just for the sake of asking a theoretical question that I know would probably 
> never appear in real life :-) 
> 
> Would / could you also use the multi-letter codes as you show eg NATO, WTO, 
> SEATO? 
> 
> & a mixture of them, so the British Ambassador to Belgium, who is also the 
> delegate / representative to NATO (if there is such a thing?), would be 
> country=GB 
> target=BE;NATO

It's possible I guess to have the inverse of that as well, where the
embassy of e.g. France also houses the ambassador of e.g. Monaco, both
being accredited to the same receiving nation? (contrived example) 

If a mission "represents" multiple countries, and the services offered
are different, how could that be tagged? Something like the full Embassy
of A also housing consular services for B. 

Possibly two OSM objects, one for the embassy of A and a separate node
for the services on behalf of B?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-11 Thread Colin Smale
On 2018-11-11 11:27, Warin wrote:

> On 11/11/18 20:05, Colin Smale wrote: 
> 
> On 2018-11-11 07:49, Graeme Fitzpatrick wrote: 
> 
> But wouldn't it be covered by the name eg "Australian Embassy to Russia"? 
> 
> We should not rely on free-text fields like "name" to convey information that 
> belongs in a structured form...

The text clearly identifies the object as;
an Embassy
The 'from' country as Australia
the 'to' country ... as Russia ... though this may also include other
countries too ..and would be indicated by an enclosure by that county. 

You miss the point... The fact that the words "Australian Embassy"
and/or "to Russia" occur in the "name" tag is not enough for an
automated processor to unambiguously understand that the sending nation
is the Commonwealth of Australia and the receiving nation is the Russian
Federation. All these words can be written in any language of the world.
Hence the need for the "from," "to" and "function" concepts to be
modelled with a curated list of values - there are only so many
countries and international organisations (in this sense) in the world,
and those lists are pretty static. 

Enclosure won't work for missions to international organisations or the
Vatican either. There are (IIRC) also arrangements between countries
such that the embassy of A in country B also represents country C under
certain circumstances. This also doesn't fit nicely with the "from"/"to"
model. On wikipedia they are called "De facto embassies": 

https://en.wikipedia.org/wiki/De_facto_embassy___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-11 Thread Colin Smale
On 2018-11-11 07:49, Graeme Fitzpatrick wrote:

> But wouldn't it be covered by the name eg "Australian Embassy to Russia"?

We should not rely on free-text fields like "name" to convey information
that belongs in a structured form...___
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-04 Thread Colin Smale
On 2018-11-04 01:20, Paul Allen wrote:

> On Sun, Nov 4, 2018 at 12:10 AM Graeme Fitzpatrick  
> wrote:
> 
>> Question though (more for someone in Europe) - is a "Member of the European 
>> Parliament" elected, or just appointed by their home country? Are they a 
>> "politician" as such?
> 
> Elected.  They don't serve any useful purpose since the EU is run by 
> unelected bureaucrats, but they're 
> elected.

Paul, please keep your personal politics out of this discussion.___
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-04 Thread Colin Smale
The activity of a prison is on behalf of a government, pursuant to a
statutory duty of the government to administer justice. That its
operation is outsourced to a private company doesn't change that fact.
You can't just start your own prison - it is a state monopoly. 

Public transport may be a state monopoly, but sometimes it isn't. In the
middle you have state regulation, which is the status in much of the UK.
Anyone can start a bus company, but you need to register the route at
least. (I think it might be a bit more complicated than that...)
Providing free transport, well, I suppose anyone can make it free if
they want, but the money has to come from somewhere... 

On 2018-11-04 15:41, Martin Koppenhoefer wrote:

> sent from a phone 
> 
> On 4. Nov 2018, at 10:19, Allan Mustard  wrote:
> 
>> If it is a budget-dependent company/corporation, such as the Commodity 
>> Credit Corporation of the U.S. government, which generates no revenue of its 
>> own and relies wholly on appropriations from the U.S. Congress, yes, it 
>> should be tagged government.  As Deep Throat said, "Follow the money!"
> 
> I find this difficult, because it implies we define what is original 
> government duty and what is not. Providing beer is apparently not a 
> government job (any more?), providing healthcare might be (?), what about 
> transportation? Is free public transportation a government duty? They surely 
> wouldn't generate (at least direct) profits, and if the service isn't free it 
> could still be financed by the government and not be profitable. Similarly 
> the providing of energy, water, the treatment of waste. Europeans tend to see 
> prisons as government sites, in the US prisons are often private. 
> 
> Ciao, Martin  
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-04 Thread Colin Smale
Thanks for the clear explanation, Allan! 

Although if it really has zero staff, I do wonder who employs the people
who "push the buttons" - authorising and approving payments etc. Do they
work for the Dept of Agriculture? Are they technically "contractors" to
the CCC?

On 2018-11-04 13:43, Allan Mustard wrote:

> The Commodity Credit Corporation is the U.S. equivalent of a British "crown 
> corporation".  It has no staff of its own, a board of directors that consists 
> of the senior political appointees of the U.S. Department of Agriculture, and 
> authority to disburse funds to farmers eligible for various government 
> programs.  It has many statutory duties and authorities to provide credit and 
> subsidies, dating back to legislation first passed in the Great Depression.  
> Programs are implemented by USDA (i.e., government) employees under these 
> authorities.  It is about as far from a commercial enterprise as one can 
> imagine--not even "pseudo-commercial"!  In WTO terms, it is the U.S. 
> government's "national paying agency" for agriculture and so by international 
> treaty is considered a government agency, even though it is incorporated in 
> Delaware as a corporation, has a board of directors, and so on.  If the CCC 
> had an office, it would be tagged office=government, but since CCC only 
> exists on paper, we
mappers don't really have to worry about it :-) On 11/4/2018 3:52 PM, Colin 
Smale wrote:
> 
> The answer will depend on whether we are talking about landuse, building, 
> office or amenity. 
> 
> Waste disposal is (in Europe) usually a statutory task, performed by a 
> commercial company on behalf of some government. If it is open to the public, 
> then the "amenity" provided is waste disposal / recycling. The landuse is 
> probably something like "waste disposal" or "industrial", similar to how 
> landfill sites might be tagged. The "office" belongs to the commercial 
> company, so that is not governmental. 
> 
> Other areas where this (outsourcing of statutory duties) is commonplace (that 
> I know of) include public transport, administration of visa applications, 
> healthcare provision, assessment of benefits claims, and operation of 
> highways/infrastructure. 
> 
> Government-owned companies like a brewery are IMHO nothing to do with the 
> execution of statutory tasks and are therefore not governmental in any way, 
> shape or form. 
> 
> In the example of the Credit Corporation, does some government organisation 
> have a statutory duty to provide credit? Or does it come under something more 
> general like "protecting the poor"? Would the government be "failing in its 
> statutory duty" if thie company disappeared? Otherwise it sounds like an 
> optional, pseudo-commercial venture which in this case happens to be 
> bankrolled by the government.
> 
> On 2018-11-04 11:13, Warin wrote: 
> 
> Where do you draw the line?
> 
> If a 'government company' has 50% of its income from a government allocation 
> and the rest from elsewhere (e.g. contracts with private 
> companies/individuals) is it 'government' or not?
> 
> On 04/11/18 20:19, Allan Mustard wrote: 
> 
> If it is a profitable company that adds to the government's coffers, such as 
> the Budvar brewery in the Czech Republic, which is government owned, I'd say 
> no.  It should be tagged as a brewery.  Same logic would apply to 
> Rosoboronexport, which is Russia's second-largest revenue earner as an arms 
> exporter.  Petronas, the Malaysian government gas and oil company, should be 
> tagged as a gas and oil company.  Same for Pemex, Petroleo Mexicano, as well 
> as the grocery stores the Bangladeshi army operates.
> 
> If it is a budget-dependent company/corporation, such as the Commodity Credit 
> Corporation of the U.S. government, which generates no revenue of its own and 
> relies wholly on appropriations from the U.S. Congress, yes, it should be 
> tagged government.  As Deep Throat said, "Follow the money!" 
> 
> apm-wa 
> On 11/4/2018 1:29 PM, Martin Koppenhoefer wrote: 
> 
> sent from a phone
> 
> On 4. Nov 2018, at 05:54, Allan Mustard  wrote:
> 
> Paul, as Deep Throat told Bob Woodward, "Follow the money."  Who pays the 
> rent on the office and who pays the salary of the occupant?  If the filthy 
> lucre comes out of the government budget, and the office is used by someone 
> drawing a government salary (as all executives, legislators, and judges do, 
> or are supposed to, at least) then it is a government office.
> 
> what about government owned companies? Should they get a government tag?
> 
> Cheers, Martin

_

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

2018-11-04 Thread Colin Smale
The answer will depend on whether we are talking about landuse,
building, office or amenity. 

Waste disposal is (in Europe) usually a statutory task, performed by a
commercial company on behalf of some government. If it is open to the
public, then the "amenity" provided is waste disposal / recycling. The
landuse is probably something like "waste disposal" or "industrial",
similar to how landfill sites might be tagged. The "office" belongs to
the commercial company, so that is not governmental. 

Other areas where this (outsourcing of statutory duties) is commonplace
(that I know of) include public transport, administration of visa
applications, healthcare provision, assessment of benefits claims, and
operation of highways/infrastructure. 

Government-owned companies like a brewery are IMHO nothing to do with
the execution of statutory tasks and are therefore not governmental in
any way, shape or form. 

In the example of the Credit Corporation, does some government
organisation have a statutory duty to provide credit? Or does it come
under something more general like "protecting the poor"? Would the
government be "failing in its statutory duty" if thie company
disappeared? Otherwise it sounds like an optional, pseudo-commercial
venture which in this case happens to be bankrolled by the government.

On 2018-11-04 11:13, Warin wrote:

> Where do you draw the line?
> 
> If a 'government company' has 50% of its income from a government allocation 
> and the rest from elsewhere (e.g. contracts with private 
> companies/individuals) is it 'government' or not?
> 
> On 04/11/18 20:19, Allan Mustard wrote: 
> 
> If it is a profitable company that adds to the government's coffers, such as 
> the Budvar brewery in the Czech Republic, which is government owned, I'd say 
> no.  It should be tagged as a brewery.  Same logic would apply to 
> Rosoboronexport, which is Russia's second-largest revenue earner as an arms 
> exporter.  Petronas, the Malaysian government gas and oil company, should be 
> tagged as a gas and oil company.  Same for Pemex, Petroleo Mexicano, as well 
> as the grocery stores the Bangladeshi army operates.
> 
> If it is a budget-dependent company/corporation, such as the Commodity Credit 
> Corporation of the U.S. government, which generates no revenue of its own and 
> relies wholly on appropriations from the U.S. Congress, yes, it should be 
> tagged government.  As Deep Throat said, "Follow the money!" 
> 
> apm-wa 
> On 11/4/2018 1:29 PM, Martin Koppenhoefer wrote: 
> 
> sent from a phone
> 
> On 4. Nov 2018, at 05:54, Allan Mustard  wrote:
> 
> Paul, as Deep Throat told Bob Woodward, "Follow the money."  Who pays the 
> rent on the office and who pays the salary of the occupant?  If the filthy 
> lucre comes out of the government budget, and the office is used by someone 
> drawing a government salary (as all executives, legislators, and judges do, 
> or are supposed to, at least) then it is a government office.
> 
> what about government owned companies? Should they get a government tag?
> 
> Cheers, Martin

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

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


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

2018-10-26 Thread Colin Smale
On 2018-10-26 18:41, Eugene Alvin Villar wrote:

> 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. ;-)

Indeed, I believe all the embassies to the Holy See are physically in
Rome. I wonder which is the "receiving state", responsible for
accommodation, security etc.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-10-26 Thread Colin Smale
On 2018-10-26 03:26, Allan Mustard wrote:

> Under the legal doctrine of extraterritoriality, the embassy or consulate is 
> considered to be located in the sending country for purposes of legal 
> jurisdiction.  Extraterritoriality is virtually unlimited in the case of an 
> embassy; it is more limited in the case of a consulate but still exists

Allan, 

That doesn't sound quite right. As I read the UN conventions, the
diplomatic staff have some immunities which are linked to their personal
status and not linked to their being in the embassy buildings. The
premises themselves are inviolable by the host state, which means local
laws sometimes cannot actually be enforced without invitation from the
Ambassador. However, the embassy as a premises is still part of the
receiving country. Delivering pizza to them is not an export. The lease
contract is under the laws of the host country. Employment contracts for
support staff can be under the law of the host country. Their radio
transmitters need to be licensed by the host country. Diplomatic cars
have to pay speeding fines and parking tickets. But in the case of
violations, the only sanction available to the host country is basically
withdrawal of recognition of diplomatic staff. 

Have I misunderstood your interpretation of "extraterritoriality"? 

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


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

2018-10-25 Thread Colin Smale
On 2018-10-25 06:42, Graeme Fitzpatrick wrote:

> On Thu, 25 Oct 2018 at 11:41, Warin <61sundow...@gmail.com> wrote: 
> 
>> Err no.
>> 
>> The 'government' is not 'foreign' but of federal/state/local jurisdiction to 
>> that place.
>> 
>> landuse=diplomatic???
> 
> Yes, but that patch of ground is owned by the "Australian" govt - it's just 
> that it's located in the US or where-ever!

For the avoidance of doubt, it is owned by the "Australian govt" in the
same sense that I own my house (but it may also be rented or leased). It
is not outside of the host country's jurisdiction, if that's what you
were implying by "owned".___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-10-23 Thread Colin Smale
On 2018-10-23 23:15, Paul Allen wrote:

> On Tue, Oct 23, 2018 at 9:21 PM Colin Smale  wrote: 
> 
>> What's your point, Paul?
> 
> That there are distinctions between embassies and consulates.

And now back to the discussion in hand 

An embassy must be tagged/taggable to indicate whether it also offers
consular services such as visas. The proposal wiki contains a suggestion
to use  services [1]=visa;passport;refuge;ticket_home etc. An embassy
offering none these consular services will need to be tagged
services=none to prevent interpretation of a missing services=* tag as
"unknown" or "all services". 
  

Links:
--
[1]
https://wiki.openstreetmap.org/w/index.php?title=Key:servicesaction=editredlink=1___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-10-23 Thread Colin Smale
On 2018-10-23 20:50, Paul Allen wrote:

> On Tue, Oct 23, 2018 at 7:18 PM Colin Smale  wrote: 
> 
>> I know this is a big generalisation, but I hope you will agree there is an 
>> important difference.
> 
> An even bigger difference is that Consulate have a menthol filter but Embassy 
> have a plain 
> filter. 
> 
> I don't recall ever seeing a brand of cigarette called "Legation" though.

What's your point, Paul?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-10-23 Thread Colin Smale
One further thought... 

There is also a big functional difference between an embassy and a
consulate. The former is more government-oriented, whereas consulates
provide services to individual citizens. I know this is a big
generalisation, but I hope you will agree there is an important
difference. BUT some embassies also provide consular services, and some
don't - they might direct you to another address for your visa or
whatever. If we tag embassies and consulates distinctly, how do we add a
secondary tag to an embassy to indicate whether they do consular work or
not?

On 2018-10-23 19:55, Allan Mustard wrote:

> Colin Smale  wrote:
>> 
>> The location of an embassy in the capital is surely not prescribed by law, 
>> but by expedience isn't it? The ambassador wants/needs to be near the action 
>> in order to carry out their primary role - interfacing with the host country 
>> government. 
> Answer: Yes. The location of an embassy is typically negotiated with the host 
> country government and is indeed a matter of expedience in most cases.  
>> 
>> There are also examples of countries with split capitals. I am in one now 
>> (Netherlands) - the capital is Amsterdam, but the embassies are in The 
>> Hague, which is the seat of government but not the capital. 
> Answer: Yes, there are exceptions to every rule!  That's why defining an 
> embassy as the mission where one finds an ambassador is the easiest and most 
> reliable way of defining an embassy.  To the casual observer, an embassy is a 
> building with a sign on it that reads "Embassy" (as long as it isn't a 
> Embassy Suites Hotel or something similar) and a consulate is a building with 
> a sign containing the word "Consulate".
>> 
>> Why is the location even relevant to this discussion, anyway?
> Answer: Because in the OSM space there is confusion of embassies and 
> consulates.  A consulate is not an embassy, but in OSM the amenity=embassy 
> tag is applied to consulates.  I am proposing to correct that, and to do 
> that, mappers must understand both the differences between an embassy and a 
> consulate and how to differentiate between them. Thanks for your help!
> 
> ___
> 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 - (consulate)

2018-10-23 Thread Colin Smale
On 2018-10-23 15:57, Allan Mustard wrote:

> Regarding Warin's comment, 
> 
>> They did conform to the 'rule' of embassy/high commission only in the 
>> capital. 
> 
> There is a small number of highly visible exceptions to the rule of embassies 
> and of missions equivalent to embassies being located in the capital.  The 
> various missions of member states to the United Nations in New York and 
> Geneva as well as the missions to the WTO in Geneva come to mind (these are 
> all missions to a multilateral organization). Fortunately most other such 
> international organizations are located in national capitals (OECD in Paris, 
> NATO and the European Union in Brussels, OSCE and some UN agencies in Vienna, 
> other UN agencies in Rome).  The easy way to determine if a mission is 
> equivalent to an embassy is to find out who is in charge of it, which can be 
> learned by Googling the mission's website.  Generally speaking, if the head 
> of the mission is an ambassador or charge d'affaires, the mission should be 
> tagged amenity=embassy.  If the "principal officer" bears a title with the 
> word "consul" in it, the amenity in question is a consulate.  The obsolete 
> head of mission
titles "minister plenipotentiary" and "envoy extraordinary" have fallen into 
disuse and I don't think it likely we will encounter them.

The location of an embassy in the capital is surely not prescribed by
law, but by expedience isn't it? The ambassador wants/needs to be near
the action in order to carry out their primary role - interfacing with
the host country government. 

There are also examples of countries with split capitals. I am in one
now (Netherlands) - the capital is Amsterdam, but the embassies are in
The Hague, which is the seat of government but not the capital. 

Why is the location even relevant to this discussion, anyway?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Traffic_sign discussion

2018-10-09 Thread Colin Smale
I am not saying these cases are impossible, only that they have to be
accommodated, preferably as uniformly as possible. It is not intended as
criticism, but as a critical test of fitness for purpose. If the tagging
scheme can't handle these real-world situations, it's not ready for
go-live yet.

On 2018-10-09 23:40, yo paseopor wrote:

> On Tue, Oct 9, 2018 at 8:16 PM Colin Smale  wrote: 
> 
>> I can think of a couple of non-trivial cases which will need to be handled: 
>> 
>> 1) multiple signs on a single post
> 
> As Finnish people do we can add subkey :2 :3 :4... (European regulations does 
> nit recommend more than 3 traffic_signs together to make better their 
> readibility.

This is of course a fairly easy one. What European regulations are you
referring to here by the way? 

>> 2) signs with a dependent (qualifier) sign, such as "except for buses"
> 
> Complementary signs are also traffic signs (in second, in third position) 
> with its own code, so they need their information (the same osm tags we have 
> for ways?)  and position. A few weeks ago in this list I talk about the 
> possible changes for "designation" value to make a key with this more 
> specific information

How do you make the link between the qualifier and the main sign it
applies to? Does it only apply to the one sign immediately above? Or to
all signs above? Or the sign(s) below? How would these links work for
multiple qualifier signs, like "except for buses" / "except with
permit"? 

>> 3) one or more signs on a larger panel - too large to represent as a node
> 
> Sorry but I don't agree with you... because I test it...and it works. Example 
> for a complete destination traffic sign 
> 
> COLOUR:ARROW
> black
> 
> COLOUR:ARROW:LOWER_PANEL
> white
> 
> COLOUR:BACK
> white
> 
> COLOUR:BACK:LOWER_PANEL
> blue
> 
> COLOUR:REF
> red
> 
> COLOUR:REF:LOWER_PANEL
> blue
> 
> COLOUR:TEXT
> white
> 
> COLOUR:TEXT:LOWER_PANEL
> white
> 
> DESTINATION:LOWER
> Coma-ruga
> 
> DESTINATION:LOWER_PANEL
> Barcelona
> 
> DESTINATION:LOWER_PANEL:LOWER
> Aeroport
> 
> DESTINATION:LOWER_PANEL:UPPER
> Vilanova i la Geltrú
> 
> DESTINATION:SYMBOL:LOWER_PANEL:LOWER
> airport
> 
> DESTINATION:UPPER
> El Vendrell
> 
> LENGTH [1]
> 500
> 
> REF [2]
> N-340
> 
> REF:LOWER_PANEL
> C-32
> 
> SIDE
> up
> 
> TIME:1
> 00:05
> 
> TIME:3
> 00:05
> 
> TIME:B
> 01:00
> 
> TIME:B:1
> 00:20
> 
> TIME:B:3
> 00:45
> 
> TRAFFIC_SIGN:2:FORWARD
> ES:S235a
> 
> TRAFFIC_SIGN:FORWARD
> ES:S235a
> 
> TURN:DESTINATION
> under
> 
> TURN:DESTINATION:LOWER_PANEL
> under
> 
> TYPE [3]
> destination_sign

How does anyone or anything (a data consumer) connect the
"traffic_sign:forward=ES:S235a" to the way that it applies to? Not all
junctions are nice 4-way 90-degree junctions. What have you "tested"
exactly? Where do you place the node for this sign in relation to the
way? Maybe if you could give a link or an exact location of this sign,
then we could have a look and see what you intend. 

>> 4) signs applying only to certain lanes
> 
> you can specify the lanes and the exact information with all these tags 
> (lanes scheme already exists)

Of course the lanes scheme exists, but it is currently applied to ways.
Should we indicate a bus lane by a node representing the sign, or as an
attribute of the way? Surely not as both. No trucks in the left hand
lane? Easy to tag on the way with lanes tagging, but what about the
sign, which might also say "buses only in the second lane except on
Tuesday" etc etc. I am not trying to be difficult here - these crazy
scenarios really do occur, and OSM needs to be able to deal with them.
You are suggesting encoding this information as tagging on a single
node; I think that's a challenge if you expect anyone/anything to be
able to interpret it properly. 

>> 5) signs on a gantry above (half of) the road
> 
> The example above is like the granty sign (with the same tags)

Is a gantry tagged as a single node, or a "way" crossing the highway?
The gantry may cross the entire highway, but the signs are only in one
direction. How to handle that? 

>> I can understand the argument for mapping the signs as objects in their own 
>> right. This would be limited to being a database of street furniture, unless 
>> and until the effect of the signs can be linked to the effect they have on 
>> traffic (in the broadest sense), which is the starting point for the present 
>> discussion. This is of course a serious exercise to ensure the link from the 
>> sign to the effect is represented unambiguousl

Re: [Tagging] Traffic_sign discussion

2018-10-09 Thread Colin Smale
I can think of a couple of non-trivial cases which will need to be
handled: 

1) multiple signs on a single post 

2) signs with a dependent (qualifier) sign, such as "except for buses" 

3) one or more signs on a larger panel - too large to represent as a
node 

4) signs applying only to certain lanes 

5) signs on a gantry above (half of) the road 

I can understand the argument for mapping the signs as objects in their
own right. This would be limited to being a database of street
furniture, unless and until the effect of the signs can be linked to the
effect they have on traffic (in the broadest sense), which is the
starting point for the present discussion. This is of course a serious
exercise to ensure the link from the sign to the effect is represented
unambiguously. 

We already have turn restrictions, maxspeed, maxheight etc on the ways
themselves (without needing to have any link to a sign). This model
works reasonably well for routing applications, albeit not without some
discussion about the types of "weight" and so on. 

The point I am trying to make, is that there might not be much of a
"business case" for linking the signs/posts to their effects, and that
mapping them as "street furniture" might be going far enough... 

On 2018-10-09 17:42, yo paseopor wrote:

> I want to start the mother of all discussions about traffic signs 
> 
> It is not the first attempt to do that. Last days, with iD implementation and 
> my message I have think it was the solution. Also I have waited some days and 
> communicate to this list my intentions to adopt the proposed iD scheme. But 
> when I start to do the modifications... People complains about it (I am sorry 
> if there was some errors "translating" to the new scheme). 
> 
> So Please , let's talk about it. What will be the correct way to tag a 
> traffic sign? 
> 
> I start with my option. Traffic sign as a NODE on the way x direction. 
> Because traffic sign is relative to the way, the road, not the building or 
> the street itselfs, it is located above, as a road mark, on the right of the 
> road or on the left of the road (or both of them). 
> 
> I'm interested in all countries so a good way to do it is with the country 
> code for every traffic sign you can find in every traffic law in every 
> country.  
> It would be interesting also to develope a generic scheme for tagging it (not 
> only the country/code) 
> 
> traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of 
> each country traffic signs law) 
> 
> Also it is facing to the direction of the way (forward and backward). In OSM 
> ways have the direction you have drawn it. So the info is relative to this 
> direction. 
> 
> As an issue detected in iD with it to make possible the edition of traffic 
> signs good way was the traffic_signals solution: an specific key. 
> 
> traffic_sign:direction=forward/backward/both 
> 
> Also accepts other facing directions like 90/270... 
> 
> Also we need the info relative to the way of its location , the side where it 
> is: Is it on the right? Is it on the left?  
> 
> side=right/left/both 
> 
> And also position, because you can have more than one traffic sign. Finnish 
> people give the solution :2 
> 
> traffic_sign:2=* 
> 
> To tag this we have some informations sources (of course first of all local 
> knowledge) like Mapillary or OpenStreetCam. 
> 
> Tools we have now: 
> 
> JOSM preset 
> JOSM style 
> JOSM Kendzi3D's configuration files and models 
> Leaflet traffic signs map 
> Taginfo stats 
> 
> More info about it : 
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>  
> 
> Main characteristics of the scheme: 
> 
> -Scalable (you can locate every traffic sign in every place) 
> -Exportable (you can locate every traffic sign of every country in the World, 
> with or without JOSM wizards) 
> -1 key / 1 value (for making the renders easy to adopt it) 
> 
> yopaseopor 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Digest, Vol 108, Issue 162

2018-09-29 Thread Colin Smale
I would prefer to stay close to real life if possible. We should
choose/adapt our tagging model to match reality, and not try to force
reality into unnatural boxes. If real life has the possibility of
overlaps, we should allow for that. Making the way for "river_feature"
colinear with any existing "centre line" is an artificial construct for
possible convenience. But if it starts limiting our ability to model the
world, then we should abandon that idea. We should not be feeling sorry
for the poor old database because it has to store a few extra nodes. The
name of a given river section is merely a convenience to a canoeist,
whereas warnings about rapids are slightly more important (I imagine,
anyway). I suppose there would be nothing wrong with having a river
section labelled with a name (as we are discussing here), and in
addition, information for the canoeist. How is this latter information
currently modelled in OSM? Is it possible that "rapids" or whatever do
not cover the whole width of the river? In that case they will need
their own polygon. Maybe we should not try to mix up "rapids" etc with
the naming of sections. 

On 2018-09-29 14:22, Yves wrote:

> For the rare case a 'section' should have two names, the smallest part can 
> have it I guess.
> Instead of section or reach, there's :part, like in building:part. 
> 
> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg 
>  a écrit : Practically, if the ways overlap, it 
> may be hard to render the name labels and interpret the data. 
> 
> I'm imagining a routing app for boaters or paddlers. It could announce the 
> name of each new reach, bend and section, and also warn of hazards: "bridge 
> in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this case, it 
> would be harder to use river sections that overlap.
> 
> Also, if you wanted to download all the parts of the river into a 
> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
> 
> I do like Yves's suggested tags, for this reason
> 
> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale  wrote: 
> 
> river_feature would be fine as well as it would imply that it doesn't need to 
> be a linear feature, a node would also be OK (for small named bays etc?)
> 
> Lets have a go at agreeing the basic principles of what we are trying to 
> achieve.  
> 
> * there can be contiguous linear sections of a river which can have names 
> * there can be small features with names, such as small bays which can better 
> be represented by a node 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * in the case of linear feature, they encompass the entire width of the river 
> and are not just a 2D line 
> * for "river", read (river OR stream OR drain OR...) 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) OR a node for smaller / non-linear features 
> * waterway=river_feature 
> * river_feature={reach,bend,bay,...} 
> 
> * name=* 
> 
> I would like this to be applicable to lakes as well (why not?) but it's 
> difficult to see how a linear feature would apply to a lake. Any comments? 
> 
> There was a suggestion that we should re-use existing flow lines and not 
> superimpose new ways. This would not allow for the fact that two linear 
> features may overlap - the end of a "bend" may overlap with the first bit of 
> a "reach" for example. The extent of these features may be well defined, but 
> they may not be so sharp. My thought is that this freedom to allow overlaps 
> is important. Any comments? 
> 
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote: 
> 
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
> The point of raising the "reach" business it to help abstracting the proposed 
> tagging model to make it more generic. If we consolidate all the thoughts 
> expressed so far, we can say that:
> 
> * there can be contiguous linear sections of a river which can have names 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * they encompass the entire width of the river and are not just a 2D line 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) 
&

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

2018-09-29 Thread Colin Smale
river_feature would be fine as well as it would imply that it doesn't
need to be a linear feature, a node would also be OK (for small named
bays etc?)

Lets have a go at agreeing the basic principles of what we are trying to
achieve.  

* there can be contiguous linear sections of a river which can have
names 
* there can be small features with names, such as small bays which can
better be represented by a node 
* they can be "straight" (for example "reaches") or "curved" (for
example "bends") 
* they can (partially) overlap each other, and there may be gaps (there
may not be a clear, sharp transition from one section to the next) 
* in the case of linear feature, they encompass the entire width of the
river and are not just a 2D line 
* for "river", read (river OR stream OR drain OR...) 

This is pointing towards: 
* a way along the centre line of the river (colinear with the
main_stream lines?) OR a node for smaller / non-linear features 
* waterway=river_feature 
* river_feature={reach,bend,bay,...} 

* name=* 

I would like this to be applicable to lakes as well (why not?) but it's
difficult to see how a linear feature would apply to a lake. Any
comments? 

There was a suggestion that we should re-use existing flow lines and not
superimpose new ways. This would not allow for the fact that two linear
features may overlap - the end of a "bend" may overlap with the first
bit of a "reach" for example. The extent of these features may be well
defined, but they may not be so sharp. My thought is that this freedom
to allow overlaps is important. Any comments? 

On 2018-09-29 00:11, Graeme Fitzpatrick wrote:

> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
>> The point of raising the "reach" business it to help abstracting the 
>> proposed tagging model to make it more generic. If we consolidate all the 
>> thoughts expressed so far, we can say that:
>> 
>> * there can be contiguous linear sections of a river which can have names 
>> * they can be "straight" (for example "reaches") or "curved" (for example 
>> "bends") 
>> * they can (partially) overlap each other, and there may be gaps (there may 
>> not be a clear, sharp transition from one section to the next) 
>> * they encompass the entire width of the river and are not just a 2D line
> 
>> This is pointing towards: 
>> * a way along the centre line of the river (colinear with the main_stream 
>> lines?) 
>> * waterway=river_section 
>> * river_section={reach,bend,...} 
>> * name=*
> 
> Liking your train of thought Colin. 
> 
> Just wondering, perhaps =river_feature? 
> 
> I'm not certain about "they encompass the entire width of the river" though? 
> Would that then exclude things like _"The Deep Hole"_ & _"17 Mile Rocks"_, 
> which are both named spots that I can point out on a map? 
> 
> Thanks 
> 
> Graeme  
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Digest, Vol 108, Issue 162

2018-09-28 Thread Colin Smale
On 2018-09-28 07:37, Dave Swarthout wrote:

> The discussion about the definition of "reach" is interesting but IMO it's 
> slightly off topic.  Perhaps, because of those differences in its 
> interpretation, we would be best served by not using the term at all.

The point of raising the "reach" business it to help abstracting the
proposed tagging model to make it more generic. If we consolidate all
the thoughts expressed so far, we can say that: 
* there can be contiguous linear sections of a river which can have
names 
* they can be "straight" (for example "reaches") or "curved" (for
example "bends") 
* they can (partially) overlap each other, and there may be gaps (there
may not be a clear, sharp transition from one section to the next) 
* they encompass the entire width of the river and are not just a 2D
line 

This is pointing towards: 
* a way along the centre line of the river (colinear with the
main_stream lines?) 
* waterway=river_section 
* river_section={reach,bend,...} 
* name=* 

Is this a basis that we can work incrementally forwards from?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging a named river bend

2018-09-27 Thread Colin Smale
I guess this can also apply to named straight bits as well? 

http://onthethames.net/reaches-river-thames/

On 2018-09-27 11:58, Dave Swarthout wrote:

> I'm working on adding islands and other features in the Tanana River in 
> Alaska. There are many named sloughs (side channels), islands and in some 
> areas curves or bends that have a name. In my example there is a large bend 
> in the river that has its own name, Harper Bend. I'm looking for a way to tag 
> that section so that the name is findable. It would be nice but not 
> imperative if that name would display on the OSM slippy map and incidentally, 
> on my GPSr. 
> 
> If I break the river at both ends of the curve, I could add the name to the 
> section between the breaks but that doesn't seem right because the river's 
> name isn't changing. Another much more complicated solution would be to break 
> the riverbank into sections and add a name to the one that encompasses the 
> bend. 
> 
> I don't know why I didn't ask here first but I raised this question on the 
> OSM Help forum and one answer was to use a node. But if one goes that way, I 
> reckon a new tag would be needed. So let's begin our discussion with that. 
> Given that it's important to me to describe our mapped objects as completely 
> as possible, I want a method to tag such a bend. 
> 
> Suggestions? Opinions? 
> Best, 
> Dave 
> -- 
> 
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Topographic Prominence for Peaks

2018-09-27 Thread Colin Smale
On 2018-09-27 07:17, Graeme Fitzpatrick wrote:

> & when you say survey with GPS, is that accurate enough for an altitude 
> reading? With my Garmin GPS (which admittedly is 10 - 15 years old, but 
> _wasn't_ a cheap one!), I can calibrate it in the back yard at 6m ASL, go for 
> a day trip & when I get home, it displays the exact same spot as anything 
> between -5 & +30m ASL :-( When out driving, I've also seen the altitude 
> display change by 100s of m's instantly, when the road is virtually flat.

...bearing in mind that ele=* is supposed to be expressed in WGS84 /
EGN96 not relative to a local sea level datum, so if your GPS already
applies a "correction" to show you heights relative to sea level, you
have to back those corrections out, or put the datum in the OSM
tagging 

GPS is not very accurate in the vertical direction, due to the altitude
of the satellites and the geometry involved. In the horizontal
directions, you are surrounded on all sides by satellites which can give
a fairly accurate fix. In the vertical plane the angles to the
satellites are limited to the half sphere you can "see" without going
through the earth.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-26 Thread Colin Smale
On 2018-09-26 06:32, Mark Wagner wrote:

> That's not what I said.  To repeat, my point is that, at least locally,
> a signposted speed limit *is* a guarantee that, for an ordinary vehicle
> traveling under ordinary conditions, the speed is reasonable.  An
> unsigned speed limit, on the other hand, does *not* carry that
> guarantee.

Sorry Mark, you are wrong. There is no guarantee, signposted or not. 

Besides the speed in relation to road geometry, I know of many
situations with speed bumps which would destroy your suspension if you
drove over them with the permitted maximum speed.___
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-25 Thread Colin Smale
On 2018-09-25 13:07, Marc Gemis wrote:

> However, I'm not sure whether gastronomic is the proper
> British-English word to use. I think the Brits are already using
> building=pub (perhaps only for a subclass of your 'gastronomic'.

The predicate "gastronomic" implies a certain level of quality, aimed at
good-food-lovers. Fast-food would not be gastronomic, nor would many
restaurants and pubs. However a modern invention is the "gastro-pub"
where they consider their food to be of a particularly high standard,
not just standard pub food.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-22 Thread Colin Smale
On 2018-09-22 23:54, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 22. Sep 2018, at 17:53, Colin Smale  wrote:
>> 
>> Opening_hours should cover this, i.e. when can the public just turn up and 
>> speak to someone. But that is not going to be an emergency.
> 
> maybe service_times could cover it, opening_hours are about something 
> different.

I agree they are different but the wiki infers that service_times are
more individual times (i.e. not periods) and the German wiki says that
service_times are for religous services! To my mind, opening_hours still
seems to fit best. After all. in that regard a police station is no
different to a shop, is it?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Toll Gantry

2018-09-22 Thread Colin Smale
On 2018-09-22 22:50, Volker Schmidt wrote:

> A toll_bridge [1] is a bridge for which you have to pay to pass, 
> highway=toll_bridge should be a highway that is a toll-bridge, not a 
> mechanical structure that is installed above a road to check the passing 
> traffic. This would be a gantry [2] 
> https://en.wikipedia.org/wiki/Gantry_(road_sign)

Exactly. A toll bridge should be highway=motorway (or whatever) +
bridge=yes + toll=yes in OSM. 

A gantry is only the structure; it might carry all manner of devices in
any combination, and even if it had no devices on it, it would still be
a gantry...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-22 Thread Colin Smale
On 2018-09-22 17:24, Martin Koppenhoefer wrote:

> The thing about a (non-) emergency police station could be that some police 
> stations close (at night, at noon, on weekends), so you would not rely on 
> them for emergencies.

In an emergency you don't go to the {police,ambulance,fire} station, you
dial 112 / 999 / 911. What is the use of having the "emergency" tag? 
Opening_hours should cover this, i.e. when can the public just turn up
and speak to someone. But that is not going to be an emergency. 

There are also "remote police stations" with a video link to a main
location.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-22 Thread Colin Smale
Well said, I agree wholeheartedly. A local, anecdotal view is in itself
not enough to produce a data model that works for everyone.

On 2018-09-22 14:22, Tobias Zwick wrote:

> Tagging an implicit speed limit explicitly for example in town with
> maxspeed=50 is straightforward enough for Germany. It seems natural that
> no specialist knowledge is required for that kind of thing. For a German.
> 
> But let's look at some other countries for the default urban speed limit.
> 
> Spain (ES):
> maxspeed=50
> maxspeed:hazmat=40
> 
> Chile (CL):
> maxspeed=60
> maxspeed:bus=50
> maxspeed:hgv=50
> 
> Hungary (HR):
> maxspeed=50
> maxspeed:tricycle=40
> 
> Kerala in India (IN-KL):
> maxspeed=50
> maxspeed:conditional=40 @ (weight > 7.5)
> maxspeed:trailer=40
> maxspeed:bus_articulated=40
> maxspeed:hgv_articulated=40
> maxspeed:bus:conditional=40 @ (weight > 7.5)
> maxspeed:hgv:conditional=40 @ (weight > 7.5)
> maxspeed:tricycle=30
> 
> Punjab in India (IN-PB):
> maxspeed=50
> maxspeed:trailer=35
> maxspeed:bus_articulated=30
> maxspeed:hgv_articulated=30
> maxspeed:hgv=45
> maxspeed:hgv:conditional=40 @ (weight > 6)
> maxspeed:conditional=40 @ (weight > 6)
> maxspeed:trailer:conditional=30 @ (weight > 6)
> maxspeed:motorcycle=35
> maxspeed:goods=45
> maxspeed:goods:conditional=40 @ (weight > 6)
> 
> Malta (MT):
> maxspeed=50
> maxspeed:bus=40
> maxspeed:hgv=30
> maxspeed:goods=40
> maxspeed:goods:conditional=30 @ (weight > 3)
> 
> Poland (PL):
> maxspeed=50
> maxspeed:conditional=60 @ (23:00-05:00)
> 
> Zambia (ZM):
> maxspeed=50
> maxspeed:conditional=40 @ (weight > 2.275)
> maxspeed:trailer=40
> maxspeed:hgv=40
> 
> Because the maxspeed tag applies to all vehicles except overridden for a
> specific vehicle type or a conditional, specifying only maxspeed=50 in
> any of the above cases has to be considered wrong or at least
> incomplete. In other words, the tags you see above would need to be
> added in the case the speed limit is given explicitly. It is not so
> straightforward then anymore.
> 
> So, maybe not for Germany, but as you see, in other places, this *is*
> specialist knowledge. No regular car driver in Punjab will be able to
> enumerate all these maxspeed rules. And, taking a less extreme example,
> I think the Polish OSM contributors wouldn't want to add this
> maxspeed:conditional=60 @ (23:00-05:00) to every single unsigned street
> in urban areas.
> 
> Also, note this is only the urban speed limit, trust me, the default
> speed limit "for all other roads" (=rural) can be much more complex.
> 
> Actually, don't trust me, see for yourself in the document I link all
> the time in the hope people would read it:
> https://wiki.openstreetmap.org/wiki/Default_speed_limits
> 
> We can not get to any results or any progress on the matter of default
> speed limits (or for any topic, for that matter) if everyone just keeps
> arguing out of his best knowledge about his home region or country only.
> 
> "It works for me" is simply not good enough for a global project.
> 
> Cheers
> Tobias
> 
> On 22/09/2018 01:03, Martin Koppenhoefer wrote: 
> 
> sent from a phone
> 
> On 19. Sep 2018, at 21:16, Tobias Zwick  wrote:
> 
> This is a good argument against tagging an explicit maxspeed=X when
> there is actually no speed limit sign around (X is what the OSM mapper
> by his knowledge about the law thinks should be the default limit here). 
> 
> everything that you map will be according to your understanding of it, I 
> cannot see a good argument for not tagging implicit limits, even more as 
> there is judgement needed based on the situation (something humans can do 
> much better than computers). Every holder of a driving license should have 
> the requisites to recognize the speed limit on a given piece of road in their 
> local area, so it doesn't require specialist knowledge.
> 
> We already have a reliable way to distinguish implicit from explicit limits 
> (we even have several of them), if you want to treat them differently in your 
> app, you can do it.
> 
> There actually is a speed limit on most roads, including those without 
> explicit signage. Omitting it will leave us in the situation that it really 
> becomes unclear whether there is no sign or nobody has bothered to enter it.
> 
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-21 Thread Colin Smale
There is a parallel discussion going on about
landuse=civil_administration which might include smaller areas for
individual government offices. Just wondering if an ambulance station
(or fire station or police station for that matter) might be analogous. 

I believe that landuse tagging should be monovalent and contiguous -
ultimately, every point on land should come under exactly one landuse
value, with the exception of land that has not been put to any use by
humans.

On 2018-09-21 11:17, Anton Klim wrote:

> I'm not sure I understand why it would be a landuse instead of an amenity tag 
> on the area, or the other way round? Are landuses supposed to be for larger 
> areas?
> 
> 21 сент. 2018 г., в 9:58, Colin Smale  написал(а):
> 
> What about landuse=ambulance_station on the area? What would the landuse be 
> otherwise?
> 
> Asking for a friend... 
> 
> On 2018-09-21 10:47, dktue wrote: How about ambulance stations?
> 
> Should we tag the area with emergency=ambulance_station and the building with 
> building=ambulance_station?
> 
> dktue
> 
> Am 21.09.2018 um 03:23 schrieb Mike H: 
> I've only mapped one station like this so far, but the area is actually 
> rendered on the map. https://www.openstreetmap.org/way/616033018 
> 
> On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer  wrote: 
> Yes of course, I've been doing this for long already.
> 
> On 20.09.2018 14:06, Philip Barnes wrote:
>> Yes, just go for it. Makes perfect sense.
>> 
>> Phil (trigpoint)
>> 
>> On 20 September 2018 12:56:03 BST, dktue  wrote:
>> 
>> Hello,
>> 
>> I love how we map areas with amenity=school and buildings inside of it
>> with building=school. The same goes for amenity=hospital and
>> building=hospital.
>> 
>> What I'd like to have is the same schema for firestations: They often
>> have a large area and one or multiple buildings on it.
>> 
>> Should I go with amenity=fire_station for the area and
>> building=fire_station for the buildings inside of it?
>> 
>> Cheers,
>> dktue
> 
> ___
> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] Area of Firestations / Area of Ambulancestations

2018-09-21 Thread Colin Smale
What about landuse=ambulance_station on the area? What would the landuse
be otherwise?

Asking for a friend... 

On 2018-09-21 10:47, dktue wrote:

> How about ambulance stations?
> 
> Should we tag the area with emergency=ambulance_station and the building with 
> building=ambulance_station?
> 
> dktue
> 
> Am 21.09.2018 um 03:23 schrieb Mike H: 
> I've only mapped one station like this so far, but the area is actually 
> rendered on the map. https://www.openstreetmap.org/way/616033018 
> 
> On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer  wrote: 
> Yes of course, I've been doing this for long already.
> 
> On 20.09.2018 14:06, Philip Barnes wrote:
>> Yes, just go for it. Makes perfect sense.
>> 
>> Phil (trigpoint)
>> 
>> On 20 September 2018 12:56:03 BST, dktue  wrote:
>> 
>> Hello,
>> 
>> I love how we map areas with amenity=school and buildings inside of it
>> with building=school. The same goes for amenity=hospital and
>> building=hospital.
>> 
>> What I'd like to have is the same schema for firestations: They often
>> have a large area and one or multiple buildings on it.
>> 
>> Should I go with amenity=fire_station for the area and
>> building=fire_station for the buildings inside of it?
>> 
>> Cheers,
>> dktue
> 
> ___
> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] landuse for government offices ?

2018-09-20 Thread Colin Smale
On 2018-09-20 12:22, John Willis wrote:

>> On Sep 20, 2018, at 5:39 PM, Colin Smale  wrote:
>> 
>> Maybe it's just me, but I really can't understand why landuse for government 
>> functions needs its own tagging. The buildings are often indistinguishable 
>> from commercial properties
> 
> Why does what the buildings look like matter?

That is yet another dimension - architectural style. But why is
"government" a specific case of "land use"? It is actually referring to
the activity carried on within. 

> Many parks are indistinguishable from natural=grassland or landuse=farmland, 
> but we make the distinction.

There could be areas which are all three at once. At a macro scale, part
of a farm, but a field to which the public has controlled access. 

> In many places, a city hall is a very different place than an ordinary office 
> building - even if we don't care that much about them.

If you are talking about architectural style, I agree. You can always
find examples to show this, and I am sure there are examples which show
the opposite as well. But this discussion is about land usage, and
whether a government office is any different to any other office in
terms of the usage of the land.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] landuse for government offices ?

2018-09-20 Thread Colin Smale
Maybe it's just me, but I really can't understand why landuse for
government functions needs its own tagging. The buildings are often
indistinguishable from commercial properties - what is different is that
the occupier is some statutory organisation. We don't tag
landuse=charity, or landuse=private, or landuse=education, so why
landuse=civic_admin? If you want to know who the tenant of a certain
building is, let's have tenant=City of Blah and allow this for any
building (or campus). Same arguments against landuse=religious. Why
should farm be tagged as landuse=religious instead of landuse=farmland
just because it is run by monks? Land use is the use a piece of land is
put to, and not WHO is doing the using or WHY they are doing it. If we
want to record those other dimensions, use different tags instead of
further complicating the landuse mess. 

On 2018-09-20 08:25, Andy Townsend wrote:

> On 20/09/18 03:57, John Willis wrote: 
> 
>> ... Retail is always wrong. Commercial is a crutch.
> 
> In your part of the world, perhaps.  Elsewhere, this isn't guaranteed to be 
> the case.  Certainly here in the UK many formerly "civic" services have been 
> privatised and are run for out-and-out commercial gain; others are run as 
> commercial entities owned by the government or non-governmental third sector 
> organisations.  What this means is that people will need to pick the landuse 
> that works best for them in their local area - to say that something is 
> "always wrong" is, in OSM, almost always wrong(!).
> 
> Best Regards,
> 
> Andy
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-19 Thread Colin Smale
In many countries in Europe, the "Welcome to XXX" sign as you enter a
town/village has the effect of delineating the "built-up area" for
traffic purposes and introduces a specific speed limit, without any
numbers being mentioned. In the countries I know in Northern Europe it
means "maxspeed=50 kmh" until you leave the town/village (unless
otherwise indicated of course). And that is independent of the type of
road by the way. On a motorway you will not pass one of these official
signs, so you carry on at 130 or whatever. The sign would be on the exit
ramps. 

The built-up area for traffic law purposes is therefore often
non-contiguous, made up of lots of polygons. You just have to know if
you are in or out of a built-up area, because it makes a difference to
many things about traffic laws (not just maxspeed).

On 2018-09-19 16:28, Jérôme Seigneuret wrote:

> Hi, tagging list  
> I just join it. 
> 
> For your information there is part of proposed tagging schema in french 
> subject discuss with @djakk.dj...@gmail.com  
> 
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/090189.html 
> 
> Values of legal type can be thinking in specific territory area and resolve 
> "in my opinion" lot of case and subject in relation to access, maxspeed, and 
> legal dimension. the last term is "the case" of lot of problem of tagging 
> because it can't be appreciated just with maxspeed and access definition. 
> 
> All cases will be deliberate. Speak with law school faculty or a lawyer can 
> help us to see all cases. 
> 
> Jérôme 
> 
> Le mer. 19 sept. 2018 à 15:57, Paul Johnson  a écrit : 
> 
> On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote: 
> 
> By the way, we should de-correlate the legal status of an highway from the 
> highway tag : with the key highway:legal_type, values : business_area or 
> residential_area or an other local legal classification. A highway=tertiary 
> could also be highway:legal_type=residential_area 
> 
> This seems like it would be way less complicated and way easier to 
> troubleshoot and way easier to approach when you're new to the project to 
> just use source:maxspeed=* to explain the context. 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-19 Thread Colin Smale
A "maximum" speed does not mean an "advised" speed. If you are driving
at an unsuitable speed, below the posted maximum, in Europe you will not
get a ticket for "speeding" as such but you may get one for "dangerous
driving" or something similar. The obligation to drive in a safe way
overrides all other more specific limitations. Think of overtaking -
just because it's not prohibited, doesn't make it safe (reasonable and
prudent). 

There is no point in trying to reflect this "reasonable and prudent"
stuff in OSM. We should stick to the objective limits, by virtue of
signposting and/or  statutes.

On 2018-09-19 09:51, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 19. Sep 2018, at 08:01, Tod Fitch  wrote:
>> 
>> California, and I suspect most if not all other states, has a reasonable and 
>> prudent clause in the speed statutes too. So depending on conditions, 
>> especially weather conditions, theoretically you can get a speeding ticket 
>> while driving under the signed or prima facia speed limit.
>> 
>> However I think that is a diversionary argument that basically implies that 
>> we can't tag any road with a speed limit because the default or signed speed 
>> limit can be trumped by a reasonable and prudent clause in the motor vehicle 
>> code.
> 
> I'd guess most jurisdictions will have a clause like this, Italy and Germany 
> have them as well, but unless you are involved in an accident you won't get 
> into problems as long as you respect the signposted or default limits. There 
> may be different implicit limits for certain weather conditions (e.g. 50kph 
> if visibility is inferior to 50m), but this is not comparable to vague 
> indications like "reasonable".
> 
> cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-15 Thread Colin Smale
Joseph, I have to admit I am getting a bit lost as to what you are
trying to define with this proposal. Whatever tagging we end up with,
who is the target audience? What are the use cases? Is it an aid to
interpreting and pronouncing the contents of the "name" tag? Is it a
(strong) hint to mappers about how to synthesize multilingual labels? Is
it documenting the official languages, or the popular spoken languages,
or what? 

Take Brussels for example. Officially bilingual for political reasons,
in practice large parts are essentially French-only. Composite street
names can be nl - fr or fr - nl. Can I suggest we work through Belgium
as a case study, and when there is a proposal to suit Belgium, we then
cross-check with e.g. Switzerland, Morocco, Spain or whatever?

On 2018-09-15 17:15, Joseph Eisenberg wrote:

> Re: "How about "name:language_order=fr;nl"? No confusion possible there, 
> whereas "name:language=fr;nl" would not specify the order, unless you define 
> the list of languages to be an ordered list, which AFAIK would be a new 
> concept to OSM." 
> 
> In Brussels they would actually like to be able to display the two languages 
> neutrally, without a set display order. I don't think a display order 
> specification is necessary. That information is already in the default 
> "name=*" tag 
> 
> "Is it intended to be only for street names? If so, highway:name:language=* 
> might be required to make that clear. Or does everything that can have a name 
> need to fit in with this?" 
> 
> Not only streets. Everything with a name=* tag has the same issues 
> 
> On Sat, Sep 15, 2018 at 11:02 PM Colin Smale  wrote: 
> 
> On 2018-09-15 15:18, Joseph Eisenberg wrote: 
> 
> Re: "A default should not require multiple values! It is the single value to 
> be used in the absence of an explicit value. If you think you need multiple 
> defaults, see my comment above about different contexts." 
> 
> The idea is to allow a community to choose 2 languages to be displayed 
> together as the default language setting, if so desired. If you check out the 
> Multilingual Names wiki page [1], there are places where people choose to 
> standardize the default name=* be a combination of two languages or two 
> encodings; eg  fr + nl in Brussels, or Arabic + French in Moroco. If this is 
> going to be adopted by the folks in Belgium, Morocco etc, there should be the 
> choice of specifying two (or 3) languages, to fit with their current 
> preference.  
> 
> How about "name:language_order=fr;nl"? No confusion possible there, whereas 
> "name:language=fr;nl" would not specify the order, unless you define the list 
> of languages to be an ordered list, which AFAIK would be a new concept to 
> OSM. 
> 
> I'm not trying to change the way the default name=* tag is used, just trying 
> to make it more useful by tagging what language is actually being used in the 
> value for the name key. And I suspect there may be more communities that will 
> choose this option, to encourage displaying names both in the local langauge 
> and in the official or national language. 
> 
> So your idea is only for multilingual areas? Seems a bit of a waste. Combine 
> this with "name:language=fr" in Wallonia, "name:language=nl" in Flanders, 
> "name:language=de" in the Ostkantons, and "name:language=fr;nl" in Brussels? 
> 
> Is it intended to be only for street names? If so, highway:name:language=* 
> might be required to make that clear. Or does everything that can have a name 
> need to fit in with this? 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Multilingual_names___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-15 Thread Colin Smale
On 2018-09-15 15:18, Joseph Eisenberg wrote:

> Re: "A default should not require multiple values! It is the single value to 
> be used in the absence of an explicit value. If you think you need multiple 
> defaults, see my comment above about different contexts." 
> 
> The idea is to allow a community to choose 2 languages to be displayed 
> together as the default language setting, if so desired. If you check out the 
> Multilingual Names wiki page [1], there are places where people choose to 
> standardize the default name=* be a combination of two languages or two 
> encodings; eg  fr + nl in Brussels, or Arabic + French in Moroco. If this is 
> going to be adopted by the folks in Belgium, Morocco etc, there should be the 
> choice of specifying two (or 3) languages, to fit with their current 
> preference.

How about "name:language_order=fr;nl"? No confusion possible there,
whereas "name:language=fr;nl" would not specify the order, unless you
define the list of languages to be an ordered list, which AFAIK would be
a new concept to OSM. 

> I'm not trying to change the way the default name=* tag is used, just trying 
> to make it more useful by tagging what language is actually being used in the 
> value for the name key. And I suspect there may be more communities that will 
> choose this option, to encourage displaying names both in the local langauge 
> and in the official or national language.

So your idea is only for multilingual areas? Seems a bit of a waste.
Combine this with "name:language=fr" in Wallonia, "name:language=nl" in
Flanders, "name:language=de" in the Ostkantons, and
"name:language=fr;nl" in Brussels? 

Is it intended to be only for street names? If so,
highway:name:language=* might be required to make that clear. Or does
everything that can have a name need to fit in with this? 
  

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Multilingual_names___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-15 Thread Colin Smale
On 2018-09-15 06:33, Joseph Eisenberg wrote:

> I like the word "default"; it doesn't make a value judgement or have positive 
> / negative connotations. And it sounds like it has to do with how the 
> database should function, which is the right idea. The most common language 
> used for names should be the "default", whether or not it is official.

As long as it is made explicit what the scope is for this default. We
may need different default languages for different contexts.
Interpreting name=* is one thing but it is a different concept to the
locally spoken language(s), or the official language(s) for example. 

> _language:default=_ has the advantage of being searchable with a simple 
> query like "language:default=*" in Taginfo, Overpass and JOSM. But it 
> requires the use of semicolons to specify multiple default languages.

A default should not require multiple values! It is the single value to
be used in the absence of an explicit value. If you think you need
multiple defaults, see my comment above about different contexts.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-14 Thread Colin Smale
On 2018-09-14 08:47, Frederik Ramm wrote:

> I'd go for a mixed approach - tag the (largest useful) administrative
> boundary first, and then allow lower level admin boundaries and finally,
> place nodes, to override the default.

Sounds good! Let's use that approach for e.g. maxspeed as well. It looks
like you have just solved the old "defaults" problem.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-11 Thread Colin Smale
On 2018-09-11 08:27, Graeme Fitzpatrick wrote:

> We will need to be a little pragmatic, because OSM mappers are never going to 
> be able to do a proper survey of the coastline 
> I agree, but we also can't easily say where the tidal limit reaches?

In most cases the state mapping or hydrography agency will know. They
have the gear, the knowledge and the mandate to make that determination.


>> but that is a separate issue to the COASTLINE discussion.
> 
> Maybe, but personally, I still think that the river banks shouldn't be marked 
> as coastline, & that the coastline should cut across the river at the coast, 
> so I guess we may agree to continue disagreeing :-)

I guess so, but what is at stake here is not getting you or me to change
our minds, but to define what the word means in an OSM context. Mappers
may also disagree about the definition of "highway" (including or
excluding the grassy bits?) but IMHO data consumers have a right to
being able to interpret the data as the mapper intended. If different
mappers use a tag in differing ways, how is the consumer to know the
intention? Having differing conventions for each country is just about
doable, but if individual mappers all have their own definitions, the
data becomes less valuable. There is much discussion and debate about
selected tagging topics, but the only thing that really counts is the
result, conclusion, consensus etc that should come out of it.
Unfortunately it rarely does, and that saddens me.  OSM is broadening
its reach to more and more parts of the world, and that is good, but
there needs to be equal effort put in to the depth of data and the
quality (consistency) of the data. 

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


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-10 Thread Colin Smale
On 2018-09-10 11:34, Colin Smale wrote:

> On 2018-09-10 11:25, Martin Koppenhoefer wrote: 
> 
> 2018-09-10 10:41 GMT+02:00 Colin Smale :
> 
> The baseline is defined by the state, in accordance with the UNCLOS rules, 
> and published to the world by deposition with the UN. The basis for the 
> baseline is: "the normal baseline for measuring the breadth of the 
> territorial sea is the low-water line along the coast as marked on 
> large-scale charts officially recognized by the coastal State." 
> http://www.un.org/depts/los/convention_agreements/texts/unclos/part2.htm 
> is there also a definition for an "unnormal" or exceptional baseline? E.g. 
> here: http://www.nonnodondolo.it/userfiles/image/37(1).gif 
> you can see that e.g. the whole gulf of taranto is included by the baseline 
> https://en.wikipedia.org/wiki/Gulf_of_Taranto 
> From what I have seen, although there is the UN definition about the low 
> water line, actual baselines tend to be much more "generous". The baselie is 
> what the country self declares and other countries accept/recognize. 
> Also the 12nmi extension (territorial waters) is not always the same, some 
> countries pretend(ed) 200 nautical miles.

Up to 200nm is the EEZ (Exclusive Economic Zone), that's not the same.
There's a neat explanation and diagram here: 
https://sites.tufts.edu/lawofthesea/chapter-two/ 

The situation with the Gulf of Taranto is that Italy claims it is an
"historic bay" for which the convention indeed makes an exception. What
constitutes an "historic bay" is not defined in the Convention
however...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-10 Thread Colin Smale
On 2018-09-10 11:25, Martin Koppenhoefer wrote:

> 2018-09-10 10:41 GMT+02:00 Colin Smale :
> 
>> The baseline is defined by the state, in accordance with the UNCLOS rules, 
>> and published to the world by deposition with the UN. The basis for the 
>> baseline is: "the normal baseline for measuring the breadth of the 
>> territorial sea is the low-water line along the coast as marked on 
>> large-scale charts officially recognized by the coastal State." 
>> http://www.un.org/depts/los/convention_agreements/texts/unclos/part2.htm
> 
> is there also a definition for an "unnormal" or exceptional baseline? E.g. 
> here: http://www.nonnodondolo.it/userfiles/image/37(1).gif 
> you can see that e.g. the whole gulf of taranto is included by the baseline 
> https://en.wikipedia.org/wiki/Gulf_of_Taranto 
> From what I have seen, although there is the UN definition about the low 
> water line, actual baselines tend to be much more "generous". The baselie is 
> what the country self declares and other countries accept/recognize. 
> 
> Also the 12nmi extension (territorial waters) is not always the same, some 
> countries pretend(ed) 200 nautical miles.

Up to 200nm is the EEZ (Exclusive Economic Zone), that's not the same.
There's a neat explanation and diagram here: 

https://sites.tufts.edu/lawofthesea/chapter-two/___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-10 Thread Colin Smale
On 2018-09-10 10:30, Martin Koppenhoefer wrote:

>> On 10. Sep 2018, at 02:09, Joseph Eisenberg  
>> wrote:
>> 
>> The legal definition of the baseline is the low tide line and also cuts 
>> across bays, inlets and estuaries.
> 
> I thought the baseline was generally defined politically/legally. In Italy 
> for example there is a law which contains a long list of points (many with 
> coordinates).

Both are correct. 

The baseline is defined by the state, in accordance with the UNCLOS
rules, and published to the world by deposition with the UN. The basis
for the baseline is: "the normal baseline for measuring the breadth of
the territorial sea is the low-water line along the coast as marked on
large-scale charts officially recognized by the coastal State." 

http://www.un.org/depts/los/convention_agreements/texts/unclos/part2.htm___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] What is a terrace after all?

2018-09-10 Thread Colin Smale
For an individual dwelling, we have building=house. For the entire row
as a single building, building=terrace_of_houses might be better, or
otherwise building=housing_terrace. But not building=terraced_house as
that implies a single dwelling.

On 2018-09-10 09:21, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 10. Sep 2018, at 02:27, André Pirard  wrote:
>> 
>> In my mind, building=terrace is a bad tag. It should be:
>> building=house
>> house:terraced=yes
>> be it as a row of houses or a single one.
> 
> I agree that building=terrace is not a nice tag, I would prefer 
> building=terraced_house
> 
> cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-10 Thread Colin Smale
Graeme, 

You suggest that coastline and baseline might be the same thing.
Unfortunately I, and many other people would take a different view. The
coastline (especially as used in OSM) is a geographically defined line,
that no law or declaration can change. It is normally taken to be
connected to the high water line. The baseline is however defined
politically, normally as a heavily generalised derivative of the low
water line, with rules (see UNCLOS and the Convention you referenced)
about how bays, islands, archipelagos, river mouths etc. can be factored
in to the resulting list of coordinates which is published to the world.
This baseline is the 0-line for the calculation of the 6/12 mile limits
and 200 mile EEZ. Watery bits on the land side of the baseline are
"internal waters" and are subject to the jurisdiction of the land (under
control of the local government). On the sea side of the baseline
maritime law will prevail, usually under control of the national
government in conjunction with all kinds of treaties. 

If the USA has defined the word "coastline" to mean "baseline", what
term does it use for the coastline in a geographic sense?

I believe that coastline and baseline are two different concepts which
need to be treated separately. If they happen to be colinear in some
cases, that's OK. But I am thinking here of vertical harbour walls,
where in 2D the high water line and low water line lay on top of one
another., and not some human declaration. 

We will need to be a little pragmatic, because OSM mappers are never
going to be able to do a proper survey of the coastline with the same
degree of accuracy as professional surveyors. We are limited to
leveraging existing data sources for all kinds of boundaries, other than
occasional anecdotal points. Trying to come up with our own definition
of things like coastline is a complete non-starter. The position of the
"river crossing" in the coastline should similarly follow existing
definitions. If we want to make further distinctions in our data so for
example salty water can be distinguished from fresh water, or so tidal
influence on river flow speed and direction can be represented, I am
sure the OSM community can find some suitable tagging for that, but that
is a separate issue to the COASTLINE discussion. 

On 2018-09-10 01:30, Graeme Fitzpatrick wrote:

> On Mon, 10 Sep 2018 at 08:25, Colin Smale  wrote: 
> 
>> So are we getting any closer to consensus on where the coastline should 
>> cross the river? I think only if it is "somewhere between the tidal limit 
>> and the sea". Are all "crossing points" then equally valid? Or can we expect 
>> strong disagreements (especially at the limits) and possible edit wars?
> 
> Unfortunately, I don't think we are ever all going to agree - some people are 
> adamant about the tidal limit, while other's are equally convinced that it 
> should be where the river enters the sea, & both arguments are just as 
> logical as the other. 
> 
> I think part of the problem is the lack of a precise definition of just what 
> is the "coastline"? eg Merriam-Webster dictionary "a line that forms the 
> boundary between the land and the ocean or a lake" which could well mean that 
> the coastline goes up a river, but how far? 
> 
> While searching for a better answer, I did however find this: 
> http://www.myfloridalegal.com/ago.nsf/Opinions/E2D8E00068ACF5EE8525622F004AA168.
>  
> 
> Some of the highlights include:  
> 
> "Congress reacted to these decisions by enacting the Submerged Lands Act of 
> 1953.[10] Congress defined "coast line" to mean "the line of ordinary low 
> water along that portion of the coast which is in direct contact with the 
> open sea and the line marking the seaward limit of inland waters" 
> 
> "the Supreme Court set the meaning of "coast line" in its earlier decree.[32] 
> The Court defined the term to mean "the line of ordinary low water along that 
> portion of the coast which is in direct contact with the open sea and the 
> line marking the seaward limits of inland waters."" 
> 
> "During the late 1950s, the coastal countries of the world proposed, 
> discussed, and drafted a treaty known as the Convention on the Territorial 
> Sea and Contiguous Zone, April 29, 1958.[34] The hope was to provide 
> uniformity in the delineation of the nations' territorial sea. Rather than 
> using the term "coast line," the Convention used the term "baseline" in the 
> measurement of the territorial sea. Article 3 defines the "baseline" for 
> measuring the territorial sea as "the low water line along the coast as 
> marked on large-scale charts officially recognized by the coastal State.&q

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-09 Thread Colin Smale
On 2018-09-09 23:35, David Groom wrote:

> -- Original Message -- 
> From: "Joseph Eisenberg"  
> To: tagging@openstreetmap.org 
> Sent: 07/09/2018 04:02:26 
> Subject: Re: [Tagging] Coastline for rivers, estuaries and mangroves? 
> 
>> I've now edited the coastline in the area mentioned. I have now added 
>> natural=coastline along all the ways forming the edge of the mangroves and 
>> open water. 
>> https://www.openstreetmap.org/changeset/62340975#map=13/-4.9075/137.1762
> 
> I have to say that to me this seems wrong. Coastline tags are now on ways 
> forming channels 40m wide and 30km from open ocean.  I just don't see that 
> these are "coastlines" .

Those distances are not too dissimilar to the situation on the River
Dart, where this whole discussion started. 

So are we getting any closer to consensus on where the coastline should
cross the river? I think only if it is "somewhere between the tidal
limit and the sea". Are all "crossing points" then equally valid? Or can
we expect strong disagreements (especially at the limits) and possible
edit wars?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-03 Thread Colin Smale
Graeme, 

Baseline is not the same as coastline, so the definition you refer to is
not what we are looking for. 

Coastline is a geographic feature, and is normally based on high water. 

Baseline is a political feature, based on the low water mark, and
simplified around bays, inlets and islands. This is the baseline from
which the 12nm territorial limit is measured, and also the 200nm EEZ and
median lines if applicable. Water on the landward side of the baseline
(e.g. lakes, inlets, estuaries) is referred to as internal waters, i.e.
belonging to the land mass itself for the purposes of maritime law.

On 2018-09-03 23:58, Graeme Fitzpatrick wrote:

> This has recently been discussed on the Australian list, with reference being 
> made to 
> http://www.ga.gov.au/scientific-topics/marine/jurisdiction/maritime-boundary-definitions,
>  which is based on the UN Convention on the Law of the Sea 
> http://www.un.org/Depts/los/convention_agreements/convention_overview_convention.htm.
>  
> 
> For our discussion now: 
> 
> "TERRITORIAL SEA BASELINE
> 
> The term Territorial Sea Baseline (TSB) refers to the line from which the 
> seaward limits of Australia's Maritime Zones are measured. These include the 
> breadth of the territorial sea; the seaward limits of the contiguous zone, 
> the exclusive economic zone and, in some cases, the continental shelf. 
> 
> The territorial sea baseline may be of various types depending upon the shape 
> of the coastline in any given locality: 
> 
> * The Normal baseline corresponds with the low water line along the coast, 
> including the coasts of islands. Under the Convention, normal baseline can be 
> drawn around low tide elevations which are defined as naturally formed areas 
> of land surrounded by and above water at low tide but submerged at high tide, 
> provided they are wholly or partly within 12 nautical miles of the coast. For 
> Australian purposes, normal baseline corresponds to the level of Lowest 
> Astronomical Tide (LAT) [1].
> * Straight baselines are a system of straight lines joining specified or 
> discrete points on the low-water line, usually known as straight baseline end 
> points. These may be used in localities where the coastline is deeply 
> indented and cut into, or where there is a fringe of islands along the coast 
> in its immediate vicinity.
> * Bay or river closing lines are straight lines drawn between the respective 
> low-water marks of the natural entrance points of bays or rivers.
> 
> Waters on the landward side of the baseline are internal waters for the 
> purposes of international law." 
> 
> & NB that they say that the Normal baseline is the low water line! 
> 
> The UN's definitions: 
> 
> Straight baselines 
> 
> 1. In localities where the coastline is deeply indented and cut into, or if 
> there is a fringe of islands along the coast in its immediate vicinity, the 
> method of straight baselines joining appropriate points may be employed in 
> drawing the baseline from which the breadth of the territorial sea is 
> measured. 
> 
> 2. Where because of the presence of a delta and other natural conditions the 
> coastline is highly unstable, the appropriate points may be selected along 
> the furthest seaward extent of the low-water line and, notwithstanding 
> subsequent regression of the low-water line, the straight baselines shall 
> remain effective until changed by the coastal State in accordance with this 
> Convention. 
> 
> 3. The drawing of straight baselines must not depart to any appreciable 
> extent from the general direction of the coast, and the sea areas lying 
> within the lines must be sufficiently closely linked to the land domain to be 
> subject to the regime of internal waters. 
> 
> 4. Straight baselines shall not be drawn to and from low-tide elevations, 
> unless lighthouses or similar installations which are permanently above sea 
> level have been built on them or except in instances where the drawing of 
> baselines to and from such elevations has received general international 
> recognition. 
> 
> 5. Where the method of straight baselines is applicable under paragraph 1, 
> account may be taken, in determining particular baselines, of economic 
> interests peculiar to the region concerned, the reality and the importance of 
> which are clearly evidenced by long usage. 
> 
> 6. The system of straight baselines may not be applied by a State in such a 
> manner as to cut off the territorial sea of another State from the high seas 
> or an exclusive economic zone. 
> 
> Article9 
> 
> Mouths of rivers 
> 
> If a river flows directly into the sea, the baseline shall be a straight line 
> across the mouth of the river between points on the low-water line of its 
> banks.
> 
> So, unless any of us want to argue with the UN, or suggest that they change 
> their definitions to suit OSM! :-), I think that they could be counted as the 
> final word? 
> 
> Thanks 
> 
> Graeme 
> 

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-03 Thread Colin Smale
On 2018-09-03 23:08, Christoph Hormann wrote:

> On Monday 03 September 2018, Colin Smale wrote: This is essentially the 
> situation we have right now.  Judgement of
> local mappers is usually fine (with the exception of political
> cases like the Rio de la Plata).  Most problems occur because
> armchair mappers misinterpret the local situation or when
> inexperienced mappers are unaware of the significance of
> distinguishing between ocean and riverbank mapping. 
> What guidance do we give to the local mappers?

What is currently written on the wiki which includes the proposal which 
is linked to from the coastline documentation.

> Given a properly formulated rule-of-thumb, why should remote armchair
> mappers come to a different conclusion to local mappers in this case?

As said this is mostly due to misinterpreting imagery. 

That can account for a few metres either way (perpendicular to the
shoreline), but not for the difference between tidal limit and a
"convenient crossing point near the sea". That is purely a personal
judgement, not misaligning imagery. After all, we are not disputing here
the location of the sides of the river, but where we draw the line from
one side of the river to the other.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-03 Thread Colin Smale
On 2018-09-03 22:20, Christoph Hormann wrote:

>> The estuarine situation will always be hard to deal with, and I think
>> we'll simply need to have rough guidelines and then trust the
>> judgment of the locals.
> 
> This is essentially the situation we have right now.  Judgement of local 
> mappers is usually fine (with the exception of political cases like the 
> Rio de la Plata).  Most problems occur because armchair mappers 
> misinterpret the local situation or when inexperienced mappers are 
> unaware of the significance of distinguishing between ocean and 
> riverbank mapping.

What guidance do we give to the local mappers? Coastline up to tidal
limit, or draw a line across wherever you think fit? Coastline and
riverbank are IMHO not mutually exclusive. 

Given a properly formulated rule-of-thumb, why should remote armchair
mappers come to a different conclusion to local mappers in this case? Or
are you proposing such a wide tolerance that basically anything will
fit, thus avoiding the discussion instead of actually tackling it?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Coastline for rivers, estuaries and mangroves?

2018-09-03 Thread Colin Smale
Just a reminder that we need a pragmatic, practical definition for OSM.
It has to be either verifiable in situ, preferably in a single visit and
without specialist equipment, knowledge or access, or it needs to be
derivable from openly accessible (and suitably licensed) sources. A
discussion whereby a hundred people contribute their subjective opinions
is unlikely to lead to a *durable* solution for OSM. In this case I
would suggest it would be impossible for a mapper to survey their own
coastline position; it is best left to hydrographers and/or
cartographers to provide the algorithm by which one can define the
correct "coastline". Then we find an open source of this data for our
regions. If this source does not exist, we approximate (based on the
chosen algorithm) until such time as open data is available. 

The nicest thing about standards is of course the wide choice
available Which standard do we adopt? Is it not possible that there
are multiple possibilities for the definition of "coastline", and which
one is best for a given use case, can vary according to the wishes of
the party consuming the data? I.e. if we preselect a specific
definition, are we implicitly and unintentionally blocking out other
definitions from representation in OSM, possibly leading to accusations
of "tagging for the renderer," being the single use case which uses the
chosen definition? 

One thing I think does have consensus - the coastline is based on the
High Water Mark (and not Low Water or mid-tide or any other point in the
tidal cycle). This in itself is impossible for a "simple mapper" to
define with any accuracy, so we will have to trust external sources. 

What is unclear, is of course where do we "draw the line", literally and
figuratively, in the case of indented coastlines and river estuaries.
Tidal limit has the advantage of being artificial (dam/weir etc) and
therefore uncontroversial, or at least in most cases readily available,
even if it is just from "common knowledge". So which standard/algorithm
would give the pragmatic, practical definition OSM needs?

On 2018-09-03 21:32, Kevin Kenny wrote:

> It would certainly need to be above Haverstraw - the current there
> http://tbone.biol.sc.edu/tide/tideshow.cgi?site=Haverstraw+%28Hudson+River%29%2C+New+York+Current
> shows significant tidal reversal.  I haven't found a gaging station
> farther upriver that reports tidal currents. Croton Point, where the
> river broadens to form the Tappan Zee, would probably be the lower
> limit. Even that seems unreasonably far upriver.
> 
> The tidal range increases as you move upstream from there. The
> greatest tidal range in the entire river is at Troy. One Native
> American name for the river was "Mahicantuck" which means, more or
> less, "the river flows both ways."
> 
> The estuarine situation will always be hard to deal with, and I think
> we'll simply need to have rough guidelines and then trust the judgment
> of the locals.
> On Mon, Sep 3, 2018 at 2:51 PM Christoph Hormann  wrote: 
> On Monday 03 September 2018, Kevin Kenny wrote: Imagico's proposal is perhaps 
> objective, but surely doesn't match
> perception in my part of the world. It seems odd that the 'coastline'
> must extend upward to https://www.openstreetmap.org/way/90929525 -
> but that is, according to Imagico's definitions, simultaneously the
> lowest and highest permissible limit. [...] 
> Then you have misunderstood the proposal.
> 
> With the Hudson river obviously the tidal case applies so you have the
> lower limit as:
> 
> With significant tides the coastline should go upstream at least to a
> point where on waterflow is going downstream for a significantly longer
> part of the tidal cycle than it goes upstream due to raising tide.
> 
> This is evidently always below the upper limit (range of tidal
> influence).
> 
> I can't say for sure where i would place the lower limit in case of the
> Hudson - The Narrows is quite definitely too low - but the current
> closure seems fine.
> 
> For low volume tidal rivers (i.e. without a salt wedge and no
> significant influence of the water volume on the ocean salinity) it
> would also be possible to define the lower limit through salinity (not
> in absolute terms but as a fraction of the open ocean salinity in the
> area).
> 
> --
> 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


Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

2018-08-09 Thread Colin Smale
On 2018-08-09 08:45, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 9. Aug 2018, at 07:17, Marc Gemis  wrote:
>> 
>> The name field is just a label. If you want to know the exact name in
>> a certain language you look at the name:xx field.
> 
> the question is about the "name in the local language".

Is it not about the "name as signed in situ"? (Cf. "on-the-ground trumps
everything else" rule) 

In the case of Brussels, are all signs "fr - nl" or are some "nl - fr" ?


Also many bilingual street signs in Belgium exploit grammatical
differences between French and Dutch; where the significant part is a
proper name (X), in French it might be "Rue X", in Dutch it is
"Xstraat", so the sign says Rue X-straat. 

Random example: 
https://www.google.com/maps/@50.826443,4.2963849,3a,15y,217.26h,94.11t/data=!3m6!1e1!3m4!1sY2SqOf8gphVOZYqsHOKlXA!2e0!7i13312!8i6656


So it looks like the text on the signs cannot be recreated from name:fr
and name:nl alone.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] place nodes for continents?

2018-08-07 Thread Colin Smale
On 2018-08-07 15:43, marc marc wrote:

> I think there's too much redundancy in using is_in:continent.
> it is useless, for example, to say that a street + the municipality
> + the region + the country is all in the same continent.
> it is enough to tag the largest polygon with is_in:continent and erase 
> those that provide the same information redundantly on objects included 
> in that polygon.
> this would limit the number of is_in:continent to one per country or a 
> few per country for countries with very scattered territories (e.g. 
> overseas territories for France)

There are several countries that span multiple continents... Russia,
Turkey, Spain and indeed France for example. 

This possibly demonstrates at least two sorts of continent: "political"
and "geographic." Other continent types are available.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] place nodes for continents?

2018-08-07 Thread Colin Smale
This would (only) be possible if there was a (at least one)
deterministic way of establishing the location of the boundary. Would
you base it on the admin boundaries, coastlines and established
baselines? The IHO definitions? 

Indeed, why not have a polygon for the Med? 

On 2018-08-07 13:17, djakk djakk wrote:

> Why not a big polygon for each continent, subcontinent, ocean, sea ... ? 
> 
> djakk 
> 
> Le mar. 7 août 2018 à 12:28, Colin Smale  a écrit : 
> 
> As even continents now appear to be subjective, all uses of them should be 
> associated with the chosen frame of reference, much like one always 
> associates a currency with an amount. A given lump of rock can be in multiple 
> continents, each with its own authority, all correct in their own ways. 
> 
> On 2018-08-07 11:48, Javier Sánchez Portero wrote: 
> 
> El mar., 7 ago. 2018 a las 10:33, Warin (<61sundow...@gmail.com>) escribió: 
> But "Officially, there is no centre of Australia." So say the experts. 
> Probably because they cannot reach consensus, sounds familiar :) 
> 
> We are extending on the "centre" problem, but there aren't even a consensus 
> in the number of continents. 
> 
> https://commons.wikimedia.org/wiki/File:Systemes_de_continents.gif 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] place nodes for continents?

2018-08-07 Thread Colin Smale
As even continents now appear to be subjective, all uses of them should
be associated with the chosen frame of reference, much like one always
associates a currency with an amount. A given lump of rock can be in
multiple continents, each with its own authority, all correct in their
own ways.

On 2018-08-07 11:48, Javier Sánchez Portero wrote:

> El mar., 7 ago. 2018 a las 10:33, Warin (<61sundow...@gmail.com>) escribió: 
> 
>> But "Officially, there is no centre of Australia." So say the experts. 
>> Probably because they cannot reach consensus, sounds familiar :)
> 
> We are extending on the "centre" problem, but there aren't even a consensus 
> in the number of continents. 
> 
> https://commons.wikimedia.org/wiki/File:Systemes_de_continents.gif 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] building = house vs detached.

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

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

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


Re: [Tagging] building = house vs detached.

2018-07-23 Thread Colin Smale
Martin, you might not agree with some of the past architectural choices
in the UK, but the point is that a "single-floor dwelling" (i.e. ground
floor only) is a called a bungalow, and this can exist in many forms. It
can be detached, terraced, end-of-terrace or semi-detached. The last two
can be only subtly different - if there is a terraced house in the
middle, you would call it end-of-terrace and not semi-detached; if there
are only two dwellings joined together, they are semi-detached. All as
per (British) English usage of course. An end-of-terrace house may also
have an identical layout to the terraced house next door - it might not
have any extra windows or land at the side. 

There are also houses which are joined only at the first floor level (or
possibly some other combination of levels), which I learnt to call
link-detached. 

The point is that whether a dwelling is a bungalow or not, is orthogonal
to whether it is {detached, semi-detached, terraced, end-of-terrace}. It
is perfectly possible for a semi-detached bungalow to be attached to a
semi-detached non-bungalow. 

So "bungalow" as an attribute is actually just an alias for something
like "floors=1" where the floor is the ground floor. 

The RICS (Royal Institute of Chartered Surveyors) ought to know:

http://www.rics.org/uk/knowledge/glossary/residential-property-types-definitions/


Let's stop conflating concepts and worrying about what things are
"called", and describe indisputable characteristics of objects, in this
case how many floors and how/whether the dwelling is connected to its
neighbours. The use of house=terrace may be justified for a transitional
situation where a whole terrace has been mapped as a single building and
not yet split into individual units. When it is split, it is just a
house - the geometry (shared nodes) will show that it connects to the
adjacent properties and allow you to derive that it is terraced. 

To help you visualise what terraced bungalows look like, here's an
example: 

https://commons.wikimedia.org/wiki/File:Kinsaley_Lane_Terraced_Bungalows_-_geograph.org.uk_-_530719.jpg


Let's ban house=bungalow. It's a house because it is intended for people
to live in it. 

By the way, the Dutch national register of buildings allows for a
complex mapping of dwelling units to physical buildings. A dwelling,
which has an address, may be composed of multiple building units (e.g. a
granny flat or outbuilding can be part of the same dwelling). A building
may be composed of multiple building units (e.g. apartments). Not all
buildings are part of a dwelling unit, and not all man-made
constructions are buildings. How do we link parts of a dwelling together
in OSM? I guess a relation with type=house containing the parts as
building=house? 

On 2018-07-23 15:00, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 23. Jul 2018, at 14:13, Colin Smale  wrote:
>> 
>> The owner would say he lived in a bungalow. No stairs, ground floor only.
> 
>> I don't think "terraced bungalow" exists as a phrase, but as a concept it 
>> certainly does.
> 
> it does not seem to be a very promising concept though. Terraced houses are 
> usually seen as a compromise for people who want an independent house, but 
> cannot afford a detached one. Terraced houses are cheaper because they need 
> less ground (i.e. you can usually find them where the ground is expensive to 
> buy), expensive ground means you'll try to use it intensively, which is 
> contradicting the bungalow concept.
> Terraced houses are almost always narrow, deep and relatively high.
> 
> Maybe in the UK with its tradition of terraced houses there could be a 
> cultural interest in something like terraced bungalows and there is also an 
> energetic advantage from reducing external walls, but overall there's little 
> danger this will become a widespread concept for housing. 
> 
> Cheers,
> Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] building = house vs detached.

2018-07-23 Thread Colin Smale
The owner would say he lived in a bungalow. No stairs, ground floor only. I 
don't think "terraced bungalow" exists as a phrase, but as a concept it 
certainly does. 


On 23 July 2018 10:44:30 CEST, Martin Koppenhoefer  
wrote:
>2018-07-23 6:17 GMT+02:00 Colin Smale :
>
>>
>> In British English a bungalow is a single storey dwelling, I. E. It
>refers
>> to the vertical axis. Nothing is implied about its juxtaposition.
>There are
>> also terraced bungalows.
>
>
>
>are "terraced bungalows" really part of the natural language, or is
>this
>maybe an advertising euphemism created by the real estate industry?
>
>Cheers,
>Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] building = house vs detached.

2018-07-22 Thread Colin Smale


On 23 July 2018 04:09:03 EEST, Jmapb  wrote:
>On 7/22/2018 7:57 PM, Paul Allen wrote:
>> You've (perhaps inadvertently)  
>
>> Oh, and then there are bungalows and cottages, which count as houses 
>> in OSM, so are tagged as
>> building=detached.
>
>Nb, the wiki does offer building=bungalow, and there are nearly 50k of 
>them out there. I'd consider bungalow a special subset of detached 
>(which is a special subset of house, etc.)
>
What about semi detached bungalows?

In British English a bungalow is a single storey dwelling, I. E. It refers to 
the vertical axis. Nothing is implied about its juxtaposition. There are also 
terraced bungalows.


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


Re: [Tagging] nautical channels

2018-07-01 Thread Colin Smale
It sounds like you might be looking for "fairway"?

https://forum.wordreference.com/threads/fairway-channel-same-difference.1910166/


http://www.yourdictionary.com/fairway 

//Colin 

On 2018-07-01 11:39, Volker Schmidt wrote:

> No, the question was about the canali in the open lagoon, which are marked
> 
> On 1 July 2018 at 09:08, Martin Koppenhoefer  wrote:
> 
>> the question here was about the Canali in Venice, usually no buoys there, 
>> but man_made banks.
> 
> No, my question was not about the canali in Venice, which are essentially 
> waterways between islands that are inhabited. 
> I realise I was not clear enough with my definition: my question was about 
> navigation channels in the open lagoon which are often, but not always marked 
> by wooden delimiters ("briccola" in Italian, "dolphin" in English) as visible 
> in this photo: [1]. That's where thay are in the lagoon [2] 
> (side remark: many of these are tagged as"seamark:mooring:category=dolphin" 
> in OSM, even though they are not for mooring) 
> 
> [1] https://www.mapillary.com/map/im/fj42p-LsTwFFlrU1MLIryg 
> [2] http://overpass-turbo.eu/s/zYh 
> ___
> 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] Street exits

2018-06-15 Thread Colin Smale
On 2018-06-15 08:28, Peter Elderson wrote:

> Speed is limited to 15 Kmph (living_street rules).

Peter, have you got a source for this 15kph maxspeed (wegenverkeerswet)
for an uitrit that is not a living street? It may be sensible, given the
priority rules and the physical construction, but I don't believe there
is any legal basis for a maxspeed as such, is there?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Street exits

2018-06-15 Thread Colin Smale
On 2018-06-15 09:54, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 15. Jun 2018, at 08:28, Peter Elderson  wrote:
>> 
>> The street is residential, but the exit is over a sidewalk, with a dropped 
>> curb. That's the piece I'm talking about: not the street, just the exit.
>> 
>> Rules (legally) implied are that traffic can pass over this sidewalk, but 
>> has to give way to all sides and all others including pedestrians. Speed is 
>> limited to 15 Kmph (living_street rules).
> 
> as I said, this is the kind of junction of german living streets, including 
> rules and appearance.

But (in NL at least) not all such junctions are with a living street. 

The essence is that entering or leaving a side road over one of these
constructions counts as a "special manoeuvre", just like reversing and
turning in the street. You have to give way to just about everything. 

When you compare a junction with this "exit construction" (Dutch:
uitritconstructie) with a similar junction without it from a drivers
perspective, the "main road" is automatically a "priority road" at that
junction, without the need for a yellow diamond. Otherwise the through
road would have to yield priority to traffic from the right. Pedestrians
crossing the side road following the main road have priority in both
cases. 

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-13 Thread Colin Smale
Why not map objective attributes, such as trees per hectare, species,
maybe natural vs managed? If the set of attributes is chosen well, then
people will be able to apply their own criteria as to what is an
"orchard" or a "forest" when consuming the data. After all, OSM is the
data, not the rendered map. 

We (a small number of people anyway, on behalf of the whole of OSM, most
of whom are unaware that this discussion is even taking place) are once
again spending a lot of energy trying to get global consensus on the
names people use to call these things, in a language which is not native
to the majority of participants. That seems pretty unachievable to me,
without a solid frame of reference. When the discussion dies down, it
won't be because there is real consensus, just that people have got
bored of the discussion and gone off to do more productive things with
their lives. Until the same subject flares up again at some point in the
future, then it all starts again.

On 2018-06-13 11:24, Martin Koppenhoefer wrote:

> btw., we have only been discussing the term forest for landcover=trees, but 
> there are other places where trees grow, e.g. orchards, groves, copses, 
> bosks, thickets. We do have orchard as a tag, but we do not have anything 
> specific for copses and groves (some might be mapped as orchards?). Thickets 
> are generally mapped as natural=scrub? Bosk is a synonymon for grove? 
> 
> What about the distinction "forest" and "wood"? Is a wood smaller and a 
> forest denser? 
> 
> Cheers, 
> Martin 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] A system structured approach rather than piecemeal

2018-06-09 Thread Colin Smale
On 2018-06-10 01:30, Warin wrote:

> One of the problem is that these main tags don't come through the tagging 
> group .. they arrive through common use that sees a demand and satisfies it.
> 
> A problem with that is that the initial users see only their local issues and 
> don't see it on a global scale ..
> so it gets used in ways that were not part of the initial use/intent.
> Tight definitions are hard to do when you only see what you are wanting to 
> map, not seeing the wider picture.
> 
> Thus we have a mess to fix up.

Absolutely agree. Inherent in this is the fact that sometimes we go down
a path with tagging which, with hindsight, proves to be "wrong," for
example 
because it is insufficiently flexible or based on a misunderstanding of
a term (given that many mappers use English as a second language). When
such a 
situation arises we must be bold enough to acknowledge that the original
tagging should be replaced with new tagging. This is not an unexpected, 
unwanted situation - it should be a mainstream activity to apply more
recent thinking to outdated tagging. It should not cost so much energy
to make 
the case for this. Compare it with allowing for refactoring and
reworking in an Agile project - it is not a bad thing, it is a fact of
life. Fail fast 
and often - that leads to progress in the end. 

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-09 Thread Colin Smale
On 2018-06-09 13:00, Warin wrote:

> On 09/06/18 19:20, Colin Smale wrote: 
> 
> On 2018-06-09 10:51, Christoph Hormann wrote: 
> On Saturday 09 June 2018, Colin Smale wrote: This analogy also means that 
> competition is essential for progress
> in OSM.

How do we define "progress"? How do we conclude if OSM today is
"better" than in the past? Are our processes becoming more mature? Is
our data quality improving? Do we have more "customers" than before?
What defined "goals" have we achieved? 
I have not defined progress and don't need to for the argument i made.  
It applies for any definition of progress you might have.  Or in other 
words: Here it just means the opposite of stagnation. 
Stagnation is exactly where we are heading, isn't it? 
With the passion shown on some subjects, I'd say OSM is very far from
'stagnation'. :) 

To me a stagnant pool is one with no life in it, no movement. 
The OSM pool has ripples and waves of different opinions some of them
clash and make turbulence. There is life in the OSM pool. 

I suppose stagnation is not quite the right word. Ripples are evidence
of energy, not progress being made. A boat straining against its anchor
can make a splash, but the only effect is warming the sea up a little. I
interpreted stagnation as not going anywhere.

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-09 Thread Colin Smale
On 2018-06-09 10:51, Christoph Hormann wrote:

> On Saturday 09 June 2018, Colin Smale wrote: This analogy also means that 
> competition is essential for progress
> in OSM.

How do we define "progress"? How do we conclude if OSM today is
"better" than in the past? Are our processes becoming more mature? Is
our data quality improving? Do we have more "customers" than before?
What defined "goals" have we achieved? 
I have not defined progress and don't need to for the argument i made.  
It applies for any definition of progress you might have.  Or in other 
words: Here it just means the opposite of stagnation. 

Stagnation is exactly where we are heading, isn't it? 

Phrases like "best map in/of the world" are fine in corporate mission
statements but it's hardly SMART[1]. 

Colin 

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-09 Thread Colin Smale
On 2018-06-09 10:00, Christoph Hormann wrote:

>> This analogy also means that competition is essential for progress in 
>> OSM.

How do we define "progress"? How do we conclude if OSM today is "better"
than in the past? Are our processes becoming more mature? Is our data
quality improving? Do we have more "customers" than before? What defined
"goals" have we achieved? 

I don't mean to be cynical, but I am truly unable to work out what our
defined aims are, so that we may measure progress against them.
Continued existence doesn't count by the way. 

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


Re: [Tagging] Conflicting wiki docu for aerialway=goods and aerialway=station

2018-05-15 Thread Colin Smale
Frisian is not a dialect of Dutch. It is an ancestor of both English and Dutch. 

On 15 May 2018 00:36:02 CEST, Paul Allen  wrote:
>On Mon, May 14, 2018 at 11:21 PM, Andrew Davidson 
>wrote:
>
>> I think that was Martin's point. OSM tags and values aren't in Dutch
>>
>
>I took the Dutch to be an example that at least one other language
>makes a
>similar
>distinction to English in that stations are for people, not goods. 
>Then
>again, Dutch
>(well, the Frisian dialect) had some influence on English, so it's
>maybe
>not a
>distinction found in many languages.
>
> --
>Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Removing helpful information in wiki pages

2018-05-12 Thread Colin Smale
Sorry, I must have misinterpreted the emails somewhere. 

On 2018-05-12 16:41, Frederik Ramm wrote:

> Hi,
> 
> On 12.05.2018 13:53, Colin Smale wrote: 
> 
>> As Thilo had pointed out, removing off-topic info from the Wiki is not a
>> documented activity of the DWG so I assume everyone was acting in a
>> purely personal capacity?
> 
> Nobody from DWG was involved until Thilo asked DWG to get involved, and
> after that the involvement of DWG was limited to exchanging messages
> with Thilo.
> 
> Bye
> Frederik___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Removing helpful information in wiki pages

2018-05-12 Thread Colin Smale
As Thilo had pointed out, removing off-topic info from the Wiki is not a
documented activity of the DWG so I assume everyone was acting in a
purely personal capacity?

On 2018-05-12 13:15, Martin Koppenhoefer wrote:

> 2018-05-11 18:22 GMT+02:00 Thilo Haug :
> 
>> Hi all, 
>> 
>> would you say this picture is "off topic" ?
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:aeroway%3Dspaceport=1519060#Pictures
>>  [1]
> 
> Yes, this is clearly off topic for the tag definition page. Why would you 
> think it is not, and what is the content you believe is contained that could 
> help understanding the tags in question?
> 
> Cheers, 
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1]
https://wiki.openstreetmap.org/w/index.php?title=Tag:aeroway%3Dspaceportoldid=1519060#Pictures___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] brand=* necessary?

2018-05-10 Thread Colin Smale
On 2018-05-10 13:17, Christoph Hormann wrote:

> On Thursday 10 May 2018, Colin Smale wrote: I should probably add that what 
> can be considered the name of a
> feature is ultimately the decision of the local community. 
> ...as long as there are global ground rules. The autonomy of local
> communities, just like democracy, cannot be unbounded. OSM is a
> global resource. What's a local community, anyway? We don't want
> people in one city doing things differently from another city 10km
> away in the same country, do we?

The definition of a name is pretty universal (as the verbal identifier a

certain specific object is referred to with).  There is not much local 
variation in that. 
Referred to, by whom? Who is the persona here? What's the use case? 

> A "name" is what something is "called" by "others." Which "others"
> are considered, is the real debate here. Is it the council? Is it the
> residents within 100m? Is it a tourist who doesn't speak the local
> language? Who gets priority? This is something that cartographers
> (AKA humans determining the rendering) must decide, depending on who
> the map is for.
> You are mixing the geographic concept of a name with the cartographic 
> concept of a label here - which is of course something a lot of mappers 
> do when they choose name tags.

Interesting - my intention was the exact opposite. The point I was
trying to make (and I think we agree on this) is that a simple "name" is
subjective. Different renderers will make different decisions about what
data to add to the resulting map, according to what they want to
portray. 

A physical sign is analogous to a label - it is a depiction of an
attribute in a certain context. The "facts" are simply that there is a
sign with certain characters on it, in a style that leads us to derive
that this is the name of an object to which it is attached or adjacent.
That is subtly different to the "facts" about the name of the object,
which can be subjective. It depends on who you ask, and in what context.
Multiple different answers may be equally correct, in different
contexts.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] brand=* necessary?

2018-05-10 Thread Colin Smale
On 2018-05-10 12:01, Christoph Hormann wrote:

> I should probably add that what can be considered the name of a feature 
> is ultimately the decision of the local community.

...as long as there are global ground rules. The autonomy of local
communities, just like democracy, cannot be unbounded. OSM is a global
resource. What's a local community, anyway? We don't want people in one
city doing things differently from another city 10km away in the same
country, do we? 

A "name" is what something is "called" by "others." Which "others" are
considered, is the real debate here. Is it the council? Is it the
residents within 100m? Is it a tourist who doesn't speak the local
language? Who gets priority? This is something that cartographers (AKA
humans determining the rendering) must decide, depending on who the map
is for. 

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


Re: [Tagging] Unifying large multi-location store chains

2018-05-03 Thread Colin Smale
There was an action a couple of years ago in the Netherlands to unify
the orthography of shop names. It was very successful, after a
consultation.

Here's the link to the discussion on the forum - unfortunately it's all
in Dutch... https://forum.openstreetmap.org/viewtopic.php?id=33909 

The originator of the project was Matthijs Melissen, who make wiki pages
for the mechanical edit process that ensued:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Math1985_mechanical


Colin 

On 2018-05-03 18:34, Leon Karcher wrote:

> Hello, 
> 
> I thought about unifying large store/restaurant chains with several locations 
> for many times now. There are some tags that are applicable to all locations 
> of a specific brand like brand=*, amenity=*/shop=*, cuisine=* for restaurants 
> and for some also name=*. Espacially name=* and brand=* are important to find 
> and filter POI. 
> 
> To have an overview I created a list in the wiki [1] which includes 
> applicable tags of some brands, but it's still under construction and only 
> shows the ones that I know. So feel free to help. 
> 
> I already did a small unification for "Applebee's" locations in Ohio (see 
> this changeset [2]). To do so I filtered out name=Applebee's and 
> name=Applebees via Overpass and reviewed the changes manually. Even though I 
> did the changes manually, this is sort of a mechanical edit, which is the 
> reason for me to ask on this mailing list on your opinion about such changes. 
> And also: What do you think of having such a list of brands? 
> 
> Hope to hear some opinions, 
> Leon/doktorpixel14 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] https://wiki.openstreetmap.org/wiki/User:Doktorpixel14/Brands
[2] https://www.openstreetmap.org/changeset/58652839___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Route members: ordered or not

2018-05-03 Thread Colin Smale
Why does a loop make it impossible to sort the ways? It implies that a
section of the route is present twice in the relation, but there is
surely no distinction between the first traversal of a way and the
second traversal?

On 2018-05-03 18:42, Volker Schmidt wrote:

> I will try to explain this in a more systematic way:
> 
> Routes belong to either of two categories: (A) Those whose members can be 
> sorted into a single ordered sequence (B) Those that cannot be sorted into a 
> single ordered sequence of members Sorting makes only sense for category (A) 
> Routes of type (B) can be subdivided into routes of type (A), each of which 
> can be sorted, but the overall route can not be sorted.
> 
> Routes are of type (A) if 
> (1) the path from begin to end is identical to the reverse path with  all 
> members traversed in the reverse order and in the opposite direction 
> or 
> (2) all members have the role forward 
> or 
> (3) all members have the role backward
> 
> Any route 
> (1) that has more than two ends 
> or 
> (2) that contains any loop (except the case that the entire route is a single 
> loop) 
> or 
> (3) that contains any element with role forword or role backward (except the 
> cases of all-forward or all-backward) 
> or
> (4) that contains node or area elements 
> is of type B
> 
> I am not sure if I have taken care of all cases - please complete as 
> necessary 
> 
> ___
> 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] Route members: ordered or not

2018-05-03 Thread Colin Smale
Good idea to re-order the ways within a route relation, but please,
don't reverse the ways to make them join up nicely head-to-tail! The
direction of ways is used for so many things that this could cause
untold collateral damage.

This might be obvious to many mappers, but it is definitely something
that well-meaning inexperienced mappers need to understand. 

Colin 

On 2018-05-03 17:26, Yves wrote:

> Un-ordered route members make it very hard to detect a broken route.
> Best practice :
> 1. If you edit a route, order it at best and check if you haven't broken it.
> 2. If you find an unordered route, order it, check if broken and try to 
> repair it.
> 
> Use for instance http://ra.osmsurround.org/.
> Yves 
> 
> Le 3 mai 2018 17:05:32 GMT+02:00, Michael Andersen  a écrit : 
> 
> I regularly edit a number of cycle routes (primarily the danish national 
> cycleroutes) and do my best to sort/order the members (it's helpfull when 
> looking for gaps and other peculiarities in JOSM), but have found that it's 
> often near impossible to make them perfectly sorted.
> 
> Consider for example https://www.openstreetmap.org/relation/20828. Where's 
> the 
> end points here? 
> 
> Also note that inexperienced mappers doing minor edits somewhere along a 
> route 
> cannot be expected to reorder it. 
> 
> On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:
> While I've mapped a number of trails most of them are not part of a
> designated larger route so I am not 100% sure, but I think hiking routes
> are much like highway routes: The ways in the relation should be ordered.
> 
> Not sure why you'd need a node in there, especially without an explicit
> role. If the route ways are ordered it is obvious where the end points are.
> 
> Cheers!
> 
> On May 3, 2018, at 5:06 AM, David Marchal  wrote:
> 
> Hello, there.
> 
> I recently worked a bit on hiking routes, and noticed that some routes
> have unordered members. That's particularly noticeable on
> waymarkedtrails.org , as it makes the
> elevation graph rubbish and useless. I read the relation:route wiki page,
> but there is only advice regarding stops order, and not way members
> order. Shouldn't there be a note on this page regarding the importance of
> sorting the ways to have a more useful relation than only spaghettis?
> 
> By the way, I saw some hiking relations having a node without explicit
> role, seemingly as a start point; is it a generally accepted, used
> feature, or only an idiosyncrasy?
> 
> Awaiting your answers,
> 
> Regards.
> 
> -
> 
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 

-

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

Yves
___
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] Manor tagging

2018-03-20 Thread Colin Smale
What about modern palaces, or buildings still in use as a palace? 

A manor is an area of land, not a building. xxx=manor_house would be
more appropriate. 

I agree that neither are hyponym / hypernym of castle - that is
something completely different like "fortified against attack". A former
castle may be in use as a palace. A manor house may be built in the
style of a castle.

On 2018-03-20 18:34, Tomasz Wójcik wrote:

> For me, it's obvious that we should choose:
> 
> * historic=palace for palaces
> * historic=manor for manors
> 
> Castles and palaces/ manors are different types of objects and it shouldn't 
> be mixed as some subtypes of castle. Of coure there are examples "on the 
> edge" but taking them as subtypes of castle it's not a solution.
> 
> ___
> 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] Shop=tailor vs craft=tailor

2018-03-18 Thread Colin Smale
On 2018-03-18 10:36, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 18. Mar 2018, at 10:09, Colin Smale <colin.sm...@xs4all.nl> wrote:
>> 
>> Craft and shop are orthogonal. Shop is a location, craft is an activity.
> 
> shop is a business offering some service or goods, craft is about a 
> professional offering services (or goods they produced). Both are about 
> location if we map them.

Craft is not a location - you cannot be IN a craft. You CAN be in a
workshop, studio, atelier etc where are craft is practiced. So if we tag
a building "craft=tailoring" then that says "tailoring occurs in this
building" or possibly "tailoring can be contracted in this building" if
the actual cutting and sewing happens elsewhere.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Shop=tailor vs craft=tailor

2018-03-18 Thread Colin Smale
Craft and shop are orthogonal. Shop is a location, craft is an activity. 

On 18 March 2018 05:57:02 CET, osm.tagg...@thorsten.engler.id.au wrote:
>“tailor” sounds very much like a craft to me.
>
> 
>
>On the other hand, it’s hard to argue with 1 tagged objects.
>
> 
>
>From the title of the issue, I assume that craft wasn’t being rendered
>before? Which might very well explain why everyone used shop to tag it…
>
> 
>
>From: James  
>Sent: Sunday, 18 March 2018 12:19
>To: Tag discussion, strategy and related tools
>
>Subject: [Tagging] Shop=tailor vs craft=tailor
>
> 
>
>https://github.com/gravitystorm/openstreetmap-carto/pull/3126#issuecomment-373963431
>
>https://taginfo.openstreetmap.org/search?q=shop%3Dtailor
>
>10 000 uses
>
>vs
>
>https://taginfo.openstreetmap.org/tags/craft=tailor#overview
>5000
>
>Should we support both or just one(if so which?)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Manor tagging

2018-03-17 Thread Colin Smale
A Manor is not a building, it's an area of land. A Manor House is a building. 

On 17 March 2018 19:40:31 CET, "José G Moya Y."  wrote:
>There are structures which are "manors" and I would't tag as a castle.
>As
>an example, a Spanish "cortijo" is the center of a big (originally,
>feudal)
>estate that is metonymically called "cortijo", too.
>
>The central building has a defensive purpose. Historians would say some
>walled villages are shaped  "in a 'cortijo' shape". But most people in
>Spain would't consider a "cortijo" as a castle.
>
>So I would left the assignment of a castle tag to "emic" local
>knowdledge.
>French manors (châteaux) are castles; from your words, it seems british
>manors are castles, but in some countries manors are definitely no
>castles.
>
>
>El 17/3/2018 13:45, "Christoph Hormann"  escribió:
>
>> On Saturday 17 March 2018, Volker Schmidt wrote:
>> >
>> >   I would remove the part that requires a current administrative
>> > function.
>> >
>> >
>> > Please do not remove this. This is the wording that made me use the
>> > manor tag for the Venetian Villas, which have exactly this
>> > characteristic. I believe, but am not sure, that the same applies
>to
>> > the UK manor houses .
>>
>> I think Martin's point was that a historic manor house does not have
>to
>> fulfill a present day function as administrative centre of an
>> agricultural estate.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Manor tagging

2018-03-17 Thread Colin Smale
I have to agree with Martin on this. A Manor was an estate, which typically had 
a big house where the feudal Lords lived, called the Manor House. The building 
therefore cannot itself be a Manor, and any feudal function has long since 
disappeared. 

On 17 March 2018 13:17:27 CET, Volker Schmidt  wrote:
>.
>
>I would remove the part that requires a current administrative
>function.
>
>
>Please do not remove this. This is the wording that made me use the
>manor
>tag for the Venetian Villas, which have exactly this characteristic. I
>believe, but am not sure, that the same applies to the UK manor houses
>.
>
>Volker
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=cannabis

2018-03-17 Thread Colin Smale


On 17 March 2018 13:24:04 CET, Paul Allen  wrote:
>On Sat, Mar 17, 2018 at 10:17 AM, James  wrote:
>
>  For example, Netherlands, where some coffee shops also sell
>cannabis (which may constitute the bulk of their business and be the
>main
>reason people use them).

Koffieshop is a euphemism for cannabis outlet. It's the ONLY reason people use 
them. If you just want a cup of coffee and a piece of cake, then you go to a 
cafe or a restaurant. 

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


Re: [Tagging] Tagging request: unnecessary admin_level tags

2018-03-10 Thread Colin Smale
On 2018-03-10 17:41, 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 which:
> 
> * can do the nesting without any sort of level number, including none, and 
> with any boundary type
> * can even nest one boundary type such as administrative inside another such 
> as political to avoid duplicating identical trees of two types
> * hence make never-ending discussions unnecessary about which numbers to use 
> or how to insert a level between 6 and 7; levels can and should be replaced 
> by names such as "province" and "district" with the result that a map can 
> tell (name) "province Liège" from "arrondissement Liège" (and "city Liège")

In the UK designation=* is used (with managed, not free-text, values) to
indicate exactly what sort of admin entity it is. There can be different
entities at the same level: metropolitan, non-metropolitan districts and
London boroughs are all at level 8, and unitary authorities and
non-metropolitan counties share level 6. (The four nations all have
their own local government structures anyway). This means the name tag
can be kept pure, without having to incorporate the "function" as that
can easily be seen from the designation. 

There is a subtle difference between the area, and the local government
entity that administers it. The relationship is not always 1:1, even at
the same level. The UK is a complicated place. 

Slightly OT: Actually the UK admin levels need a bit of review. The
Regions (admin level 5) have (and have never had) no administrative
function, and there are now Combined Authorities with (limited) admin
functions spanning multiple UAs at level 6. We should convert the
Regions to something like statistical or political, and free up admin
with level 5 for the CAs. 

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


Re: [Tagging] Tagging request: unnecessary admin_level tags

2018-03-10 Thread Colin Smale
On 2018-03-10 17:41, André Pirard wrote:

> * "ceremonial" Berkshire [1] that is not administrative, has no level and yet 
> contains administrative "councils"
> Berkshire itself, however, is not a subarea of a higher level but it could
> 
> * Relation Bracknell Forest (113682) [2] as subarea
> * Relation Reading (115074) [3] as subarea
> * Relation Slough (117097) [4] as subarea
> * Relation West Berkshire (116938) [5] as subarea
> * Relation Windsor and Maidenhead (111014) [6] as subarea
> * Relation Wokingham (114311) [7] as subarea

In an administrative sense his is a logical error. The UAs should not be
a subarea of the ceremonial county. However in a geometrical sense it is
not wrong of course, although you could consider it redundant. 

A ceremonial county boundary is defined using a different process to
administrative counties, and in theory there can be temporary divergence
(if the admin boundary is changed by law and it takes a while for the
ceremonial county to catch up) or, indeed, permanent divergence (such as
County Durham which is split between two admin counties). 

I would be in favour of removing the subarea links in the case of the
Berkshire UAs. 

A ceremonial county has no level because it doesn't need one - there are
no ceremonial entities at a higher or lower level. 

Colin 

Links:
--
[1] https://www.openstreetmap.org/relation/52411
[2] https://www.openstreetmap.org/relation/113682
[3] https://www.openstreetmap.org/relation/115074
[4] https://www.openstreetmap.org/relation/117097
[5] https://www.openstreetmap.org/relation/116938
[6] https://www.openstreetmap.org/relation/111014
[7] https://www.openstreetmap.org/relation/114311___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging request: missing admin_level tags

2018-03-10 Thread Colin Smale
On 2018-03-10 11:56, osm.tagg...@thorsten.engler.id.au wrote:

> I agree that the priorities need to be codified (for the standard style), but 
> this remains unchanged, no matter if the boundaries are rendered by polygon 
> or by way.

Sorry, you are right, I should have made that clear; I was intending to
refer to the standard style as shown on openstreetmap.org. 

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


Re: [Tagging] Tagging request: missing admin_level tags

2018-03-10 Thread Colin Smale
On 2018-03-10 11:31, osm.tagg...@thorsten.engler.id.au wrote:

>> There is nothing about the data that's desired on the ways that requires any 
>> sort of human decision making, it can all be automatically derived from 
>> information that's already available.

One thing that should maybe be codified, is where multiple types of
boundary coincide. For boundary=administrative it is pretty clear that
the lowest value of admin_level takes precedence for the rendering, but
what about if it is co-linear with a political boundary for example? I
would expect the rendering for the admin boundary to take precedence
here, but does everyone agree with that? What about the boundary of a
police area combined with an admin boundary? 

I am raising it here because it is subjective, i.e. subject to human
decision making, in the absence of any consensus about the relative
rendering priorities of these boundary types. 

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


Re: [Tagging] Tagging request: missing admin_level tags

2018-03-10 Thread Colin Smale
Matthijs, 

This goes against the principle of tagging the relation, not the
members. An admin area is syntactically analogous to a multipolygon and
it would be a shame to introduce yet another polygon tagging paradigm. 

What are you thinking for other types of boundaries? boundary=political,
boundary=national_park come to mind. Will they be treated differently to
boundary=administrative?

What do you intend exactly when you say "maritime boundaries"? That part
of a (national) boundary which crosses water? Or some other definition? 

Colin 

On 2018-03-10 01:51, Matthijs Melissen wrote:

> Hi all,
> 
> OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is
> considering to change the mechanism for rendering admin boundaries.
> The proposed rendering of admin borders will be based on admin
> boundary ways rather than polygons. This has a number of advantages -
> for example, it will make it possible to style maritime boundaries
> differently.
> 
> The admin boundary ways are already in the database. However, in some
> cases they are missing an admin_level tag. When the proposed style
> change will be deployed, boundary=administrative ways without
> admin_level tag will no longer be rendered. I would therefore suggest
> to make sure admin_level tags are present on all
> boundary=administrative ways.
> 
> A map showing admin boundary ways without admin_level tag (displayed
> in gray) can be found here:
> http://product.itoworld.com/map/2?lon=20.00736=51.92203=6
> As can be seen, most countries already do have admin_level on ways.
> However, in for example Poland, Iran and Australia, this data seems to
> be missing.
> 
> -- Matthijs
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] reviving hollow way

2018-02-19 Thread Colin Smale
Wikipedia says they are also known as hollow way - you learn something
every day. Sunken Lane appears to be the preferred terminology however. 

https://en.wikipedia.org/wiki/Sunken_lane

Why historic? It still is a sunken lane. If you go back a couple of
hundred years it probably wasn't though - the level has lowered through
erosion over a very long period. 

It is a way in a cutting, but a special type of cutting whereby it is
not deliberately lowered by a single act of man (or highways authority
or whatever). As such I think cutting=sunken_lane feels good. 

On 2018-02-19 11:48, joost schouppe wrote:

> Hi, 
> 
> Hollow way is probably a germanism; it's what sunken lanes are literally 
> called in Dutch too. I absolutely agree that we should stick to British 
> English for tags, wherever possible. So if we change the proposal to 
> historic=sunken_lane, then we're all set for voting, right? 
> 
> Almost all the hollow_way's in Germany seem to have been made in one go 
> (looking at taghistory.raifer.tech), so I think that means there's a decent 
> chance for a relatively massive change operation. 
> 
> ___
> 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] Short-term parking zones

2018-01-23 Thread Colin Smale
Was the speed limit already the responsibility of the regional
governments? Or was there a constitutional change to delegate that power
to them? 

If they already had the power, the source:maxspeed value should not have
referred to BE but to Flanders specifically (BE:VL?).

On 2018-01-23 10:00, Marc Gemis wrote:

> We had this situation last year, when Flanders (northern part of
> Belgium) decided to change the speed limit from 90 km/h to 70 km/h.
> Brussels and Wallonia kept the default on 90 for rural roads.
> Not only was this for a part of the country, but many roads already
> had signs for maxspeed 70 or zone 70 before the change. So we had to
> change the source:maxspeed as well for all roads, to indicate that it
> is now on regional level.
> Some roads that were 90 remained 90 after the official changes, but
> got (or already had) signs.
> 
> So many more changes were needed than just retagging roads with
> source:maxspeed=BE:rural from 90 to 70.
> 
> regards
> 
> m
> 
> On Wed, Jan 17, 2018 at 12:33 PM, Martin Koppenhoefer
>  wrote: 2018-01-16 23:03 GMT+01:00 Kevin Kenny 
> : 
> ...I've never tried to tag any of that sort of regulatory information, but
> I can imagine that applying it to all the streets in the town would be both
> tedious and unmanageable (the latter because if the town were to change the
> ordinance, it would mean updates to many hundreds of highway segments). 
> 
> While I agree it is not the perfect solution, we are trying to deal with
> similar provisions (default implicit maxspeed by context) through additional
> tags which refer to the legislation. E.g. we add explicit maxspeed tags to
> roads inside settlements where the maxspeed is implicit (within the city
> limit signs), and add source:maxspeed tags (e.g. value IT:urban in this
> case) for the unlikely case, that the law changes, so we can automatically
> select all ways with this referrer and change their maxspeed in one go,
> without needing to care for signedposted maxspeeds with the same value
> (because they should have source:maxspeed=sign or maybe nothing). At least
> this is the theory, so far we haven't needed it.
> 
> Even if your regulations are not national or by the state but only in your
> county or township, you could add some additional tag that refers to the
> ordinance, so if it changes you can change all those cases in one go.
> 
> Cheers,
> Martin
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] Proposed features - Voting - Pressurized waterways

2018-01-22 Thread Colin Smale
How about waterway=pressurised (with an s instead of a z) for correct
(British) English spelling which (unless I have missed something) is
still the lingua franca of OSM?

On 2018-01-22 19:40, François Lacombe wrote:

> Hi Volker,
> 
> waterway=pressurized is compatible with both standard and pumping hydropower 
> plants. The doesn't cover power parts and hydraulic parts may be the same.
> 
> I've tested this tagging on a site with 2 different power plants, one is 
> pumping and the second is standard (last is used to power up the first to 
> start pumping) Pumping : https://www.openstreetmap.org/relation/3113489 
> Standard : https://www.openstreetmap.org/relation/3113488
> 
> They use the same pipes, with waterway=pressurized on it.
> 
> Is this clear for you ? 
> 
> François 
> 
> 2018-01-22 19:12 GMT+01:00 Volker Schmidt :
> 
>> I would suggest to have something similar for the thousands of water pumping 
>> stations here in the Veneto region of Northern Italy (Po valley), and most 
>> likely hundreds of thousands world-wide. Not sure if it makes sense to put 
>> it in the same proposal. Certainly some components are identical at least in 
>> appearance, but also most likely in function. I see them daily,but am not an 
>> expert, unfortunately
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging [1]
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] drinkable vs. drinking_water

2018-01-10 Thread Colin Smale
Which law is that? And in which language? 

In French for example "potable" means "drinkable (without problems)" 

I think you are a little inaccurate with your suggestion that
drinking_water is an antonym of waste water/sewage. There is plenty of
water out there which is neither - lakes and rainwater for example, and
plenty of water which is even worse than sewage (industrial waste
stuff).

On 2018-01-10 16:00, Cez jod wrote:

> Potable and drinking_water are not equal.
> 
> drinking_water=yes means I can drink water straight from the source (tap, 
> fountain, source) the water has been laboratory tested, so I know I can drink 
> it without boiling.
> 
> Potable=yes/no means that water in any case should be boiled before 
> consumption (raw water) because it has not been tested in the laboratory. 
> That's the law.
> 
> amenity=drinking_water it contains in itself the tag Potable=yes / no (no 
> need to add it)
> 
> amenity=drinking_water is antonyms for waste water/sewage 
> ___
> 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 - (Fire Hydrant Extensions (part 3))

2017-12-19 Thread Colin Smale
Hi Moritz, 

It depends on what characteristics are important to you. 

"water driven" is power transfer medium so pump:power_medium=water. This
is not the energy source! It doesn't say if the water has
potential/kinetic energy due to gravity, or if it itself is being
pressurised by a powered pump (e.g. hydrostatic drive) 

"integrated" is to distinguish from something else? What would be
alternatives to a pump being "integrated"? 

"bilge pump" is about its function, so something like
"pump:function=bilge" 

"in a well" is about its location so "pump:location=bottom_of_well"?

How about the type of pump? Centrifugal? Reciprocating? 

And the medium that is being pumped? In this context it is probably
water but in general a pump could be used for all sorts of stuff. 

--colin 

On 2017-12-19 17:31, Moritz wrote:

> Hi Colin,
> 
> Am 2017-12-19 16:29, schrieb Colin Smale: 
> 
>> Please don't use "pump:type" as it invites people to use it for loads of
>> different things. You are actually doing it yourself. A "bilge pump" is
>> functional and says nothing about the construction or power source (even
>> if there is such a thing as a typical bilge pump). And "electric_pump"
>> is about the power source, and says nothing about the function or
>> construction.
> 
> What is your suggestion for proper tagging a
> 
> * water driven bilge pump which is integrated in the well
> * an electric pump integrated in the well?
> 
> Moritz
> 
> On 2017-12-19 16:20, François Lacombe wrote:
> 
> Hi Viking,
> 
> Thank you for your work on this additional part
> 
> I'd be in favor of grouping pump et pump:type in on "pump" key. Valid values 
> would be yes, bilge_pump or electric_pum. Yes would be used only if pump 
> technology is unknown.
> 
> There is no need of 2 keys.
> 
> All the best
> 
> François
> 
> FRANÇOIS LACOMBE
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com [1] [3 [1]]
> @InfosReseaux [4 [2]]
> 2017-12-19 10:40 GMT+01:00 Viking <vikin...@tin.it>:
> 
> I removed all "useful combination" on hydrants wiki, because all optional 
> tags could be added to this list and it would become unnecessarily long.
> 
> Best regards
> Alberto
> 
> ---
> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
> https://www.avast.com/antivirus [1 [3]]
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging [2 [4]] 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

Links:
--
[1] https://www.avast.com/antivirus
[2] https://lists.openstreetmap.org/listinfo/tagging
[3] http://www.infos-reseaux.com
[4] http://www.twitter.com/InfosReseaux
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging 

Links:
--
[1] http://www.infos-reseaux.com
[2] http://www.twitter.com/InfosReseaux
[3] https://www.avast.com/antivirus
[4] https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

2017-12-19 Thread Colin Smale
Please don't use "pump:type" as it invites people to use it for loads of
different things. You are actually doing it yourself. A "bilge pump" is
functional and says nothing about the construction or power source (even
if there is such a thing as a typical bilge pump). And "electric_pump"
is about the power source, and says nothing about the function or
construction. 

//colin

On 2017-12-19 16:20, François Lacombe wrote:

> Hi Viking,
> 
> Thank you for your work on this additional part
> 
> I'd be in favor of grouping pump et pump:type in on "pump" key. Valid values 
> would be yes, bilge_pump or electric_pum. Yes would be used only if pump 
> technology is unknown.
> 
> There is no need of 2 keys.
> 
> All the best
> 
> François
> 
> FRANÇOIS LACOMBE
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com [3]
> @InfosReseaux [4] 
> 2017-12-19 10:40 GMT+01:00 Viking :
> 
>> I removed all "useful combination" on hydrants wiki, because all optional 
>> tags could be added to this list and it would become unnecessarily long.
>> 
>> Best regards
>> Alberto
>> 
>> ---
>> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
>> https://www.avast.com/antivirus [1]
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging [2]
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] https://www.avast.com/antivirus
[2] https://lists.openstreetmap.org/listinfo/tagging
[3] http://www.infos-reseaux.com
[4] http://www.twitter.com/InfosReseaux___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "building=college" tag missing from building key page

2017-12-08 Thread Colin Smale
This is why the ISCED codes exist: 

https://en.wikipedia.org/wiki/International_Standard_Classification_of_Education#ISCED_2011_levels,_categories,_and_sub-categories


They are already used in OSM: 

https://wiki.openstreetmap.org/wiki/Proposed_features/ISCED 

So the original enquiry can be addressed with building=school and
isced:level=*

On 2017-12-08 22:30, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 7. Dec 2017, at 19:31, Marco Boeringa  wrote:
>> 
>> Anyway, no tagging scheme for education will ever be perfect, the 
>> differences between individual countries and the usage of specific 
>> terminology is vast.
> 
> while this is true, choosing good names for the tags still helps in reducing 
> misunderstandings. "college" for example is not a very clear term for use on 
> global scale, because it can mean different things in different places / 
> context. Something more abstract like secondary_school or different words 
> like vocational school or professional school, which describe a concept, 
> would IMHO be better than college.
> 
> cheers,
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   3   4   5   6   >