Re: [Tagging] Barrier=berm

2019-11-25 Thread Dave Swarthout
The proposal looks good to me. Thanks for your effort.

On Tue, Nov 26, 2019 at 9:51 AM Graeme Fitzpatrick 
wrote:

> Following the recent discussions of protective walls, I've created a page
> for barrier=berm  https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dberm
>
> As it is already in use 61 times, I didn't think we had to go through the
> full RFC / voting procedure, but please correct me if I'm wrong?
>
> As always, comments & discussion welcomed! :-)
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?

2019-10-26 Thread Dave Swarthout
I live in Alaska and the tidal range there is huge, 28 feet (8.5 meters)
with the spring high tides. Also, Alaskan rivers are usually so remote that
one has no good way to even estimate how far the high tide extends upriver.

On Sat, Oct 26, 2019 at 6:25 PM Iago Casabiell 
wrote:

> This is a very complicated subject, made even more compliclated because
> the coastline is only mapped in high tide. Intertidal zones are huge.
> There's a proposed tag to map the low tide coast:
> natural=mean_low_water_springs.
> (
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dmean_low_water_springs
> )
>
> I think a key for a generic term for a river mouth is needed, extending
> beyond natural=coastline, wich should reach upriver to where the high tide
> crawls.
> Also there should be a specific tag for each type of river mouth: estuary,
> fjord, ría, delta, etc.
>
> I live in Galicia in NW Spain where the tidal range is above 4m and tiny
> rivers open into huge well defined bays called rías. I've been mapping them
> as bays in these last few months and there is still much work to do
> extending natural=coastline upriver, drawing natural=mean_low_water_springs
> and defining each type of natural=wetland contained in the ría. Check it
> out and you'll see it's complicated, and also see why this new tagging is
> very important.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?

2019-10-26 Thread Dave Swarthout
Hi Clifford,

Can you help me find something in the Skagit Delta that is tagged with the
estuary tag? When I read your post, I immediately tried to check it out
because I'm trying to understand how that tag is being used currently. But
I wasn't able to find anything.

Thanks for your help.

On Sat, Oct 26, 2019 at 9:29 AM Clifford Snow 
wrote:

> Looking at the US NHD estuary is broadly defined. For example, The Skagit
> River flows through my county into the Puget Sound in Washington State. I
> would expect the delta area, where it empties into the sound to be defined
> as an estuary. And it is. But  apparently so is the whole of Puget Sound.
> The trouble I see if 1) if we define an estuary different than scientific
> model or 2) use the science definition of an estuary. If we differ from the
> science definition, we'll constantly battle users of what is included in
> our model and what isn't. If we go with the scientific definition then
> we'll get questions on why we picked that model when it sometimes doesn't
> make sense.
>
> I'd really like to hear from someone that can explain exactly what an
> estuary encompases and what makes sense to map.
>
> Best,
> Clifford
>
> On Fri, Oct 25, 2019 at 5:26 PM Dave Swarthout 
> wrote:
>
>> Then there is the additional problem that the terminal end of the way
>> used to indicate the waterway=river connects with the "coastline" which is
>> where the estuary portion of the river ends. I'm not clear about which
>> object you propose adding the estuary=yes tag to? Let me put it another
>> way. If the particular river is mapped using a way that terminates on the
>> coastline, where does the estuary tag get placed? I realize that some
>> rivers are mapped using just a riverbank area, i.e, there is no way to
>> terminate, but that still leaves my question unanswered.
>>
>> On Sat, Oct 26, 2019 at 7:13 AM Graeme Fitzpatrick 
>> wrote:
>>
>>> & we get back to the same problem previously discussed with river > sea
>>> ...
>>>
>>> At what point does a river become an estuary & where does that then
>>> become the sea?
>>>
>>> Having said that, I quite like river=estuary :-), but I think we'll have
>>> problems defining it?
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>>
>>> On Sat, 26 Oct 2019 at 09:53, Paul Allen  wrote:
>>>
>>>> On Sat, 26 Oct 2019 at 00:43, Warin <61sundow...@gmail.com> wrote:
>>>>
>>>>>
>>>>> estuary = tidal mount of a large river? As defined by the Oxford
>>>>> Dictionary.
>>>>>
>>>>
>>>> Estuaries are complicated.  https://en.wikipedia.org/wiki/Estuary
>>>>
>>>> --
>>>> 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
>>>
>>
>>
>> --
>> 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
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>


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


Re: [Tagging] Tagging estuaries: estuary=yes or river=estuary?

2019-10-25 Thread Dave Swarthout
Then there is the additional problem that the terminal end of the way used
to indicate the waterway=river connects with the "coastline" which is where
the estuary portion of the river ends. I'm not clear about which object you
propose adding the estuary=yes tag to? Let me put it another way. If the
particular river is mapped using a way that terminates on the coastline,
where does the estuary tag get placed? I realize that some rivers are
mapped using just a riverbank area, i.e, there is no way to terminate, but
that still leaves my question unanswered.

On Sat, Oct 26, 2019 at 7:13 AM Graeme Fitzpatrick 
wrote:

> & we get back to the same problem previously discussed with river > sea ...
>
> At what point does a river become an estuary & where does that then become
> the sea?
>
> Having said that, I quite like river=estuary :-), but I think we'll have
> problems defining it?
>
> Thanks
>
> Graeme
>
>
> On Sat, 26 Oct 2019 at 09:53, Paul Allen  wrote:
>
>> On Sat, 26 Oct 2019 at 00:43, Warin <61sundow...@gmail.com> wrote:
>>
>>>
>>> estuary = tidal mount of a large river? As defined by the Oxford
>>> Dictionary.
>>>
>>
>> Estuaries are complicated.  https://en.wikipedia.org/wiki/Estuary
>>
>> --
>> 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
>


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Dave Swarthout
Asking OSM mappers if they have "strict standards" on this issue is chasing
a fantasy, IMHO. We discussed this in our local Thailand mapping forum and
AFAIK, it wasn't resolved. In one example, a five-lane highway with no
physical barrier and the "fifth lane" painted with big yellow stripes, the
mapper used two separate ways, both tagged oneway=yes to represent the
situation. I disagreed. My thinking is that OSM prefers having a physical
barrier before tagging two separate ways and I do too. By the way, Google
maps uses two lanes both tagged as oneway for this particular example.

YMMV

On Thu, Oct 10, 2019 at 1:40 PM Frederik Ramm  wrote:

> Hi,
>
> DWG has been asked to mediate in a user dispute in Germany where a local
> mapper has chosen to represent a busy four-lane primary highway (two
> lanes in each direction, and a double continuous line painted in the
> middle which is physically possible but legally not allowed to cross).
>
> Other mappers object to this saying that it violates the rule that there
> must be some sort of physical division to allow that form of mapping.
>
> The original mapper claims that using two separate oneway=yes ways is
> clearer and easier, as it does away with the need for turn restrictions
> at junctions. Other mappers claim that the two-separate-way mapping is
> violating rules and that OSM will soon become unusable if everyone maps
> how they want.
>
> The question is basically two-fold; one, what are the established
> standards and rules concerning this situation, and two, in how far is it
> acceptable to deviate from these standards if a local mapper thinks it
> is a good idea.
>
> Personally I believe that "physical division => separate ways; no
> physical division => shared way" is the standard in OSM, or perhaps at
> least the "rule of thumb". But (since people in the German discussion
> have more or less claimed that the world is going to end if local
> mappers are allowed to treat this differently) I'd like to hear from
> mappers in other countries how rigidly this standard is applied. Is it
> something where local mappers have some freedom of judgment (like when
> choosing which highway=* category to apply to a road) or do you have
> strict standards and definitions?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] New tag proposal: 'addr=milestone'

2019-10-01 Thread Dave Swarthout
The "milestone" value is a misnomer in most modern situations. Here in
Thailand, many roads have actual mile markers, er kilometer markers, but
they are not made of stone. They are painted concrete. In the U.S. there
are very few of these if any. When I'm tagging mile markers in the U.S., I
include a tag description=Metal flag

One of the things I love to map in Thailand are km=0 milestones which
denote the beginning of a numbered route. To date, I've added approximately
270 of these special milestones.

On Wed, Oct 2, 2019 at 12:43 AM Aaron Young  wrote:

> What I'm unclear on is if these addresses refer to an actual road
> marker, or an actual distance based upon interpolation between
> actual road markers.  If you have a road marker at 8km and another
> road marker at 9km, would a house between the two have addr:milestone
> 8, 9 or 8.5?  If the address is of an actual road marker then addr:milestone
> would be appropriate (given that we already misuse highway=milestone
> to mean kilometre markers); if it's a distance that doesn't correspond to
> an actual road marker then we need a better name.
>
> I would expect the address:milestone=8.5 would be used.  This is something
> that can be determined by software and is not always written on signage but
> widely used.
>
> There are also usages within the US for emergency response purposes.
> Highway call boxes often use mile marker or milestone reference to
> determine location of incident.  US highways have milemarker signage every
> mile to assist with this purpose.  Utilizing it in address finding
> throughout the world is a needed tag in my opinion.
>
> Aaron
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] New tag proposal: 'addr=milestone'

2019-10-01 Thread Dave Swarthout
> I may be mistaken but I seem to remember mile markers being used in rural
areas of the USA to indicate linear position along a main road.

You are not mistaken. Many hotels and parks in the rural areas of Alaska
mark their location that way.

On Tue, Oct 1, 2019 at 2:06 PM Colin Smale  wrote:

> On 2019-10-01 08:18, Florian Lohoff wrote:
>
> Hi Jorge,
>
> On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote:
>
> Throughouthe entire Latin American region and some other parts of
> the world, it is quite common to find the kilometer (Km.) information,
> as may be found on the "highway:milestone", as part of the actual
> addresses. Mostly used in suburban and rural areas, which may usually
> not even have any visible references or even house numbers, the use of
> the milestone is widely utilized to find an address in these regions.
>
>
> We have such addresses in Germany too. They are pretty rare though.
> sometimes really rural mobile masts or copper distribution
> street cabinets and stuff carry addresses like this.
>
> I may be mistaken but I seem to remember mile markers being used in rural
> areas of the USA to indicate linear position along a main road.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Strange tags

2019-09-29 Thread Dave Swarthout
Yes, it's always complicated, isn't it? I realize many folks are interested
in climbing all the peaks on certain lists. Good for them. The Adirondack
46ers was the only one familiar to me.

As I said, I have no stake in this. It was mostly curiosity that motivated
me to bring it to the Tagging group.







On Mon, Sep 30, 2019 at 8:40 AM Kevin Kenny  wrote:

> On Sun, Sep 29, 2019 at 7:51 PM Dave Swarthout 
> wrote:
> >
> > Well, I'll be damned. These hikers, or "hillbaggers", are using these
> tags for their own purposes. Many of them could easily be derived from the
> ele tag. I have no stake in whether they do that or not except to say that
> it encourages others to make up tags for their own regional uses. In New
> York State there is a list of 46 peaks that top 4,000 feet and anyone who
> summits them joins the group called "The 46ers." But nobody maps them with
> 46er=yes/no because this information is immediately obvious from the ele
> tag.
>
> Actually, it's the list of peaks that were thought to be above 4000
> feet (and with requirements for prominence and isolation) at the time
> that the club was founded. Simple elevation is not enough to determine
> this. Because of prominence and isolation requirements, Pyramid Peak
> (4597 ft AMSL) is not on the list; it is considered to be a subsidiary
> summit of Gothics. Similarly, Little Marcy and Schofield Cobble are
> considered subsidiary summits of Mount Marcy, but Gray Peak squeaks in
> with just barely the required prominence. Moreover, it turns out in
> modern surveys that Mount Blake, Cliff Mountain, Nye Mountain and
> Couchsachraga are all less than 4000 feet AMSL, while MacNaughton
> Mountain tops 4000 feet but is not one of the 46. Finally, Slide
> Mountain (4120 feet) and Hunter Mountain (4040 feet) are excluded by
> being outside the Adirondack Park - they are both clearly above 4000
> feet and have tremendous prominence, but they're in an entirely
> different range.
>
> The Catskill 35 (which has Slide and Hunter as its two tallest peaks)
> are another list that's locally significant. It purports to be the "35
> summits above 3500 feet in the Catskills" but once again that's an
> oversimplification. For it, the prominence and isolation rules have
> been fine-tuned over the years to keep the list stable. "The Dink",
> south of Cornell Mountain, "Camel's Hump" west of Thomas Cole
> Mountain, or "Little Slide" north of Slide Mountain all are
> unquestionably named peaks above 3500 feet, but either are not
> prominent enough or are too close to a different peak. The definitions
> have to be tuned very finely, however, to keep Wittenberg from being
> considered a subsidiary summit of Cornell Mountain. Since the club's
> founding, only one peak has been added to the list: its name is
> Southwest Hunter, or Leavitt Peak, or Hill 3750, depending on what
> version of the list you consult. It was nameless until its inclusion
> on the list meant that hikers needed a name for it. (Grace Peak in the
> Adirondacks has a somewhat similar story, and did indeed acquire a
> name from being listed.) The current feeling in the club appears to be
> that the list should now be fixed as it stands. If it turns out, as is
> plausible, that the high point of Dry Brook Ridge or Millbrook Ridge
> tops out above 3500 feet, the sentiment appears to be that they should
> not be added.
>
> The Catskill 35 list also contains four summits (Slide, Blackhead,
> Balsam [Ulster County] and Panther) that have to be climbed twice - at
> least once in winter. The choice of which summits were included in
> that list appears to have been entirely arbitrary, and the club
> founders never offered an explanation.
>
> Given that the lists at this point are arbitrary, there's really no
> way to represent the list membership other than making up some
> entirely arbitrary scheme. If asked to come up with something, I'd
> probably put the 46 summits in a group relation and hang the name
> 'Adirondack 46' off that. I'd do a similar thing for the Catskill 35,
> but then scratch my head about how to identify the Winter Four.
>
> As it is, I use information external to OSM for rendering this area so
> that the list memberships can be shown - they are quite important to
> the local hikers, many of whom are chasing their Adirondack 46'er or
> Catskill 3500 Club badges. Peak-bagging is a serious sport around
> here!
>
> I've not tried to add the information because I eschew controversy. I
> know that on the 'tagging' list there are hard-liners who would even
> challenge adding the peaks' names to the list, on the grounds that the
> names for the most part cannot be observed in the field. (Look at a
> topo ma

Re: [Tagging] Strange tags

2019-09-29 Thread Dave Swarthout
Well, I'll be damned. These hikers, or "hillbaggers", are using these tags
for their own purposes. Many of them could easily be derived from the ele
tag. I have no stake in whether they do that or not except to say that it
encourages others to make up tags for their own regional uses. In New York
State there is a list of 46 peaks that top 4,000 feet and anyone who
summits them joins the group called "The 46ers." But nobody maps them with
46er=yes/no because this information is immediately obvious from the ele
tag.

In Thailand, there are local expat mappers who "name" a track or path in
rural regions "Single-track" or "Double track" thus indicating in their own
way whether it's suitable for motorcycle use. I try to discourage such
mapping, preferring to address it some other more uniform and acceptable
manner. This usage amounts to the same thing in IMO. I mean, the list in
the Wikipedia article is a long one. Do we really want all this extra, what
I would term, clutter? I'm not suggesting removing those tags but was just
curious about them.

On Mon, Sep 30, 2019 at 2:39 AM Valor Naram  wrote:

> But as datauser I won't use that data. We need to find a way to make the
> tags more useful in global scope. That can be done by translating to widely
> supported tags etc.
>
> ~ Sören Reinecke alias Valor Naram
>
>
>  Original Message 
> Subject: Re: [Tagging] Strange tags
> From: ael
> To: tagging@openstreetmap.org
> CC:
>
>
> On Sun, Sep 29, 2019 at 07:24:16PM +0200, Jan Michel wrote:
> > On 29.09.19 17:07, Paul Allen wrote:
> > >
> > > Really?
> > >
> > > There are people who are VERY interested in these things.  People who
> > > want to know where
> > > Munros, Donalds, Grahams, Marilyns, TuMPs, etc. are.
> >
> > Well... There is no documentation of these tags in the OSM wiki.
>
> While that is certainly desirable, it is not necessary, especially where
> the terms are well known - at least in the relevant region.
>
> >
> > These seem to be very local terms that are not used outside of Scotland
> > (British Isles?). In general we oppose such local terms as keys because
> they
> > won't be of any use outside a small area.
>
> Who are "we" who oppose such terms?
>
> OSM is trying to be the best map possible, and the map should be useful
> in small areas (like the UK) as well as more globally.
>
> Even if one local mapper with special local knowledge tags something
> only understood in a very small area, it is still improving the map.
>
> ael
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
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] Strange tags

2019-09-29 Thread Dave Swarthout
Hi,

I was mapping an area of geologic significance in Scotland, Dob's Linn,
today and as I was panning here and there looking at nearby features came
across some tags that I have never seen before. They were added back in
2010 so I didn't bother to try to contact the original mapper. Instead,
perhaps one of you has stumbled on similar tags in your work. I'm guessing
that the tags corbett, donald, graham, and munro were either contributors
to the data and their names preserved by user:marscot or something else I
can't fathom.

In a diary entry from 2009, user:marscot has this to say: "tomorrow I head
into the mountains to grab another 3 munros for me and osm, they are Cairn
Asoda and Cairnwell, and another one further along." I gather from Google
that a "munro" is a peak in Scotland that is less than 3000 ft in height.
All fine and dandy, but is that a valid tag? And what is a "donald", or 

corbett=yes
donald=yes
ele=821
graham=no
man_made=cairn
munro=no
name=White Coomb
natural=peak
note=cairn yes
source=local_knowledge
wikidata=Q7994603
wikipedia=en:White Coomb

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


Re: [Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

2019-08-28 Thread Dave Swarthout
Thanks for a nice job on the proposal. The new tag seems appropriate as
well. I have not seen anything like this in my travels but it sounds like a
wonderful idea.

Cheers,

Dave

On Wed, Aug 28, 2019 at 12:34 PM simson.gert...@gmail.com <
simson.gert...@gmail.com> wrote:

> The wording "bump" is ok in my eyes for the lowered hatch type too because:
>
> -after you roll down the inclined plane the edge "bumpes" you up again
> -I don't think the word "bump" necessarily implies the direction up or a
> direction at all.
> -The brand name of the device on the pictures is "Actibump"
>
> Regards
>
> Am 28.08.2019 um 21:14 schrieb Anton Klim:
> > Thanks for the proposal, this is something I haven’t heard of before!
> > Not sure if “bump” would be suitable for those that slide down beneath
> the surface? Maybe traffic_calming=dynamic/variable?
> >
> > Regards
> > Ant
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Use of tag "import=yes" on objects, not changesets?

2019-08-10 Thread Dave Swarthout
The Facebook team did employ some sort of AI to assist in the
identification of highways but it wasn't always right. And the mappers they
employed didn't know OSM very well. We met with them several times to offer
advice and hints but some of the more active mappers in Thailand are still
railing about the failure of the team to come up to speed. They joined OSM,
they mapped, they departed. Next up, Grab. Another huge imbroglio resulted.
Same issues. Inaccurate mapping, broken routes, especially in Bangkok.

The horse has definitely left the barn. We're left with what remains a very
large task of cleaning up and verifying. On a positive note, they added
thousands of highways for us and made their high-quality DigitalGlobe
imagery available to ordinary OSMers. That, to me anyway, was well worth
the trade-off.

On Sat, Aug 10, 2019 at 9:43 AM Paul Allen  wrote:

> On Sat, 10 Aug 2019 at 17:27, Dave Swarthout 
> wrote:
>
>> The decision to use the import=yes tag wasn't mine nor that of other
>> experienced Thailand mappers. The Facebook crew "invented" this use, for
>> whatever internal reason(s)of their own and we local mappers simply went
>> along with it because we were desperate for a method with which to check
>> their work.
>>
>
> If Joseph was right that Facebook used AI on the aerial imagery then I'd
> say it does meet some
> of the criteria for an import unless the results were first verified by
> humans.  And since it
> sounds like Facebook dumped the unverified AI output into OSM for humans
> to check, then
> import=yes doesn't sound unreasonable (although it might have been better
> as a changeset
> tag rather than an object tag).  Would something like AI_assisted have
> been better?  Maybe.
> Would a changeset tag have been better?  Maybe.  Is there any point
> locking the stable door
> now the horse has bolted?  No.  Can we persuade Facebook to do it any
> differently in the
> future?  I have my doubts, and I expect Facebook horses will keep bolting
> because they
> never lock the stable doors.
>
> --
> Paul
>
>

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


Re: [Tagging] Use of tag "import=yes" on objects, not changesets?

2019-08-10 Thread Dave Swarthout
The decision to use the import=yes tag wasn't mine nor that of other
experienced Thailand mappers. The Facebook crew "invented" this use, for
whatever internal reason(s)of their own and we local mappers simply went
along with it because we were desperate for a method with which to check
their work.

On Fri, Aug 9, 2019 at 4:25 PM Joseph Eisenberg 
wrote:

> Thanks, Dave.
>
> Re: > "Having that tag allows us to easily locate and check the
> validity of their work.
> > ... After we check the work, we remove the import tag."
>
> This usage would be incompatible with what I was told about Indonesia:
> if they want to use this tag to find how many roads they added, they
> probably don't want me to remove it.
>
> Even for your use-case in Thailand, I think it would be better to use
> a different tag, like "computer_vision_assisted" for the facebook
> stuff, or something else more specific, since "import=yes" should mean
> that the data came from an external source, rather than from on of our
> usually sources aerial imagery.
>
> Joseph
>
> On 8/10/19, Dave Swarthout  wrote:
> > The reason those objects (mostly highways) are tagged that way in
> Thailand,
> > at least, is because much of the mapping done by the Facebook and Grab
> > teams was rather poorly executed. Having that tag allows us to easily
> > locate and check the validity of their work. One of the regular Thailand
> > contributors developed a Map Paint Style that outlines all highways
> tagged
> > with import=yes in JOSM. After we check the work, we remove the import
> tag.
> >
> > I think this is a valid use for the tag, and it's not meant to be a
> > permanent tag in any case.
> >
> > Cheers,
> >
> > Dave
> >
> > On Fri, Aug 9, 2019 at 9:49 AM Paul Allen  wrote:
> >
> >> On Fri, 9 Aug 2019 at 15:23, Frederik Ramm  wrote:
> >>
> >>>
> >>> f.s.v.o. "simple", a relatively foolproof method on a Linux machine is
> >>>
> >>> 1. download indonesia history pbf,
> >>> 2. run osmium command line tool to convert into ASCII "opl" format,
> >>> 3. grep how many ways with highway=* and v=1 are mapped by their team.
> >>>
> >>
> >> You omitted step 0: install osmium.
> >>
> >> And possibly step -1: figure out how to compile and install osmium
> >> because
> >> it's not
> >> available as a package for the distro you're using.
> >>
> >> Yeah, both of those steps ought to be obvious to Linux users.  But if
> >> somebody
> >> puts a Linux distro on an old computer specifically just for this then
> >> those are things
> >> they need to be aware of.  Osmium isn't a standard part of Linux and
> it's
> >> not available
> >> pre-packaged for all distros.
> >>
> >> --
> >> Paul
> >>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >
> >
> > --
> > Dave Swarthout
> > Homer, Alaska
> > Chiang Mai, Thailand
> > Travel Blog at http://dswarthout.blogspot.com
> >
>


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


Re: [Tagging] Use of tag "import=yes" on objects, not changesets?

2019-08-09 Thread Dave Swarthout
The reason those objects (mostly highways) are tagged that way in Thailand,
at least, is because much of the mapping done by the Facebook and Grab
teams was rather poorly executed. Having that tag allows us to easily
locate and check the validity of their work. One of the regular Thailand
contributors developed a Map Paint Style that outlines all highways tagged
with import=yes in JOSM. After we check the work, we remove the import tag.

I think this is a valid use for the tag, and it's not meant to be a
permanent tag in any case.

Cheers,

Dave

On Fri, Aug 9, 2019 at 9:49 AM Paul Allen  wrote:

> On Fri, 9 Aug 2019 at 15:23, Frederik Ramm  wrote:
>
>>
>> f.s.v.o. "simple", a relatively foolproof method on a Linux machine is
>>
>> 1. download indonesia history pbf,
>> 2. run osmium command line tool to convert into ASCII "opl" format,
>> 3. grep how many ways with highway=* and v=1 are mapped by their team.
>>
>
> You omitted step 0: install osmium.
>
> And possibly step -1: figure out how to compile and install osmium because
> it's not
> available as a package for the distro you're using.
>
> Yeah, both of those steps ought to be obvious to Linux users.  But if
> somebody
> puts a Linux distro on an old computer specifically just for this then
> those are things
> they need to be aware of.  Osmium isn't a standard part of Linux and it's
> not available
> pre-packaged for all distros.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Road hierarchy

2019-08-05 Thread Dave Swarthout
>Different places, different practices. In the rural areas near here, a
great many private service ways have names, so that the houses on them will
have street >addresses for emergency services to find. Often the name is
something like 'Smith Road' because it goes into the Smith family farm.
It's just a highway=service >or highway=track access=private, but is named
and signed for navigation.

That same practice is fairly common in Alaska as well. Tiger often classes
these as residentials but like all Tiger data, it must be verified before
you can believe it LOL


On Mon, Aug 5, 2019 at 11:11 AM Kevin Kenny  wrote:

> On Mon, Aug 5, 2019 at 1:07 AM Florian Lohoff  wrote:
>
>> Correct - But from my experience its either a service or it has
>> a name. At least in the part of Germany where i map.
>>
>> There are of course the 1% of exceptions where Bayer or BASF names roads
>> on their facility property. But the typical parking aisle or
>> access to a fuel station should not carry a name.
>>
>>
> Different places, different practices. In the rural areas near here, a
> great many private service ways have names, so that the houses on them will
> have street addresses for emergency services to find. Often the name is
> something like 'Smith Road' because it goes into the Smith family farm.
> It's just a highway=service or highway=track access=private, but is named
> and signed for navigation.
>
> I agree that a parking aisle or urban driveway is unlikely to have a name.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Road hierarchy

2019-08-04 Thread Dave Swarthout
Peter wrote:
My research tells me ‘unclassified’ means classified as ‘unclassified‘,
which is a class of road in the public road system.

I respectfully disagree.
That is only the case where a country has a class of roads they label or
call "Unclassified". In Alaska and Thailand, where I do the bulk of my
mapping, an unclassified highway is just that, it is a highway having no
classification. I consider it higher in the hierarchy than a residential
and lower than a tertiary, although some opinions may differ. Whether paved
or unpaved makes no difference. As long as it connects towns or hamlets in
a reasonable manner, then it is an unclassified highway.

On Sun, Aug 4, 2019 at 10:49 AM Peter Elderson  wrote:

> My research tells me ‘unclassified’ means classified as ‘unclassified‘,
> which is a class of road in the public road system. Other roads cannot be
> classified as ‘unclassified’, but should get another classification. Roads
> without classification need a fixme, not a classification as ‘unclassified’.
>
> Mvg Peter Elderson
>
> > Op 4 aug. 2019 om 16:23 heeft Martin Koppenhoefer <
> dieterdre...@gmail.com> het volgende geschreven:
> >
> >
> >
> > sent from a phone
> >
> >> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> >>
> >> A residential is also an unclassified road.
> >
> >
> > IMHO it is not, as an unclassified road is part of the interconnection
> grid, while a residential road is not
> >
> > 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
>


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


Re: [Tagging] shop=cannabis including medical cannabis

2019-06-14 Thread Dave Swarthout
@Jmapb

I agree with all of your points.

Reiterating a bit: Using the cannabis:*.* tag to designate a place where
one can buy cannabis, be it a pharmacy or a shop=cannabis, or be it for
recreational or medical use, will go a long way toward making this scenario
both understandable and logical.

I wouldn't like using shop=cannabis with amenity=pharmacy on the same
object. No way. There would also be an ugly "tag collision" with
shop=chemist (whatever that is, LOL). IMO, it would be best to use the tag
of cannabis:medical=only for such dispensaries.

On Fri, Jun 14, 2019 at 2:56 PM Jmapb via Tagging 
wrote:

> On 6/14/2019 5:33 PM, Dave Swarthout wrote:
>
> > Martin wrote:
> >
> > >It would imply adding shop=cannabis to pharmacies? In some countries
> > the sale of medicine is restricted to pharmacies.
> >
> > Not necessarily. IMO, we could also use the cannabis:medical=yes/only
> > tag to pharmacies offering it.
> >
> Yes, my understanding is that shop=cannabis is only for shops whose sole
> purpose (or at least clear primary purpose) is the sale of cannabis. It
> shouldn't automatically be added to any POI where legal cannabis is
> available.
>
> A pharmacy that sells a variety of medicines should not be tagged as
> shop=cannabis, but could still be tagged with cannabis:*=* (similar to
> drink:wine=yes at shop=deli.)
>
> IMO the shop=cannabis tag should not be used at all in any jurisdiction
> where legal cannabis is only available through general purpose
> pharmacies. (I don't know of any such places, but I assume they exist
> somewhere, or will at some point.) And obviously it also shouldn't be
> used in jurisdictions where all cannabis sales are illegal.
>
> J
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=cannabis including medical cannabis

2019-06-14 Thread Dave Swarthout
Martin wrote:

>It would imply adding shop=cannabis to pharmacies? In some countries the
sale of medicine is restricted to pharmacies.

Not necessarily. IMO, we could also use the cannabis:medical=yes/only tag
to pharmacies offering it.

On Fri, Jun 14, 2019 at 12:58 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Jun 2019, at 18:26, Jmapb  wrote:
> >
> > An accepted answer to a recent question on help.openstreetmap.org (
> >
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> > ) suggested expanding the definition of shop=cannabis to include
> > dispensaries for medical cannabis.
> >
> > This makes sense to me, and the original discussion (
> >
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> > ) doesn't really give any clear reason for excluding medical cannabis
> > shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> > are proposed and not disputed.)
>
>
> It would imply adding shop=cannabis to pharmacies? In some countries the
> sale of medicine is restricted to pharmacies.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=cannabis including medical cannabis

2019-06-14 Thread Dave Swarthout
I strongly agree that the Wiki should be updated to include the tags
already in use for medical and recreational use of marijuana. I'm don't
understand why the Wiki authors made it so restrictive in the first place.

I also agree that these dispensaries are merely special purpose shops and
not pharmacies. Furthermore, in the U.S. normal pharmacies do not, AFAIK,
sell cannabis. I suggest:

cannabis:medical=yes/only
cannabis:recreational=yes/only

Using these optional tags, shops that sell only medical or only
recreational cannabis can be better distinguished.

Also, agree that the verbiage about Colorado could be removed.

Thanks,

Dave

On Fri, Jun 14, 2019 at 9:49 AM Jmapb  wrote:

> On 6/14/2019 1:15 PM, Tobias Zwick wrote:
> > Wouldn't medical cannabis be sold in pharmacies?
>
> The world is vast and diverse, so I imagine the answer is yes. But in
> the places I map most (USA), medical cannabis is sold in single-purpose
> shops called dispensaries, which do not stock any other medicines.
> Calling them pharmacies would be a form of "troll tagging."
>
> (Of course a pharmacy that does sell cannabis, wherever and whenever
> that exists, could be tagged cannabis=yes or cannabis:medical=yes.)
>
> J
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] refugee camp

2019-06-11 Thread Dave Swarthout
I did not add a refugee=yes tag. I tagged it as a place=town because my
quick search for alternatives came up empty and there are about 50,000
people living there. That way, at least the camp name shows up on maps and
is searchable. I'll retag it based on what we decide here.

On Tue, Jun 11, 2019 at 12:06 PM Violaine_Do  wrote:

> Hi,
>
> Did you think about adding refugee=yes tag on place=* ?
>
> There were also an idea, if you have the boundary to develop rules
> around boundary, similar to boundary = administrative to
> boundary=refugee see
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Camp_Boundaries
>
> I also think is is something to dig in and happy to help...
>
> Best,
>
> V
>
> On 11/06/2019 05:39, Jan S wrote:
> >
> > Am 10. Juni 2019 22:05:53 MESZ schrieb Dave Swarthout <
> daveswarth...@gmail.com>:
> >> The refugee camps I'm familiar with in Thailand are not social
> >> facilities
> >> except in an incidental way. They are essentially internment camps
> >> surrounded by fences with guarded gates where undocumented aliens are
> >> kept.
> >> They are landuse=residential because they're isolated areas in the
> >> countryside and contain permanent dwellings but having no other way to
> >> tag
> >> it at the time, I tagged a big refugee camp near Mae Sot as place=town
> >> and
> >> name=Mae La Refugee Camp. As for the refugee aspect, I made a note and
> >> left
> >> it at that.
> > I have my doubts whether place=town is the appropriate tag for a fenced
> living area, where people are obliged to live. Why wouldn't a big prison be
> place=town then, too (just have a look at
> https://en.m.wikipedia.org/wiki/Palmasola)?
> >
> >
> >> I'm not sure which approach would be better between social_facility,
> >> amenity or what have you, but any tourism-related tag definitely will
> >> not
> >> work.
> > My idea of a refugee camp is that there's some kind of social service,
> either public or private, like food distribution, medical attention, maybe
> housing or tents being provided by the government, UNHCR, or whomever.
> Would anything like that apply to the camps in Thailand you've described?
> If yes, I wouldn't have issues with using social_facility...
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> --
> Violaine_Do
>
>

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


Re: [Tagging] refugee camp

2019-06-10 Thread Dave Swarthout
The refugee camps I'm familiar with in Thailand are not social facilities
except in an incidental way. They are essentially internment camps
surrounded by fences with guarded gates where undocumented aliens are kept.
They are landuse=residential because they're isolated areas in the
countryside and contain permanent dwellings but having no other way to tag
it at the time, I tagged a big refugee camp near Mae Sot as place=town and
name=Mae La Refugee Camp. As for the refugee aspect, I made a note and left
it at that.

I'm not sure which approach would be better between social_facility,
amenity or what have you, but any tourism-related tag definitely will not
work. In this particluar case, place=town is appropriate because it's so
large; smaller camps might be tagged as place=hamlet, etc.

On Mon, Jun 10, 2019 at 6:04 AM Phake Nick  wrote:

> If you look at it from a temporary residence for the group of people
> perspective, then I guess tags like place=village/town/neighbourhood could
> be better choices?
>
> 在 2019年6月10日週一 20:18,Joseph Eisenberg  寫道:
>
>> I understand why refugee camps have been mapped with
>> amenity=social_facility - it's the closest existing tag, since
>> tourism=camp_site is clearly wrong and landuse=residential isn't quite
>> right.
>>
>> However, I don't think that large refugee camps are a perfect fit for
>> amenity=social_facility.
>>
>>  Most of these are group homes (eg orphanages), nursing homes (for the
>> elderly), hospices, assisted living facilities, homeless shelters,
>> outreach facilities for the homelss, etc - they provide services for
>> vulnerable groups in the community who have difficulty living on their
>> own.
>>
>> Refugee camps are closer to an informal residential settlement in many
>> developing countries, especially those that are larger or have been in
>> place for more than a few months (these are the ones most likely to be
>> mapped, I believe).
>>
>> I would encourage creating a proposal and a new tag specifically for
>> these sorts of places. There could perhaps be a distinction between
>> sites for people temporarily displaced locally (eg a camp for people
>> in the same town, after a flood) versus long-distance or international
>> migrants.
>>
>> On 6/10/19, Jan S  wrote:
>> >>
>> >> On 6/6/2019 5:27 PM, Graeme Fitzpatrick wrote:
>> >> >>* I'd suggest something like social_facility=temporary_housing.
>> >> *>>>* To me, social_facility doesn't quite cut it for "refugees".
>> >> Refugees
>> >> *>* strike me as people fleeing from war / massive natural disaster -
>> >> *>* social_facility comes across as small scale for homeless people /
>> >> *>* women's refuge sort of thing?
>> >> *>>Browsing through the values of social_facility:for, it's a lot more
>> >> diverse than just victims of abuse and poverty -- and
>> >> social_facility:for=refugee(s) has hundreds of uses. But you definitely
>> >> have a point about scale -- some of these camps house over a hundred
>> >> thousand people. That's on the scale of a small city -- a community,
>> not
>> >> a facility. So maybe place=refugee_camp is a better solution.
>> >>
>> >> J
>> >>
>> >>
>> > Picking up the subject again (and having noticed that the refugee camps
>> I
>> > know in my area are not tagged at all or at least very rudimentary
>> simply
>> > as amenity=social_facility), I've done another search on the internet
>> and
>> > have dug up this wiki page:
>> > https://wiki.openstreetmap.org/wiki/Refugee_Camp_Mapping
>> >
>> > It's been modified in 2018 for the last time, is quite rudimentary in
>> the
>> > description of the tags and values proposed and apparently oriented
>> mainly
>> > at makeshift camps in Africa or the Levante. It would be an effort to
>> bring
>> > some order into this and to make it more diverse (covering anything from
>> > spontaneous camps like the infamous Jungle in Calais or the already
>> > dismantled Idomeini camp, to permanent structures like asylum-seeker
>> > reception centres like this:
>> https://www.openstreetmap.org/way/390153052).
>> >
>> > I'll see if I can give it a try over the next weeks... or would that be
>> a
>> > task for a coordinated action?
>> >
>> > Best, Jan
>> >
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Complicated traffic light combinations

2019-06-07 Thread Dave Swarthout
There is a switch in the Show submenu of the Configure Map menu named OSM
Notes, Flick it on and the notes appear.

Dave

On Thu, Jun 6, 2019 at 10:52 PM Graeme Fitzpatrick 
wrote:

>
>
> On Fri, 7 Jun 2019 at 09:35, Dave Swarthout 
> wrote:
>
>> Actually, OSMand will display notes if you enable that feature. It's a
>> useful tool if you happen to be an OSM mapper.
>>
>
> I know you can see the Description & as well as various tag details, but
> how do you see Notes, thanks Dave?
>
> Thanks
>
> Graeme
>


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


Re: [Tagging] Complicated traffic light combinations

2019-06-06 Thread Dave Swarthout
Actually, OSMand will display notes if you enable that feature. It's a
useful tool if you happen to be an OSM mapper.

On Thu, Jun 6, 2019, 3:21 PM Warin <61sundow...@gmail.com> wrote:

> On 07/06/19 08:58, Andy Townsend wrote:
> > Hello,
> >
> > I've just mapped the traffic lights for a river crossing in
> > https://www.openstreetmap.org/changeset/71005300 (Elvington in
> > Yorkshire, England).
>
> >
> > Along with which direction the light points and what traffic it is
> > designed to control I've added the button info only as note tags at
> > this stage, but is there a better way of doing this?
>
> I don't think the 'note' key is used by renders, it is mean for
> communication between mappers.
> I would use the 'description' key as it may go on to maps so that may
> communicate to both mappers and map users.
>
> ___
> 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] tracktype=*;*;*

2019-05-09 Thread Dave Swarthout
I've occasionally seen mappers do this sort of thing intentionally. They
may know (or guess) that a particular way has more than one tracktype so
they simply add other values and separate them with a semicolon.

In such cases, if one cannot determine what the tracktype actually is, it
might be better to simply delete the entire tag. Unless you want to create
a changeset comment or contact the original mapper some other way.

On Thu, May 9, 2019 at 1:39 PM Florian Lohoff  wrote:

> On Thu, May 09, 2019 at 01:37:09PM -0600, brad wrote:
> > I'm seeing some tracks with multiple tracktype's like this:
> >
> > Way 364707088 [highway=track,  name=FR 514,
> tracktype=grade2;grade1;grade3]
> >
> > Is this generally accepted practice?
> > If so, why?
>
> IMHO does not make sense at all. Most likely somebody joined track
> segments without noticing the different grades and the editor
> joined it.
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Avoid using place=locality - find more specific tags instead

2019-04-16 Thread Dave Swarthout
Joseph wrote: We recently discussed place=locality, and I now believe this
tag
should be avoided, and perhaps deprecated."

I cannot agree.

In the case of Alaska, these named places are so remote that there is no
chance of me (or any other OSM mapper for that matter), ever doing a survey
to determine if those place names are in use by locals (trappers hunters,
canoeists) or not. I'm willing to change my tagging practices and ADD a new
and better designed tag reflecting the status of such places as can best be
determined from DigitalGlobe imagery but I am certainly not going to remove
the place=locality tag from them.

Warin's question is also relevant: what about place=island or place=islet?
FYI, Alaska currently has more than 500K nodes, 5646 ways and 186 relations
that represent either a place=island or place=islet and I'm still adding
more of them daily.

@MarKus: Regarding the tagging of islands or lake groups (clusters), I've
already begun to use the type=group tag and hope that someone will push
OSM-Carto to render such relations in the future.

On Tue, Apr 16, 2019 at 5:26 AM Markus  wrote:

> Hi
>
> On Tue, 16 Apr 2019 at 09:40, Joseph Eisenberg
>  wrote:
> >
> > Two of the examples need new tags created:
> > 3 lakes with a name: needs a new tag, perhaps natural=lake_group as a
> > multipolygon relation?
>
> There is already a proposed and used type=group relation for all kind
> of named groups:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation
>
> Regards
>
> Markus
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subtag for place=locality?

2019-04-15 Thread Dave Swarthout
> Can you give an example of one of these groups of named islands? If they
are close together and divided from other islands in the area, I would use
“archipelago”.

Here's a small group of only two islands that is definitely not an
archipelago, (as I understand that term, i.e., a "chain" of islands), and
have one name to describe both islands, the Leland Islands:

https://www.openstreetmap.org/way/20287799#map=14/58.6562/-135.9916

In this case, the original mapper didn't tag them as a multipolygon but
applied the place=island tag to the group as a node. I fact, he didn't even
bother to redraw the horrible PGS coastline to separate them into
individual islands.

Alaska has hundreds of these island groups.

On Mon, Apr 15, 2019 at 7:12 PM Warin <61sundow...@gmail.com> wrote:

> On 15/04/19 22:04, Joseph Eisenberg wrote:
> > That's an interesting example. Was the wheel put there as a landmark
> > or route marker, or just for fun?
>
> I don't know. I would assume as a landmark, to form a meeting place or a
> simple navigational aid. I don't even know if the present wheel is the
> original one.
>
> >
> > If the tag "place=locality" didn't exist, how would you tag this?
>
> I'd ask here, that is one of the things this group is good for.
>
> >
> > On 4/15/19, Warin <61sundow...@gmail.com> wrote:
> >> As an example of a locality that has never had a population
> >>
> >> https://www.openstreetmap.org/node/117041320
> >>
> >> /The Wheel/ (a car wheel - no tyre) was originally mounted on a tree by
> >> bushwalkers to mark the hub of the Blue Labyrinth's ridges.
> >>
> >> No one has ever lived there. Plenty of people go past, and it still a
> >> navigational feature.
> >>
> >> Fairly certain other localities have their stories to tell too.
> >>
> >>
> >> n 15/04/19 17:23, Warin wrote:
> >>>  From the original start of place=locality
> >>>
> >>> /All current place tags are for either populated areas, or for larger
> >>> areas of County sized or bigger. The place=locality tag is useful for
> >>> places that have a specific name, but do not necessarily have any
> >>> geographic feature or population centre that could be used to attach a
> >>> name tag to. /
> >>>
> >>> That to me suggest that places that locality can be a place that had
> >>> population, or places that did not have a population.
> >>>
> >>> But, I agree, that places that had a population would be better tagged
> >>> disused:/abandonded: place=hamlet/town/village/city
> >>>
> >>> I think that can go on the wiki for locality... under 'when not to
> >>> use' with the others there.
> >>> /
> >>> /
> >>> On 15/04/19 17:03, Martin Koppenhoefer wrote:
> >>>>
> >>>> sent from a phone
> >>>>
> >>>> On 15. Apr 2019, at 03:55, Joseph Eisenberg
> >>>> mailto:joseph.eisenb...@gmail.com>>
> wrote:
> >>>>
> >>>>> The most important value would be one for a locality that is a former
> >>>>> populated place but no longer has a population.
> >>>>
> >>>> I’ve always understood the population part of the locality tag
> >>>> definition as a way of saying the place name does not relate to a
> >>>> settlement or dwelling (but it doesn’t necessarily mean nobody is
> >>>> living around there, it means this name is not for an inhabited
> >>>> place). A generic tag for a place name/ toponym, to be used where no
> >>>> specific tag has yet been developed.
> >>>> (e.g. we have specific tags for toponyms that refer to mountain
> >>>> peaks, wetlands, lakes, islands, deserts, caves, settlements, etc. so
> >>>> we don’t use locality for them)
> >>>>
> >>>> I’m not sure I’d support locality subtags, for lots of things a main
> >>>> tag might be more fitting with the established tagging system, but it
> >>>> depends on the actually proposed values.
> >>>>
> >>>> For ghost towns (settlements) I’ve found a lot tagged as
> >>>> abandoned:place=hamlet/village/town
> >>>>
> >>>> https://taginfo.openstreetmap.org/keys/abandoned:place#values
> >>>>
> >>>> which seems inline with the rest of our tagging and is by far more
> >>>> frequent than any “ghost” variations.
> >>>>
> >>>> Cheers, Martin
> >>>>
> >>>>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subtag for place=locality?

2019-04-15 Thread Dave Swarthout
Joseph wrote:

There is a request to render place=archipelago now (Issue #3394); I
will look into it. It's only used 740 times, so it would help if more
people start using the tag. It would certainly be useful here in
Indonesia.
(BTW, I would recommend tagging archipelagos as simple nodes or as
multipolygon relations that include all of the islands. The wiki pages
suggests using a "type=cluster" relation, but this would be hard to
use)

The groups of islands I mentioned to are not archipelagos but merely
several islands sharing a name. The same logic applies to named groups of
lakes, for example, Three Lakes (
https://www.openstreetmap.org/relation/6714525), which I tagged as a
multipolygon. Lately, as a result of a discussion on this list, I've begun
using type=group for this sort of feature. OSM Carto doesn't render either
type=cluster or type=group multipolygons so many mappers will no doubt
continue to use type=multipolygon for them.

I'm willing to add a more specific tag for abandoned localities if we can
decide exactly which one of the several alternatives is the best candidate.
Of  course, 99% of such places in Alaska cannot be inspected in person to
decide if foundations and infrastructure exist because they are incredibly
remote. One has only satellite imagery with which to envision what's on the
ground. That's one reason I fall back to simply using the abandoned=yes tag.

On Mon, Apr 15, 2019 at 1:15 PM Kevin Kenny  wrote:

> On Mon, Apr 15, 2019 at 12:49 PM Volker Schmidt  wrote:
>
>> A side remark. Triggered by comparing abandoned palces with abandoned
>> railways (and smilar),
>> a ghost town with (some) buidlings still standing should be abandoned: ...
>> a ghost town without trace on the ground should be tagged with razed: ...
>> or dismantled: ... , but not with abandoned: ...
>> Example: https://www.openstreetmap.org/node/150938807
>> This is a former town, of which you do no see any trace on the ground any
>> more (apart from a few racks)
>>
>
> I thought that the commoner lifecycle prefix was 'demolished' ?
>
> I use 'disused' if the buildings are relatively well preserved and might
> be rehabbed, 'abandoned' if they're ruined, 'demolished' if the buildings
> are not standing but the settlement is still observable. Most of the ghost
> settlements that I've visited have clearly visible building foundations,
> stone walls separating fields, and road grades (which may be grown to
> trees, but are still obviously artificially graded) and are thus
> 'demolished.' (The ones on State land have likely had their buildings burnt
> to discourage squatters.) Theymay also have formations like tannery vats,
> mine shafts, mill races or cellar holes.
>
> https://www.flickr.com/photos/ke9tv/8690778427 is typical of 'demolished'
> - the road has mature trees standing in it and is not passable for any
> distance by anything on wheels, but the fact that the area was once a
> settlement is obvious. (I've found the remains of a mill, a tannery, and a
> forge in that former settlement, but have not been able to discover even
> its name.)
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Subtag for place=locality?

2019-04-15 Thread Dave Swarthout
Yes, that's one locality for every four persons in the state, an
interesting statistic. Many of these are indeed GNIS imports and some of
those are also tagged with
"gnis:Class": "Populated Place"
which is often inaccurate. I'm certain the gold rushes Alaska experienced
during the past 150 years contributed to many of these abandoned "Populated
Places". Some of them were quite large (several thousands of inhabitants)
but as gold became scarcer and more difficult to extract from the ground,
were abandoned. I typically add only the abandoned=yes tag on any feature
that either appears to be or is known to be deserted.

I tag a typical abandoned place=locality with only the name, the source,
the abandoned=yes tag and occasionally with a description if I think it's
interesting enough. Some of this information is found in a very useful
public domain publication, the Dictionary of Alaska Place Names, which
contains a wealth of information about such localities. I use it constantly
in my Alaska mapping work.

I don't have a good guess as to the validity of the existing localities nor
can I estimate how many might be actually natural features like
mountain_range or valleys but there are definitely plenty of those.
Sometimes people tag groups of islands with the locality tag as opposed to
creating a relation of some sort. It's a much simpler solution and provides
the mapper assurance that it will render. I don't use that approach because
I don't think it's correct.

On Mon, Apr 15, 2019 at 7:29 AM Joseph Eisenberg 
wrote:

> > There are countless old settlements, gold mining camps, road building
> > camps, airstrips, and even Native American villages scattered around our
> > immense state. Most are indeed abandoned and sometimes I add
> abandoned=yes
> > to the tags, especially if there is no longer any sign of habitation
> > visible on satellite imagery.
>
> Thanks Dave,
>
> What tags do you usually add for a former settlement, or for an
> abandoned gold mining or road building camp?
>
> Are you using just place=locality with abandoned=yes, or is the tag
> "abandoned" always referring to a more specific feature, like
> historic=mine or aeroway=aerodrome?
>
> > An Overpass query returned almost 190,000 nodes along with 417 ways and
> 46
> > relations tagged as place=locality, that are located in Alaska.
>
> There are 750k people in Alaska, so there's more than one locality for
> every 4 people!
>
> Clearly most of these were imported, probably from GNIS(?).
>
> In your experience, how many of the imported locality nodes seem to be
> correctly tagged?
>
> Could many of them be something more specific, like natural=valley,
> natural=ridge, natural=peak, natural=bay, railway=junction,
> highway=junction, place=island, etc?
>
> Joseph
>


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


Re: [Tagging] Subtag for place=locality?

2019-04-15 Thread Dave Swarthout
As a mapper in Alaska, I rely heavily upon the USGS Topographic map layer
to provide names for geographic features. Alaska has many places that
perfectly fit the definition Warin provided from the Wiki:

*All current place tags are for either populated areas, or for larger areas
of County sized or bigger. The place=locality tag is useful for places that
have a specific name, but do not necessarily have any geographic feature or
population centre that could be used to attach a name tag to. *

Given Alaska's gold mining history, I encounter such places all the time.
There are countless old settlements, gold mining camps, road building
camps, airstrips, and even Native American villages scattered around our
immense state. Most are indeed abandoned and sometimes I add abandoned=yes
to the tags, especially if there is no longer any sign of habitation
visible on satellite imagery.

An Overpass query returned almost 190,000 nodes along with 417 ways and 46
relations tagged as place=locality, that are located in Alaska.

AlaskaDave

On Mon, Apr 15, 2019 at 3:34 AM Warin <61sundow...@gmail.com> wrote:

> As an example of a locality that has never had a population
>
> https://www.openstreetmap.org/node/117041320
>
> *The Wheel* (a car wheel - no tyre) was originally mounted on a tree by
> bushwalkers to mark the hub of the Blue Labyrinth's ridges.
>
> No one has ever lived there. Plenty of people go past, and it still a
> navigational feature.
>
> Fairly certain other localities have their stories to tell too.
>
>
> n 15/04/19 17:23, Warin wrote:
>
> From the original start of place=locality
>
> *All current place tags are for either populated areas, or for larger
> areas of County sized or bigger. The place=locality tag is useful for
> places that have a specific name, but do not necessarily have any
> geographic feature or population centre that could be used to attach a name
> tag to. *
>
> That to me suggest that places that locality can be a place that had
> population, or places that did not have a population.
>
> But, I agree, that places that had a population would be better tagged
> disused:/abandonded: place=hamlet/town/village/city
>
> I think that can go on the wiki for locality... under 'when not to use'
> with the others there.
>
>
> On 15/04/19 17:03, Martin Koppenhoefer wrote:
>
>
>
> sent from a phone
>
> On 15. Apr 2019, at 03:55, Joseph Eisenberg 
> wrote:
>
> The most important value would be one for a locality that is a former
> populated place but no longer has a population.
>
>
>
> I’ve always understood the population part of the locality tag definition
> as a way of saying the place name does not relate to a settlement or
> dwelling (but it doesn’t necessarily mean nobody is living around there, it
> means this name is not for an inhabited place). A generic tag for a place
> name/ toponym, to be used where no specific tag has yet been developed.
> (e.g. we have specific tags for toponyms that refer to mountain peaks,
> wetlands, lakes, islands, deserts, caves, settlements, etc. so we don’t use
> locality for them)
>
> I’m not sure I’d support locality subtags, for lots of things a main tag
> might be more fitting with the established tagging system, but it depends
> on the actually proposed values.
>
> For ghost towns (settlements) I’ve found a lot tagged as
> abandoned:place=hamlet/village/town
>
> https://taginfo.openstreetmap.org/keys/abandoned:place#values
>
> which seems inline with the rest of our tagging and is by far more
> frequent than any “ghost” variations.
>
> Cheers, Martin
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread Dave Swarthout
>From Wikipedia:

Jersey barriers were developed in the 1950s, beginning in the U.S. state of New
Jersey <https://en.wikipedia.org/wiki/New_Jersey> as separators between
lanes of a highway. Over time, they grew taller (as their effectiveness was
demonstrated) and became more modular (as their usefulness as temporary
barriers became apparent). Taller barriers have the added advantage of
blocking most oncoming headlights.

So it has an American heritage. Seeing as it's a widely used term in OSM,
I'd say it's a small payback for forcing us to use the English spelling of
things like centre and neighbourhood.  LOL

Dave

On Sun, Apr 14, 2019 at 3:57 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 14. Apr 2019, at 04:43, Joseph Eisenberg 
> wrote:
>
> I want to know so that the wiki page can be edited to show the correct
> status: approved vs in use.
>
>
>
> I went back into the archives and it seems it was included and approved in
> my more barrier types proposal 2011:
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/New_barrier_types=684703
> Not sure where the tag name for jersey barriers came from, probably from
> tagging ml discussion (it is not a word I have in my vocabulary)
>
> Cheers, Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-02-26 Thread Dave Swarthout
Whoa,

What happened to the original topic of this thread? We were trying to come
up with a system of determining whether a highway is classified or
residential. Now we're talking about traffic density and traffic speed, and
some sort of numerical classification scheme for motorways, etc.

What's going on?

Signed,
Confused in Thailand. (AlaskaDave)

On Tue, Feb 26, 2019 at 12:28 PM Warin <61sundow...@gmail.com> wrote:

> On 26/02/19 10:59, Sergio Manzi wrote:
>
> +1 here too, and a little bit of the same concerns expressed by Andy (
> https://xkcd.com/927/)
>
> BTW, in the Italian mailing list there is currently a thread discussing if
> and how we should tag highways according to what are the official
> categories in the Italian Traffic Code (*Codice della Strada*) are.
>
> There the concern is most about how to tag an official classification 
> (*something
> that is implicit in the tag value in UK, if I'm not mistaken*) instead of
> a "descriptive classification".
>
> Is ther a UK page that has these official classifications? They maybe of
> use to fit others classifications to.
>
> But other concerns are emerging too (*at least in my head!*), like the
> administrative responsibility under which a given road falls (*state,
> region, province, municipality, private*)
>
> Use operator=* ???
>
> and ad-hoc values as input for the router (*s**peed limits, traffic
> density, etc.*
>
>
> Rather than the density.. traffic speed could be more usefull? Example
> traffic_speed=20 @ 6:00-19:00 Mon-Fri , traffic_speed=15 @ 9:00-17:00
> Sat-Sun (yes, busier on the weekends!)
> *. *If no traffic_speed then routers use the max_speed..
>
> * *OR* a comprehensive "preference"value  *).
>
> Keep on going!
>
> Cheers,
>
> Sergio
>
>
>
> On 2019-02-25 22:10, Andy Townsend wrote:
>
> On 24/02/2019 14:25, djakk djakk wrote:
>
>
> I think we should decorrelate the attributes of a road : its
> administrative class, its importance in the road network (at least 5
> levels), its physical characteristics (motorway-like, two large lanes,
> link=yes ...), possibly its traffic characteristics.
>
> So we can tag a secondary motorway or a primary road through a residential
> area or an official motorway with pedestrians actually walking on it.
>
> So that we’ll unify osm road classification through the world (remember
> the highway=trunk issue ;-))
>
>
> It's a noble aim, but unfortunately the first thing that springs to mind
> is https://xkcd.com/927/ :)
>
> However, some of the stuff on
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
> I definitely agree with, and in some cases actually do do myself - like
> trying to capture the physical characteristics wherever relevant.
>
> Best Regards,
>
> Andy
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-23 Thread Dave Swarthout
 > Most residential roads now are tagged as unclassified, I just
> have to list them, determine if the default fits, then retag them as
> highway=road.


Andy replied: "Tagging roads that you know well as "highway=road" sounds
like a mistake"
+1

I agree. Tagging highway=road means: I don't have any idea what sort of
road this is (but I can see it on the satellite imagery). I hope these
roads are never considered to be routable. The mkgmap program's standard
style defaults to that conclusion, IIRC. I think of it more or less as a
place holder, a way that needs a closer look.

Others have stated that they think of an unclassified way as something
having more significance than a residential way while still being less
important than a tertiary highway. (By the way, in Thailand,
coincidentally, a tertiary highway is the lowest class of highway that
carries a ref.). And that has been my assumption right along.

Where do we stand on that question? Is that the correct question to b
asking?

On Sat, Feb 23, 2019 at 8:16 PM Peter Elderson  wrote:

> I was thinking further about the idea that came up here: deduct road type
> from the landuse=residential. It's different than current usage, and I dont
> think it is feasable.
>
>
> Vr gr Peter Elderson
>
>
> Op za 23 feb. 2019 om 14:02 schreef Andy Townsend :
>
>> On 23/02/2019 11:36, Peter Elderson wrote:
>> > The tagging scheme should have a clear intention to facilitate
>> > rendering and routing. Then renderers and routers know what there is,
>> > so they can decide how to handle it.
>>
>>
>> To be clear, "highway=road" is used when it _isn't_ clear what the
>> classification should be.
>>
>>
>> >
>> > If residential area means that road class is highway=residential
>> > unless taggted otherwise, that should be made very clear.
>>
>>
>> No, it doesn't.
>>
>>
>> > At the moment, I don't think it is clear, and road tagging in
>> > residential areas in Nederland certainly does not follow this principle.
>>
>>
>> That's good!
>>
>>
>> > If the scheme is adopted and very clearly documented, I could adjust
>> > the residential road tagging in my village (pop 25.000) in a couple of
>> > hours. Most residential roads now are tagged as unclassified, I just
>> > have to list them, determine if the default fits, then retag them as
>> > highway=road.
>>
>>
>> Tagging roads that you know well as "highway=road" sounds like a mistake.
>>
>>
>> >
>> > The problem with such a default of course is: if the area is altered,
>> > roads may (and will) unintentionally change because suddenly the
>> > default applies or no longer applies. Also, wouldn't renderers and
>> > routers will have to deal with roads crossing the border of a
>> > residential area suddenly changing types, without a node to tie the
>> > action to?
>>
>>
>> I think there's been a miscommunication here - there is no such
>> default.  It's certainly not your fault - English as used to describe
>> roads in the UK is the problem, with "unclassified" meaning a particular
>> explicit classification.
>>
>> 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
>


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Dave Swarthout
 the German Forum by years - I was
>> astonished
>> finding statements in the German article for unclassified which do not
>> match
>> (but oppose) the English versions which i typically use and prefer.
>>
>> Its not the first time i find the German articles to contain a hidden
>> agenda bei a minority or single mappers trying to steer the community.
>>
>> Flo
>> --
>> Florian Lohoff f...@zz.de
>> UTF-8 Test: The  ran after a , but the  ran away
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Dave Swarthout
While I agree with Georg's assessment in general, I want to point out that
in Thailand I often do downgrade an unclassified highway when it enters a
residential area because the differences between the two ways can be
significant. You will be driving along on a nice, smooth, two-lane highway
and when it enters a hamlet it might transform into a very narrow one-lane
street lined with houses. My intent when tagging is to indicate that the
highway when it passes through a town is not in any way a high-speed
thorofare. I was under the impression that "downgrading" it to residential
would help routers evaluate various alternative routes better.

So, yes, I do perceive an unclassified highway to be more significant than
a residential highway in several ways, speed, convenience, and also safety.

On Wed, Feb 20, 2019 at 5:05 PM Georg Feddern  wrote:

> Am 20.02.2019 um 10:22 schrieb Florian Lohoff:
>
> So for me retagging residential to unclassified is broken under the
> assumption that unclassified is something "better" than residential.
>
> It is even more broken when there is residential usage in which case
> unclassified is inappropriate.
>
> While discussing i found that there was some modification to the German
> version of unclassified not saying that unclassified is something
> "better" but suggesting that an unclassified should be dragged into
> city limits until the next higher class street. This lets user
> assume that unclassified is some higher priority than residential.
>
>
> I was treating those streets identical for the last 10+ years and only
> the city limits gave the indication whether to use unclassified or
> residential.
>
> Am i wrong with that usage?
>
>
> Even the english wiki says:
> "The tag highway <https://wiki.openstreetmap.org/wiki/Key:highway>=
> unclassified is used for minor public roads typically at the lowest level
> of the interconnecting grid network."
>
> As part of the interconnecting grid network it should connect to at least
> unclassified or higher roads - unless it is a dead end settlement.
> Tagging a through connecting road only because it is inside a city limit
> as residential makes no sense.
> And usually a connecting road from outside a city limit has at least a bit
> more traffic as an inner-city-only residential.
> So the conclusion an unclassified has a bit higher priority than a
> residential is not far from reality.
>
> Otherwise there is often the problem to tag the main access roads inside a
> bigger residential area.
> The practice to tag those as unclassified for a bit higher priority may
> not be optimal - but suitable.
>
> This discussion - and usage - is some years old now - and I thought you
> had at least knowledge of it from the german forum.
>
> Georg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Dave Swarthout
That is a most interesting question.

Here in Thailand I interpret their differences, perhaps incorrectly, as
residential meaning a way with houses on it, while an unclassified highway
is one step below a tertiary and therefore one step above a residential. It
does not have many houses (residences) and is often a connector between
minor towns or villages. Which is more important? In my opinion, an
unclassified highway would offer faster transit times than a residential so
I'm surprised to learn that routers rate them the same.

It's a tricky distinction. I hope this thread will help clarify that
distinction.

On Wed, Feb 20, 2019 at 4:24 PM Florian Lohoff  wrote:

>
> Hi,
> i found some changesets downgrading streets to unclassified. After some
> discussions the mapper were under the impression that unclassified is
> something higher priority than residential.
>
> From my long tagging practice in OSM unclassified and residential are
> identical in respect to priority. (And e.g. OSRM treats them equal)
> The first is used as a connecting road off city limits. The latter is
> used for the lowest class roads within city boundarys (Where there is
> residential usage)
>
> So for me retagging residential to unclassified is broken under the
> assumption that unclassified is something "better" than residential.
>
> It is even more broken when there is residential usage in which case
> unclassified is inappropriate.
>
> While discussing i found that there was some modification to the German
> version of unclassified not saying that unclassified is something
> "better" but suggesting that an unclassified should be dragged into
> city limits until the next higher class street. This lets user
> assume that unclassified is some higher priority than residential.
>
>
> I was treating those streets identical for the last 10+ years and only
> the city limits gave the indication whether to use unclassified or
> residential.
>
> Am i wrong with that usage?
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels

2019-02-19 Thread Dave Swarthout
Sure, it works for me. I've only mapped one canoe route so far and, based
on this thread, have already added the waterway=fairway tag to all the
previously untagged ways in the route.

On Wed, Feb 20, 2019 at 4:12 AM Graeme Fitzpatrick 
wrote:

>
> On Wed, 20 Feb 2019 at 01:30, Fernando Trebien 
> wrote:
>
>>
>> I've applied the two fairway tags to a major fairway on a lake [1][2],
>> please let me know if you think anything should be mapped differently.
>>
>
> At first glance, it seems to work, thanks Fernando.
>
> Dave / Kenny - would it also work for your canoeing purposes?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels

2019-02-15 Thread Dave Swarthout
"Direction of flow" isn't quite right for a canoe route that crosses a
lake. Also, it would be rare but not impossible, for a canoe route to move
against the flow when traversing a stream. But, unless someone can think of
a better way to word this, I'm okay with what's there. Such refinements can
be made in the route relation perhaps. Direction "forward" or "backward"
come to mind although I've never used them for a canoe route myself. The
only canoe route I've ever mapped can be traveled in either direction if
one wishes.

Dave

On Sat, Feb 16, 2019 at 5:49 AM Graeme Fitzpatrick 
wrote:

>
> On Sat, 16 Feb 2019 at 00:12, Fernando Trebien 
> wrote:
>
>>
>> For well-known partially unmarked shipping routes, I think there would
>> be no problem lifting the requirement of navigation marks. But I'm not
>> sure if this applies to canoe routes, which are usually not marked.
>> I'm neither a sailor nor a native English speaker, so I think I'd
>> better leave this decision to those experienced in marine navigation.
>>
>
> Going off my own knowledge of small craft, along with Dave & Kevin's canoe
> experience :-), I've edited the page as discussed above
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway
>
> Are we all happy with that?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels

2019-02-13 Thread Dave Swarthout
>So waterway=fairway applies anywhere, but if it's a "major" (marked)
channel, then it also gets seamark:type
<https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway
<https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>.

>Does that work?

Yes, indeed. That would work very well IMO.

As Kevin pointed out, I have used route=canoe in a relation but without
adding a tag to the ways, most maps either cannot, or choose not to, render
them so you're left with footways that end on both sides of a lake (the
portages) with no connection between them. Solving this problem is the
reason I made my suggestion.

Dave

On Thu, Feb 14, 2019 at 4:45 AM Graeme Fitzpatrick 
wrote:

>
> On Thu, 14 Feb 2019 at 04:05, Fernando Trebien 
> wrote:
>
>> On Tue, Feb 12, 2019 at 10:49 AM Dave Swarthout 
>> wrote:
>> >
>> > The seamark definition in the supplied link is very general. I cannot
>> see how anyone could misinterpret this use of either waterway=fairway or
>> seamark:type=fairway unless they are specialists, in which case I'm sure a
>> response will be forthcoming. Regardless, I agree that the conflict note
>> should be removed.
>>
>> I've updated the wiki, please have a look and let me know if you
>> disagree. [1]
>>
>> > but I also hope we can somehow make it applicable to canoe routes as
>> well.
>>
>> From the definition of waterway=fairway, it can be used for the
>> members of canoe routes as long as they are artificial and marked by
>> buoys. I expect this to be rare though.
>>
>
> I'd suggest a slight change of wording to clarify it even further:
>
> "A navigable route in a lake or sea. If the navigable area is marked by
> buoys or navigation markers, it should also be mapped with seamark:type
> <https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway
> <https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>."
>
> So waterway=fairway applies anywhere, but if it's a "major" (marked)
> channel, then it also gets seamark:type
> <https://wiki.openstreetmap.org/wiki/Key:seamark:type>=fairway
> <https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dfairway>.
>
> Does that work?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels

2019-02-13 Thread Dave Swarthout
Certainly, the portion of a canoe trail that crosses a lake or pond is
indefinite. I assume also that any part that travels along a river would
tend to follow its centerline. Such portions of a route can also be tagged
as indefinite=yes but what do people think about the canoe route as
waterway=fairway idea?

On Tue, Feb 12, 2019 at 9:12 PM Kevin Kenny  wrote:

> On Tue, Feb 12, 2019 at 7:49 AM Dave Swarthout 
> wrote:
> >
> > The seamark definition in the supplied link is very general. I cannot
> see how anyone could misinterpret this use of either waterway=fairway or
> seamark:type=fairway unless they are specialists, in which case I'm sure a
> response will be forthcoming. Regardless, I agree that the conflict note
> should be removed.
> >
> > I would love to see the tag waterway=fairway accepted but I also hope we
> can somehow make it applicable to canoe routes as well. A canoe route is
> not as well defined as a shipping channel, for example, but it does have a
> preferred path and well-defined put-in and take-out points. It does not,
> however, typically have marker buoys or lights. If we removed that
> requirement or made it optional, that would save a lot of energy in trying
> to get a modification approved later. So, instead of saying: " A navigable
> route in a lake or sea marked by buoys", it might say, "A navigable route
> in a lake or sea usually marked by buoys. In the case of a fairway
> describing a canoe route, there would typically be no buoys."
> >
> > Opinions? I think the fairway tag fits so well it might be appropriated
> for use on such routes anyway.
>
> We recently were also discussing the idea of having an
> 'indefinite=yes' tag to mark the indefiniite portion of the closed set
> of ways that encloses a peninsula, isthmus, bay, strait, or similar
> form.  Is the on-water portion of a canoe route an indefinite way?  (I
> would imagine that portages are usually quite definite, but I've
> carried on a few where the mud was only slightly too thick to pole or
> paddle through.)
>
> It appears that the nearest thing on the seamark schema is
> https://wiki.openstreetmap.org/wiki/Seamarks/Leading_Lines - and it
> states specifically that the centreline of a fairway should not be
> mapped.  In the nautical world, there are usually well-defined and
> charted limits of safe navigation, so that a fairway will be bounded
> by clearing lines. In the canoe world, it is for the boatman to decide
> where safe water is at the lake's current height or the river's
> current rate of flow.
>
> I'd imagine that a canoe route that follows a river would ordinarily
> share the river "centerline" or Thalweg with the 'river' object,
> except for where it comes ashore to portage or is plotted in a
> specific track around obstacles. On a paddle-and-portage from lake to
> lake, the waterway portions are quite indefinite indeed!
>


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


Re: [Tagging] Fwd: [tagging] Canoe route / nautical channels

2019-02-12 Thread Dave Swarthout
The seamark definition in the supplied link is very general. I cannot see
how anyone could misinterpret this use of either waterway=fairway or
seamark:type=fairway unless they are specialists, in which case I'm sure a
response will be forthcoming. Regardless, I agree that the conflict note
should be removed.

I would love to see the tag waterway=fairway accepted but I also hope we
can somehow make it applicable to canoe routes as well. A canoe route is
not as well defined as a shipping channel, for example, but it does have a
preferred path and well-defined put-in and take-out points. It does not,
however, typically have marker buoys or lights. If we removed that
requirement or made it optional, that would save a lot of energy in trying
to get a modification approved later. So, instead of saying: " A navigable
route in a lake or sea marked by buoys", it might say, "A navigable route
in a lake or sea usually marked by buoys. In the case of a fairway
describing a canoe route, there would typically be no buoys."

Opinions? I think the fairway tag fits so well it might be appropriated for
use on such routes anyway.

Dave



On Tue, Feb 12, 2019 at 7:00 PM Fernando Trebien 
wrote:

> Sorry to bring this back so much time later. I just want to confirm a
> detail.
>
> On Tue, Jul 3, 2018 at 8:34 AM Multi Modaal  wrote:
> > > I could go along with the extension of the definition of
> waterway=canal to
> > > cover also navigation channels in larger bodies of water, if this
> solution
> > > is accepted as a result of  voting process on a formal proposal.
> Personally
> > > I prefer a new tag for nautical or navigation channels.
> > I agree that a new tag (waterway=lake seems fine to me) would be better,
> but until that is formally proposed and widely accepted by data users I see
> no advantage in banning current practice which is also in concordance with
> the wiki for instance waterway=fairway  (fairway on a lake is added as an
> addition to waterway=canal/river )
>
> Since 27 March 2018, the wiki [1] says that waterway=fairway is
> "questioned and conflicts with seamark:type=fairway", but I think this
> is not correct. The wiki also states that waterway=fairway should be
> used on ways and that seamark:type=fairway should be used on closed
> ways, so I believe that a complete description includes both a
> navigable area and a line through it (which is typically a requirement
> for routing).
>
> If you agree, I think the conflict note should be removed from the wiki.
>
> Regards,
>
> [1]
> https://wiki.openstreetmap.org/wiki/Template:Generic:Map_Features:waterway
> [2] https://wiki.openstreetmap.org/wiki/Seamarks/Seamark_Objects
>
> --
> Fernando Trebien
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] motorcycle:scale

2019-02-07 Thread Dave Swarthout
@Paul

Agreed, and you still must produce a new Wiki page regardless. That's the
process most people, including me, try to avoid. Hell, even if we all
agreed that a new "category" for Wiki tagging-related pages (which is what
I presume we're talking about here) is a good idea, it's a long way from
that to reaching consensus.

Or am I missing your point totally?

On Thu, Feb 7, 2019 at 8:03 PM Paul Allen  wrote:

> On Thu, 7 Feb 2019 at 12:12, Dave Swarthout 
> wrote:
>
>>
>> I like the idea of the "informal" category but isn't that more or less
>> the same as "proposed"?
>>
>
> The proposal process is formal.  It's documented, people scream at you if
> you don't do it exactly
> right, etc.  Doesn't matter if the tag gets approved or not, the proposal
> process is formal.
> "Informal" means "make it up as you need it."  Or, as I said, ad hoc.
>
> --
> Paul
>
>

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


Re: [Tagging] motorcycle:scale

2019-02-07 Thread Dave Swarthout
" Maybe I should eschew obfuscation."

+1

LOL. We have enough problems with English here - no need to add Latin to
our already strained conversations.

I like the idea of the "informal" category but isn't that more or less the
same as "proposed"?

IMO, the main difficulty with keeping the Wiki updated is that editing it
is tricky. I see grammatical errors all the time, for example, but don't
want to get into a big conversation about any changes I make so I often
just ignore them. And adding a proposal is simply too much work when I have
so many other things I want to add to the map. I guess that's due to my own
shortcomings. But then again, I imagine that issue keeps many mappers
besides me from altering or adding things to it.

Dave

On Thu, Feb 7, 2019 at 6:11 PM Paul Allen  wrote:

> On Thu, 7 Feb 2019 at 10:52, Markus  wrote:
>
>>
>> Perhaps it would help though, if the status on the wiki page were more
>> clear and prominent – maybe a different page colour and a status of
>> 'informal' instead of 'in use' for those non-standard tags.
>>
>
> Just to get into the spirit of things. };-)
>
> How about "impromptu" or "extempore" or "ad hoc" instead of informal?
> When more widely
> used we could change the status to "de facto."
>
> Maybe I should eschew obfuscation.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-02-01 Thread Dave Swarthout
I like the proposal, Markus, but am confused by this statement:

natural=peninsula is not intended for tagging coastal areas or coastal
strips.

What does it mean? Can you word it differently perhaps?

Thanks for your efforts on this proposal.

On Sat, Feb 2, 2019 at 12:10 AM Markus  wrote:

> Hello,
>
> Are there still any objections to or comments on this proposal?
> Otherwise, i'd like to start voting in two weeks (if possible together
> with the related proposal natural=isthmus).
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dpeninsula
>
> Thank you all for your suggestions for improvement!
>
> Regards
>
> Markus
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Drain vs ditch

2019-01-16 Thread Dave Swarthout
Sounds good, Eugene. I like those descriptions.

On Wed, Jan 16, 2019 at 4:41 PM Eugene Podshivalov 
wrote:

> =drain
>> suggested: Use waterway
>> <https://wiki.openstreetmap.org/wiki/Key:waterway>=drain for artificial
>> waterways <https://wiki.openstreetmap.org/wiki/Waterways>, typically
>> lined with concrete or similar, usually used to carry water for drainage
>> or irrigation purposes.
>>
>> =ditch
>> suggested: Use waterway
>> <https://wiki.openstreetmap.org/wiki/Key:waterway>=ditch for simple
>> narrow artificial waterways
>> <https://wiki.openstreetmap.org/wiki/Waterways>, typically unlined,
>> usually used to remove storm-water or similar from nearby land. Ditches
>> are usually straight (as opposed to natural streams). They may contain
>> little water or even be dry most of the year – to mark this intermittent
>> <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used.
>>
>
> I don't know if that was done on purpose of by mistake but these
> definitions are mixed up a bit. It is ditches that are used for irrigation,
> not drains.
> I would suggest to define them as follows.
>
> canal - large man-made open flow (free flow vs pipe flow) waterways used
> to carry useful water for transportation, hydro-power generation,
> irrigation or land drainage purposes. consider using waterway=ditch for
> small irrigation or land drainage channels. consider using waterway=drain
> for small lined superflous liquid drainage channels.
>
> drain - small artificial free flow waterways usually lined with concrete
> or similar used for carrying away superflous liquid like rain water or
> industrial discharge. consider using waterway=ditch for unlined channels
> used to drain nearby land. consider using waterway=canal for large unlined
> land drainage channels.
>
> ditch - small artificial free flow unlined waterways used for irrigating
> or draining land as well as for deviding land. consider using
> waterway=canal for large irrigation or land drainage channels. consider
> using waterway=drain for lined superflous liquid drainage channels.
>
> No need to introduce any new tags.
>
> Eugene
>
> ср, 16 янв. 2019 г. в 05:12, Warin <61sundow...@gmail.com>:
>
>> On 16/01/19 11:53, Graeme Fitzpatrick wrote:
>>
>>
>> On Wed, 16 Jan 2019 at 10:28, Dave Swarthout 
>> wrote:
>>
>>>
>>> Although the 1st definition sort of agrees with your usage, the common
>>> definition in the U.S. is closer to the other two. There are several other
>>> definitions given but most of them are similar to those two. So it will be
>>> a bit confusing to use here in the U.S.
>>>
>>
>> Now why does that amaze me! :-)
>>
>> irrigation channel: a passage
>> <https://www.macmillandictionary.com/dictionary/british/passage> dug
>> <https://www.macmillandictionary.com/dictionary/british/dug> in the
>> ground <https://www.macmillandictionary.com/dictionary/british/ground_1>
>>  and used <https://www.macmillandictionary.com/dictionary/british/used>
>>  for bringing
>> <https://www.macmillandictionary.com/dictionary/british/bring> water
>> <https://www.macmillandictionary.com/dictionary/british/water_1> to land
>> <https://www.macmillandictionary.com/dictionary/british/land_1> in order
>> <https://www.macmillandictionary.com/dictionary/british/order_1> to make
>> <https://www.macmillandictionary.com/dictionary/british/make_1> plants
>> <https://www.macmillandictionary.com/dictionary/british/plant_1> grow
>> <https://www.macmillandictionary.com/dictionary/british/grow>
>>
>>
>>
>> OSM gives a distinction between river and stream.
>> There should be a similar distinction between 'drain' etc.
>> It should not be base on the flow of water as that could be hard to
>> determine - especially if the water is off when mapping.
>>
>> For example, 'a drain can be easily stepped over'?
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Trailhead tagging

2019-01-16 Thread Dave Swarthout
Your proposal looks good. I would vote "yes" on it.

On Wed, Jan 16, 2019 at 4:28 PM Peter Elderson  wrote:

> I made a concept wiki page:
> https://wiki.openstreetmap.org/wiki/Tag:trailhead
> I think it fits the outcome of this discussion. If not, feel free to
> comment.
>
> I don't want to change the earlier proposal, it is a step further than my
> concept tagging page which just documents existing practice.
>
>
> Vr gr Peter Elderson
>
>
> Op di 15 jan. 2019 om 00:41 schreef Dave Swarthout <
> daveswarth...@gmail.com>:
>
>> Kevin said:
>> I'm therefore going to stick with 'designated or customary place to
>> begin or end a trip on a trail.'
>>
>> Me too. I've mapped many such trailheads in Alaska and almost everybody I
>> know would recognize the term trailhead as meaning a point of access to a
>> path or trail. It's fine to add other details, like parking, toilets,
>> registration facilities, etc. separately. I haven't followed this thread
>> carefully, so can't speak to the TOP situation fully but I do know a
>> trailhead when I see it on a map or otherwise.
>>
>> Dave
>>
>> On Tue, Jan 15, 2019 at 6:16 AM Graeme Fitzpatrick 
>> wrote:
>>
>>>
>>> On Tue, 15 Jan 2019 at 09:04, Tod Fitch  wrote:
>>>
>>>>
>>>> Guess: Someone found it on the trail and figured it would be easier for
>>>> the person missing it to find it hanging from the sign than some place
>>>> along miles of trail.
>>>>
>>>
>>> Bit of a problem when you've got to walk back the 65 klm looking for it!
>>>
>>> Thanks
>>>
>>> Graeme
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

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


Re: [Tagging] Creating shop=caravan

2019-01-16 Thread Dave Swarthout
I appreciate your efforts on this, Graeme, believe me. However, seeing as
motorhome and recreational_vehicle are so similar, I would use motorhome as
a top-level tag with RVs being a special type of motorhome and have a
separate shop=mobile_home page. Then all bases are covered. Mobile_home
covers the odd case of the wheeled structure that is usually installed
semi-permanently in a trailer park (see proposed feature for this
https://wiki.openstreetmap.org/wiki/Proposed_features/Trailer_Park) or
similar neighborhood. Note that on that page for anenity=trailer_park, they
state: "As an amenity, this makes sense for truly mobile homes (aka
recreational vehicles aka caravans". However, that definition should be
changed to match our new definitions should you proceed along the path
we're discussing. Confusion in terminology rears its ugly head on that page
as well.  LOL

Also, if this split was to be adopted, how best then to differentiate a
recreational_vehicle (powered, suitable for camping, but not a large
motorhome) from the larger class of motorhomes? Good question. Maybe we
could just assume that RVs are also motorhomes and let it go at that.

On Wed, Jan 16, 2019 at 8:55 AM Graeme Fitzpatrick 
wrote:

> OK, so after taking in everybody's thoughts & comments (thanks! :-)), I've
> come up with:
>
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcaravan
>
> https://wiki.openstreetmap.org/wiki/Shop%3Dmotorhome
>
> https://wiki.openstreetmap.org/wiki/Shop%3Drecreational_vehicle
>
> How's that?
>
> As always, all comments welcomed!
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Drain vs ditch

2019-01-15 Thread Dave Swarthout
Graeme, I like the definitions you posted but why add "channel" to the
list? When I think of a channel I think of a shipping lane or a dredged
channel where ships with deeper drafts can pass through shallow water. From
my online dictionary:

1. the bed of a stream, river, or other waterway.
2. Nautical: a navigable route between two bodies of water.
3. the deeper part of a waterway.

Although the 1st definition sort of agrees with your usage, the common
definition in the U.S. is closer to the other two. There are several other
definitions given but most of them are similar to those two. So it will be
a bit confusing to use here in the U.S. but it's not a huge problem if it
appears in the Wiki list of definitions.

On Wed, Jan 16, 2019 at 7:08 AM Graeme Fitzpatrick 
wrote:

>
>
> On Tue, 15 Jan 2019 at 23:28, Eugene Podshivalov 
> wrote:
>
>> The confusion is mainly in the difference between irrigation canals vs
>> irrigation ditches and drainage diches vs drains.
>>
>> In practice wide irrigation channels are called canals whereas small ones
>> are called diches and people tend to tag them as such.
>> This tendency is enforced by the fact that canals and diches are rendered
>> in difference size.
>> IMO there is no problem here, we should just document this usage properly.
>>
>> Drainage diches and drains are confused simply because of their identical
>> definition on the waterway wiki page
>> https://wiki.openstreetmap.org/wiki/Key:waterway
>> drain - An artificial free flow waterway used for carrying superfluous
>> water like storm water...
>> ditch - An small artificial free flow waterway used for carrying
>> superfluous water along paths or roads for drainage purposes
>>
>
> So, would we all be happy with redoing the various wiki pages along these
> lines:
>
> =canal:
> current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>=
> canal for man-made *open flow* (free flow vs pipe flow) waterways
> <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful
> water for transportation, hydro-power generation or irrigation purposes.
>
> suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>
> =canal for large man-made *open flow* (free flow vs pipe flow) waterways
> <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful
> water, usually for transportation, but also for hydro-power generation or
> irrigation purposes
>
> =drain
> current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>=
> drain for artificial waterways
> <https://wiki.openstreetmap.org/wiki/Waterways>, typically lined with
> concrete or similar, used to carry superfluous water like storm water or
> grey-discharge.
>
> suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>
> =drain for artificial waterways
> <https://wiki.openstreetmap.org/wiki/Waterways>, typically lined with
> concrete or similar, usually used to carry water for drainage or
> irrigation purposes.
>
> =ditch
> current: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>=
> ditch for simple narrow artificial waterways
> <https://wiki.openstreetmap.org/wiki/Waterways> used to drain nearby
> land, to remove storm-water or similar. Ditches are usually straight (as
> opposed to natural streams). They may contain little water or even be dry
> most of the year – to mark this intermittent
> <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used.
>
> suggested: Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>
> =ditch for simple narrow artificial waterways
> <https://wiki.openstreetmap.org/wiki/Waterways>, typically unlined,
> usually used to remove storm-water or similar from nearby land. Ditches
> are usually straight (as opposed to natural streams). They may contain
> little water or even be dry most of the year – to mark this intermittent
> <https://wiki.openstreetmap.org/wiki/Key:intermittent>=yes may be used.
>
> New category
> =channel
> Use waterway <https://wiki.openstreetmap.org/wiki/Key:waterway>=channel for
> small man-made *open flow* waterways
> <https://wiki.openstreetmap.org/wiki/Waterways> used to carry useful
> water, usually for irrigation purposes. Channels are usually straight, but
> can be either lined or unlined.
>
> Would something like that clarify matters?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Trailhead tagging

2019-01-14 Thread Dave Swarthout
Kevin said:
I'm therefore going to stick with 'designated or customary place to
begin or end a trip on a trail.'

Me too. I've mapped many such trailheads in Alaska and almost everybody I
know would recognize the term trailhead as meaning a point of access to a
path or trail. It's fine to add other details, like parking, toilets,
registration facilities, etc. separately. I haven't followed this thread
carefully, so can't speak to the TOP situation fully but I do know a
trailhead when I see it on a map or otherwise.

Dave

On Tue, Jan 15, 2019 at 6:16 AM Graeme Fitzpatrick 
wrote:

>
> On Tue, 15 Jan 2019 at 09:04, Tod Fitch  wrote:
>
>>
>> Guess: Someone found it on the trail and figured it would be easier for
>> the person missing it to find it hanging from the sign than some place
>> along miles of trail.
>>
>
> Bit of a problem when you've got to walk back the 65 klm looking for it!
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-14 Thread Dave Swarthout
I could live with two pages. A shop=caravan and a
shop=recreational_vehicles cross-referenced to one another. It will be
clear from the description that such recreational_vehicles contain
kitchens, bathrooms, living quarters, and are not towed while the caravan
page can specify the same but be restricted to towed, non-powered trailers.
People on both sides of the ocean will have trouble with one or the other
(both?) definitions but I don't see any other way through this semantic
stalemate.

Now, if we could only get rid of tourism_caravan_site and replace it with
tourism=campground. Sigh. That'll never happen but it should.

On Tue, Jan 15, 2019 at 6:14 AM Graeme Fitzpatrick 
wrote:

> On Tue, 15 Jan 2019 at 08:50, Paul Allen  wrote:
>
>>
>> RV may not be only American, but it's still not UK English.
>>
>
> Of course, you are correct Paul, I was forgetting for a moment that OSM is
> supposed to be British English throughout (although we all know that that's
> not really true!).
>
> Minor technicality really - main page stays as =caravan, secondary page/s
> as =recreational_vehicles etc with a description & see shop=caravan.
>
> As far as I can see, that should cover everything, shouldn't it?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-14 Thread Dave Swarthout
Round and round we go and ne'er the twain shall meet.

Mobile home simply will not work in this use case. Nobody camps or travels
from place to place in a mobile home.

On Mon, Jan 14, 2019 at 7:01 PM Paul Allen  wrote:

> On Sun, 13 Jan 2019 at 22:08, Graeme Fitzpatrick 
> wrote:
>
>> Wow, so much for me naively thinking that caravan was a universal word!
>> Should know better by now :-)
>>
>
> Yeah, where are the camels?  It's not a proper caravan without camels.
>
> Have a question about searching though, which was raised previously. You
>> have a place that deals in both (self-propelled) "motorhomes" & also
>> (towed) "caravans", & it's tagged as a shop=caravan, with caravan=yes &
>> also motorhome=yes (ignoring the exact wording for the moment).
>>
>
> If you search for motorhome, will it be found because the details include
>> motorhome=yes, or would you have to search for caravan, because it's tagged
>> as a shop=caravan? (Sorry, I know that's badly worded but can't think of a
>> better way of putting it)
>>
>
> Having thought about it some more, and using shop=mobile_home as the main
> tag (I know you
> don't like it, but I do), then
> mobile_home:sells=static_caravan;touring_caravan;motor_home.  Yes,
> I just mixed UK and US terms there, but it was about the best I could come
> up with on a first
> attempt (no doubt we will spend weeks arguing over those).  Maybe we ought
> to have
> "caravan" and "static_caravan."
>
> So mobile_home appears to cover it.
>
>
> Not really, sorry
>
> https://en.wikipedia.org/wiki/Mobile_home: "A *mobile home* (also
> *trailer*, *trailer home*, *house trailer*, *static caravan*, *residential
> caravan*) is a prefabricated
> <https://en.wikipedia.org/wiki/Prefabrication>structure, built in a
> factory on a permanently attached chassis before being transported to site
> (either by being towed or on a trailer). Used as permanent homes
> <https://en.wikipedia.org/wiki/Home>, or for holiday or temporary
> accommodation, they are left often permanently or semi-permanently in one
> place"
>
> Nothing in that excludes touring caravans.  "Used as permanent homes *or*
> for holiday
> or temporary accommodation."  "The are left *often* permanently [,..] in
> one place."  It may imply
> that the term most commonly refers to static caravans but doesn't
> explicitly exclude RVs,
> touring caravans, etc.
>
> Also, from the second paragraph of https://en.wikipedia.org/wiki/Motorhome
> "Motorhomes" are part of the much larger associated group of *mobile
> homes* which includes
> *caravans, *also known as tourers, and static caravans.
>
> Not that anyone should ever take Wikipedia as gospel for anything, but
> that accords well with
> (British) English definitions of "mobile" and "home."  You can live in it
> (home) and you can
> move it around (mobile).  "Motor home" excludes towed caravans and static
> caravans (no motor) and
> really only includes RVs and similar self-propelled vehicles.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-14 Thread Dave Swarthout
Americans would call them travel trailers, or camper trailers, and I would
also categorize fifth-wheel campers as trailers, despite their sometimes
enormous size, because they are pulled by a separate vehicle.

Paul wrote earlier:
In the US the term RV is a blanket term covering self-propelled, trailers
and all other sub-categories

To continue exploring that suggestion, we could create a new top-level tag,
say shop=recreational_vehicle, or shop=rv, further characterize it using
sells=trailed;self_propelled or some similar term, and then go on to flesh
out the details using other sub-tags as previously suggested.
Recreation_vehicle covers all the bases, is newer a term than caravan so
perhaps less "loaded" with historical baggage, and would work best for the
country within which the lion's share of such vehicles are bought and sold.

Dave

On Mon, Jan 14, 2019 at 10:41 AM Tod Fitch  wrote:

>
> > On Jan 13, 2019, at 7:27 PM, Graeme Fitzpatrick 
> wrote:
> >
> > So what do you call "little houses on wheels that are towed behind your
> car to stay in when you go on holidays"? :-)
> >
> > Are they just "trailers"
> >
> > Thanks
> >
> > Graeme
>
> “Travel trailers”.
>
> A generic plain “trailer” is probably for cargo or hauling your ATV,
> snowmobiles or “dirt bikes”.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-13 Thread Dave Swarthout
Nope, a mobile home is not the same as an RV or travel_trailer. Have a look
at the illustrations on the Wikipedia page. It is, as the Wikipedia
definition says, a prefabricated structure meant for permanent living. It
has wheels, hence the mobile part of its name but it's moved very
infrequently, sometimes only from the factory to its location inside of a,
here's another American term, trailer park.

An aside: As I consider this thread and the problems we're having with
terminology I came to the realization that most countries don't have such
things as we do in the U.S. Some of the motorhomes you see on American
highways are behemoths based on a full-size bus chassis, powered by big
rear-mounted diesel engines. I'd be willing to bet that no other country
has anything even approaching the sheer size of these things. And they are
quite common here. And are they expensive? Yep. 100 to 200K USD and up.

Anyway, how best to describe the plethora of such vehicles, in the U.S.
especially where they are so common, in one word? The term motorhome fits
such monsters and works for many other smaller vehicles like your garden
variety Winnebagos and extended van conversions but cannot describe
unpowered trailers or, in British vernacular, caravans.

Where do we go from here?

On Mon, Jan 14, 2019 at 6:43 AM Warin <61sundow...@gmail.com> wrote:

> On 14/01/19 09:07, Graeme Fitzpatrick wrote:
>
> Wow, so much for me naively thinking that caravan was a universal word!
> Should know better by now :-)
>
> On Sun, 13 Jan 2019 at 21:58, Paul Allen  wrote:
>
>
>
>> However, there does appear to be a better term.  From
>> https://en.wikipedia.org/wiki/Motorhome
>> (the bold emphasis is mine):
>>
>> Motorhomes are part of the much larger associated group of *mobile homes*
>> which includes
>> caravans, also known as tourers, and static caravans.
>>
>> So mobile_home appears to cover it.
>>
>
> Not really, sorry
>
> https://en.wikipedia.org/wiki/Mobile_home: "A *mobile home* (also
> *trailer*, *trailer home*, *house trailer*, *static caravan*, *residential
> caravan*) is a prefabricated
> <https://en.wikipedia.org/wiki/Prefabrication>structure, built in a
> factory on a permanently attached chassis before being transported to site
> (either by being towed or on a trailer). Used as permanent homes
> <https://en.wikipedia.org/wiki/Home>, or for holiday or temporary
> accommodation, they are left often permanently or semi-permanently in one
> place"
>
>
> It would cover those things that slide in and out of utility vehicles and
> act as accommodation.
>
> I think the 'mobile home' is an acceptable term to cover the lot. Why is
> it unacceptable?
> The emphasise on 'permanent' I think is wrong, but there is enough
> vagueness to accept that 'mobile' means mobile.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-13 Thread Dave Swarthout
Back to the caravan vs motorhome distinction for a moment. By the way,
Martin's page was in regard to access, so it's not so relevant to this
discussion except to acknowledge that the term motorhome is in existence.
Graeme mentioned propulsion so I assumed we were talking about what in the
U.S. would be called motorhomes. Maybe then two top-level tags are needed,
as he suggested. One for caravans or trailers, another for powered
motorhomes, aka RVs. The pages could be similar in tagging scheme but have
differing subtags.

Bu that seems both wasteful and will likely be confusing. We could
distinguish between the two basic varieties, motorized or trailer in some
other tag.

Dave

PS: Martin's idea about OSM v2.0. Good one, Martin!

On Sun, Jan 13, 2019 at 3:51 PM Dave Swarthout 
wrote:

> Warin, You're in Australia, right? When I was traveling in New Zealand I'm
> pretty sure they called small motorhomes caravans. But maybe not.
>
> I have no personal knowledge of the word caravan. To me, it makes no sense
> at all to label anything having wheels as a caravan when everyone knows a
> caravan is a string of freight-hauling camels negotiating the Sahara. I say
> that in jest but yet, here we are again getting fouled up with usages in
> different countries. We are stuck with tourism=caravan_site as well. Nobody
> in the U.S. would ever refer to a campground hosting RVs and camping
> trailers as a caravan_site or caravan_park but in OSM, of course, we must
> do just that.
>
> Anyway, my reply needn't be restricted to "caravans" or trailers. It's
> merely an idea I wanted to mention. Just now, Martin replied with a page
> about motorhomes. I'll take a look and get back to you.
>
> On Sun, Jan 13, 2019 at 3:36 PM Warin <61sundow...@gmail.com> wrote:
>
>> On 13/01/19 19:06, Dave Swarthout wrote:
>>
>> >Possibly a separate page again for shop=motorhome? (I think that would
>> be a good coverall term?)
>>
>> I would prefer that but it's an American term. We might as well just stay
>> with caravan. Plus, I do think the tag you're proposing could, with enough
>> thought, be made to work for all types of recreational_vehicles/caravans.
>>
>> There is a difference.
>> Caravans attach to a motor vehicle for moment.
>> Motor homes/campers are self propelled.
>>
>>
>> There was a thread just a while ago on this list discussing ti-lo's solo
>> initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme
>> that integrated the functions of dealer, parts shop and accessories shop by
>> using subtags to make the distinctions. (See the Services section:
>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags).
>> His scheme was criticized because he didn't discuss it fully enough on this
>> list but aside from that, I liked the idea. The main tag and all subtags
>> except those that already stand on their own, begin with the same keyword,
>> motorcycle, and proceed from there, adding as much detail as desired or
>> known.
>>
>> Hence, one might have
>> caravan:parts=yes
>> caravan:accessories=yes/no
>> caravan:sales=yes/no
>> caravan:type=type_a/type_b/type_c/fifth_wheel/trailer
>>
>> type?  caravan:classification=* ? classifications could be local legal
>> ones. Other things are descriptions .. and OSM has a tag for that.
>>
>> second_hand=yes/only
>> caravan:propulsion=trailer/yes/solar_powered (wishful thinking)  [also
>> gas/diesel?]
>>
>> I say again, caravans are not self propelled - they need to be pulled
>> along by something.
>> Oxford Dictionary: A vehicle equipped for living in, typically towed by
>> a car.
>> Origin Late 15th century (in caravan (sense 2)): from French caravane,
>> from Persian kārwān. The sense ‘covered horse-drawn wagon’ dates from the
>> early 19th century.
>>
>>
>> The caravan:types are well-known to anyone shopping for RVs (in America
>> for sure but Europe or Asia, I dunno) but the tag is optional. Use it for
>> fine-grained tagging, ignore it otherwise.
>>
>>
>> In the UK smaller 'back' roads are narrow - Toyota Landcrusiers are seen
>> as too wide, an American small Winabago is UK huge.
>>
>>
>> Dave
>>
>> On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick 
>> wrote:
>>
>>>
>>>
>>>
>>> On Sun, 13 Jan 2019 at 13:06, Dave Swarthout 
>>> wrote:
>>>
>>>> I'm assuming that this tagging scheme is also for a shop that sells
>>>> only caravan parts and accessories but not caravans.
>>>>
>>>
>>> No, I've tried to set

Re: [Tagging] Creating shop=caravan

2019-01-13 Thread Dave Swarthout
Warin, You're in Australia, right? When I was traveling in New Zealand I'm
pretty sure they called small motorhomes caravans. But maybe not.

I have no personal knowledge of the word caravan. To me, it makes no sense
at all to label anything having wheels as a caravan when everyone knows a
caravan is a string of freight-hauling camels negotiating the Sahara. I say
that in jest but yet, here we are again getting fouled up with usages in
different countries. We are stuck with tourism=caravan_site as well. Nobody
in the U.S. would ever refer to a campground hosting RVs and camping
trailers as a caravan_site or caravan_park but in OSM, of course, we must
do just that.

Anyway, my reply needn't be restricted to "caravans" or trailers. It's
merely an idea I wanted to mention. Just now, Martin replied with a page
about motorhomes. I'll take a look and get back to you.

On Sun, Jan 13, 2019 at 3:36 PM Warin <61sundow...@gmail.com> wrote:

> On 13/01/19 19:06, Dave Swarthout wrote:
>
> >Possibly a separate page again for shop=motorhome? (I think that would be
> a good coverall term?)
>
> I would prefer that but it's an American term. We might as well just stay
> with caravan. Plus, I do think the tag you're proposing could, with enough
> thought, be made to work for all types of recreational_vehicles/caravans.
>
> There is a difference.
> Caravans attach to a motor vehicle for moment.
> Motor homes/campers are self propelled.
>
>
> There was a thread just a while ago on this list discussing ti-lo's solo
> initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme
> that integrated the functions of dealer, parts shop and accessories shop by
> using subtags to make the distinctions. (See the Services section:
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags).
> His scheme was criticized because he didn't discuss it fully enough on this
> list but aside from that, I liked the idea. The main tag and all subtags
> except those that already stand on their own, begin with the same keyword,
> motorcycle, and proceed from there, adding as much detail as desired or
> known.
>
> Hence, one might have
> caravan:parts=yes
> caravan:accessories=yes/no
> caravan:sales=yes/no
> caravan:type=type_a/type_b/type_c/fifth_wheel/trailer
>
> type?  caravan:classification=* ? classifications could be local legal
> ones. Other things are descriptions .. and OSM has a tag for that.
>
> second_hand=yes/only
> caravan:propulsion=trailer/yes/solar_powered (wishful thinking)  [also
> gas/diesel?]
>
> I say again, caravans are not self propelled - they need to be pulled
> along by something.
> Oxford Dictionary: A vehicle equipped for living in, typically towed by a
> car.
> Origin Late 15th century (in caravan (sense 2)): from French caravane,
> from Persian kārwān. The sense ‘covered horse-drawn wagon’ dates from the
> early 19th century.
>
>
> The caravan:types are well-known to anyone shopping for RVs (in America
> for sure but Europe or Asia, I dunno) but the tag is optional. Use it for
> fine-grained tagging, ignore it otherwise.
>
>
> In the UK smaller 'back' roads are narrow - Toyota Landcrusiers are seen
> as too wide, an American small Winabago is UK huge.
>
>
> Dave
>
> On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick 
> wrote:
>
>>
>>
>>
>> On Sun, 13 Jan 2019 at 13:06, Dave Swarthout 
>> wrote:
>>
>>> I'm assuming that this tagging scheme is also for a shop that sells only
>>> caravan parts and accessories but not caravans.
>>>
>>
>> No, I've tried to set it up selling (dealer) as well as parts, repair &
>> rental. Any other options you can think of, or better ways to word things?
>>
>>
>>> Also, I see you've decided not to be specific about the type or style of
>>> caravan sold. I would think caravan:style or caravan:class might be useful
>>> to distinguish between type_a, type_c, fifth-wheel, trailer, etc.
>>>
>>
>> Couple of people have suggested that & I've asked some questions about
>> "how" but no feedback yet
>>
>> On Tue, 8 Jan 2019 at 07:54, Graeme Fitzpatrick 
>> wrote:
>>
>>>
>>> Possibly something like caravan:type=caravan / motorhome / Winnebago /
>>> camper trailer etc, but then you get to the problem of what is difference
>>> between a camper van, motorhome & Winnebago?
>>>
>>
>> motorised=yes / no?
>>
>> propulsion=towed / motorised?
>>
>> Possibly a separate page again for shop=motorhome? (I think that would be
>> a good coverall term?)
>>
>> It's also, at least in the US, very common for

Re: [Tagging] Creating shop=caravan

2019-01-13 Thread Dave Swarthout
>Possibly a separate page again for shop=motorhome? (I think that would be
a good coverall term?)

I would prefer that but it's an American term. We might as well just stay
with caravan. Plus, I do think the tag you're proposing could, with enough
thought, be made to work for all types of recreational_vehicles/caravans.

There was a thread just a while ago on this list discussing ti-lo's solo
initiative to upgrade motorcycle=shop tagging. It was/is a sensible scheme
that integrated the functions of dealer, parts shop and accessories shop by
using subtags to make the distinctions. (See the Services section:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmotorcycle#Services_tags).
His scheme was criticized because he didn't discuss it fully enough on this
list but aside from that, I liked the idea. The main tag and all subtags
except those that already stand on their own, begin with the same keyword,
motorcycle, and proceed from there, adding as much detail as desired or
known.

Hence, one might have
caravan:parts=yes
caravan:accessories=yes/no
caravan:sales=yes/no
caravan:type=type_a/type_b/type_c/fifth_wheel/trailer
second_hand=yes/only
caravan:propulsion=trailer/yes/solar_powered (wishful thinking)  [also
gas/diesel?]

The caravan:types are well-known to anyone shopping for RVs (in America for
sure but Europe or Asia, I dunno) but the tag is optional. Use it for
fine-grained tagging, ignore it otherwise.

Dave

On Sun, Jan 13, 2019 at 1:01 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 13 Jan 2019 at 13:06, Dave Swarthout 
> wrote:
>
>> I'm assuming that this tagging scheme is also for a shop that sells only
>> caravan parts and accessories but not caravans.
>>
>
> No, I've tried to set it up selling (dealer) as well as parts, repair &
> rental. Any other options you can think of, or better ways to word things?
>
>
>> Also, I see you've decided not to be specific about the type or style of
>> caravan sold. I would think caravan:style or caravan:class might be useful
>> to distinguish between type_a, type_c, fifth-wheel, trailer, etc.
>>
>
> Couple of people have suggested that & I've asked some questions about
> "how" but no feedback yet
>
> On Tue, 8 Jan 2019 at 07:54, Graeme Fitzpatrick 
> wrote:
>
>>
>> Possibly something like caravan:type=caravan / motorhome / Winnebago /
>> camper trailer etc, but then you get to the problem of what is difference
>> between a camper van, motorhome & Winnebago?
>>
>
> motorised=yes / no?
>
> propulsion=towed / motorised?
>
> Possibly a separate page again for shop=motorhome? (I think that would be
> a good coverall term?)
>
> It's also, at least in the US, very common for a dealer
>> to sell one or the other, but not both.
>
>
> But if we use a separate page, won't you have the same problem that you'll
> only be able to find one or the other?
>
> As I mentioned earlier, if we had
>
> caravan:type=caravan / motorhome / camper_trailer
>
> would you be able to search for the type you want?
>
> So, any thoughts?
>
> Thanks
>
> Graeme
>
> PS How you going using Warin's suggestion to create pages? :-)
>
>
>


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


Re: [Tagging] Creating shop=caravan

2019-01-12 Thread Dave Swarthout
I'm assuming that this tagging scheme is also for a shop that sells only
caravan parts and accessories but not caravans. There are any such shops
scattered around the U.S. Also, I see you've decided not to be specific
about the type or style of caravan sold. I would think caravan:style or
caravan:class might be useful to distinguish between type_a, type_c,
fifth-wheel, trailer, etc.  I think I saw some comments earlier in this
thread about class.

On Sun, Jan 13, 2019 at 9:13 AM Lorenzo Mastrogiacomi 
wrote:

> Il giorno dom, 13/01/2019 alle 11.26 +1000, Graeme Fitzpatrick ha
> scritto:
> >
> >
> >
> > On Sun, 13 Jan 2019 at 09:44, Lorenzo Mastrogiacomi <
> > lomastr...@gmail.com> wrote:
> > > Language links come from the shop=* page, probably because the page
> > > name is wrong :)
> > > Please use the Move action under More and enter the name
> > > "Tag:shop=caravan".
> >
> > Thanks Lorenzo!
> >
> > Done, so page is now at
> > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcaravan,
> > but
> > > > > Languages - how do I edit them all out?
> >
> > all the other languages are still listed?
> >
> > Thanks
> >
> > Graeme
> >
>
> Ok, so I don't know why but I just added the type=value parameter to
> the ValueDescription template and it looks good now.
>
>
>
> Lorenzo
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-01-10 Thread Dave Swarthout
Tomas,

We just went through a whole discussion about mapping bays as
polygons. (see 
https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html)
This is a similar one. I was one of the people who promoted converting
nodes that describe bays into polygons in order to better represent
their true size and provide better label placement. Now, after having
to add boundaries to those areas of coastline, I can see the benefits
of leaving the nodes as they are and allowing software to place the
result labels as best it can. Many on this list didn't favor using
multipolygons to outline bays either. Involving polygons does
complicate subsequent mapping chores. For example, I was adding a
National Park boundary in Alaska. I wanted to conflate it with
coastline where I could. So I have this way, the boundary way, that is
also shared with a peninsula, and also a portion of named ocean, the
Chukchi Sea, a large "bay" of sorts, which is also a multipolygon.
Each section of coastline/boundary must now be added separately to
these three multipolygons! It's a ton of work.

I stopped using multipolygons to map bays after that. I might use them
on occasion to better "illustrate" peninsulas but I won't do that in
an area where there's already multipolygon complexity present. As
people pointed out in the last discussion, it makes for a ton of extra
work and invites errors from novice mappers. I now agree with that
view.

Dave

On Thu, Jan 10, 2019 at 2:56 PM Tomas Straupis  wrote:
>
> 2019-01-10, kt, 09:06 Martin Koppenhoefer rašė:
> > coding the geometry into the db does not necessarily mean creating polygons 
> > though.
> > You could also store just 3 nodes and a hint that these are representing a 
> > polygon, to store a triangle (for example).
>
>   Sorry, I did not get it. How saving only vertexes is better than
> having a polygon (made out of those vertexes)?
>
>   Full geometry is required to be able to calculate label positions on
> all scales. For small scales this could be a simple curved line
> (calculated from polygon geometry), for large scales it could be a lot
> of labels placed/scattered on the same polygon geometry and
> approximating (simplifying) such polygon too much would decrease
> number of labels placed or labels would be placed outside of an object
> which is even worse.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

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


Re: [Tagging] Creating shop=caravan

2019-01-07 Thread Dave Swarthout
Warin -
I read through the documentation for Templates and the way it's used in
Mediawiki applications like our Wiki is to define a piece of text, with or
without photos, etc., as a reusable fragment that can be inserted in any
page and if the original, the "template", is edited the changes propagate
to all instances of the template in as many places as it appears. It's sort
of like what used to be known as "boilerplate" in word-processors except
its content is dynamic.

Thanks for your clarification though. It motivated me to learn a bit more
about the Wiki s/w I constantly complain about. LOL

On Mon, Jan 7, 2019 at 3:32 PM Marc Gemis  wrote:

> Graeme,
>
> You might have to change the picture and the rendering icon in the
> right "summary" bar.
>
> On Mon, Jan 7, 2019 at 8:22 AM Graeme Fitzpatrick 
> wrote:
> >
> > & here we go: https://wiki.openstreetmap.org/wiki/Shop%3Dcaravan :-)
> >
> > Known problems
> >
> > Languages - how do I edit them all out?
> >
> > service=parts has moved one box too far across
> >
> > Have to change the photo & (suggested) icon
> >
> > Wikidata reference
> >
> > Any & all other comments welcome!
> >
> > Seeing that apparently it's already been used 130 odd times, can I take
> that we don't actually have to RFC & vote on it?
> >
> > Thanks
> >
> > Graeme
> >
> >
> > On Mon, 7 Jan 2019 at 17:06, Graeme Fitzpatrick 
> wrote:
> >>
> >>
> >> On Mon, 7 Jan 2019 at 11:12, Warin <61sundow...@gmail.com> wrote:
> >>>
> >>> This is what I do .. it works and leaves the original page alone...
> >>>
> >>> 1) get the "car" template
> >>> On the page you want to copy Click on "edit Source" - Copy all of it
> and paste it over to your your word processor as a new document.
> >>>  Exit out out this "Edit Source" without saving "cancel" I think is it
> - so it stays the same.
> >>>
> >>> 2) edit the template
> >>> Now in your word processor find and replace all the "car" and replace
> with "caravan". Perform similar edits here - much easier than the editor
> you may not be familiar with on the wiki.
> >>> When your finished here ...
> >>>
> >>>
> >>> 3) create the new page
> >>> Type the title of the page you want to create in the wiki search box
> ...
> >>> It will come up with a suggestion to create the page you want .. click
> on that and you have started to create the new page :)
> >>> Copy all of the stuff you have on your word processor page over to the
> new page (copy and paste) .. and save it ... Done.
> >>
> >>
> >> Warin, that is fantastic! :-)
> >>
> >> Now you just have to write a page titled Creating pages, so everybody
> can find it!
> >>
> >> 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
>


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


Re: [Tagging] Creating shop=caravan

2019-01-06 Thread Dave Swarthout
@Warin
Can you illustrate or explain the differences between editing a  "template"
and editing a simple page? When you save your edited version of the new
page does it become a template?

On Mon, Jan 7, 2019 at 8:12 AM Warin <61sundow...@gmail.com> wrote:

> This is what I do .. it works and leaves the original page alone...
>
> 1) get the "car" template
> On the page you want to copy Click on "edit Source" - Copy all of it and
> paste it over to your your word processor as a new document.
>  Exit out out this "Edit Source" without saving "cancel" I think is it -
> so it stays the same.
>
> 2) edit the template
> Now in your word processor find and replace all the "car" and replace with
> "caravan". Perform similar edits here - much easier than the editor you may
> not be familiar with on the wiki.
> When your finished here ...
>
>
> 3) create the new page
> Type the title of the page you want to create in the wiki search box ...
> It will come up with a suggestion to create the page you want .. click on
> that and you have started to create the new page :)
> Copy all of the stuff you have on your word processor page over to the new
> page (copy and paste) .. and save it ... Done.
>
> On 07/01/19 11:23, Dave Swarthout wrote:
>
> Haha, Graeme. I am in the same boat when it comes to adding anything to
> the Wiki. Welcome to the arcane world of Wiki editing. I don't have an
> answer to your question. I only want to sympathize.
>
> Dave
>
>
>
> On Mon, Jan 7, 2019 at 5:35 AM Graeme Fitzpatrick 
> wrote:
>
>> Recently asked what to tag some things as, including a business selling
>> caravans.
>>
>> On Sat, 29 Dec 2018 at 02:37, Philip Barnes  wrote:
>>
>>> On Fri, 2018-12-28 at 16:36 +1000, Graeme Fitzpatrick wrote:
>>>
>>>
>>> & yards dedicated to caravan sales? I can find shop=car
>>> https://wiki.openstreetmap.org/wiki/Tag:shop=car, which says it's a
>>> place that sells cars, buses or trucks. Perhaps shop=caravan?
>>>
>>>
>>> Shop=caravan has over 100 uses, so why not?
>>>
>>
>> With fear & trepidation :-) I am about to try & create a page
>> shop=caravan, then put it up for further discussion.
>>
>> I know this has been discussed before, but I'm still unclear on the
>> details (& from previous discussions, a lot of other people are as well :-()
>>
>> The page would be fairly similar to shop=car
>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar, so that sounds like
>> a good basis to start with.
>>
>> If I just open that page, "Edit source", change value=car to
>> value=caravan, then save that, I'm fairly sure that will create a
>> shop=caravan page ready for further editing, but will the original shop=car
>> page still exist?
>>
>> Is there a better way to create a new page?
>>
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-06 Thread Dave Swarthout
Haha, Graeme. I am in the same boat when it comes to adding anything to the
Wiki. Welcome to the arcane world of Wiki editing. I don't have an answer
to your question. I only want to sympathize.

Dave



On Mon, Jan 7, 2019 at 5:35 AM Graeme Fitzpatrick 
wrote:

> Recently asked what to tag some things as, including a business selling
> caravans.
>
> On Sat, 29 Dec 2018 at 02:37, Philip Barnes  wrote:
>
>> On Fri, 2018-12-28 at 16:36 +1000, Graeme Fitzpatrick wrote:
>>
>>
>> & yards dedicated to caravan sales? I can find shop=car
>> https://wiki.openstreetmap.org/wiki/Tag:shop=car, which says it's a
>> place that sells cars, buses or trucks. Perhaps shop=caravan?
>>
>>
>> Shop=caravan has over 100 uses, so why not?
>>
>
> With fear & trepidation :-) I am about to try & create a page
> shop=caravan, then put it up for further discussion.
>
> I know this has been discussed before, but I'm still unclear on the
> details (& from previous discussions, a lot of other people are as well :-()
>
> The page would be fairly similar to shop=car
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar, so that sounds like a
> good basis to start with.
>
> If I just open that page, "Edit source", change value=car to
> value=caravan, then save that, I'm fairly sure that will create a
> shop=caravan page ready for further editing, but will the original shop=car
> page still exist?
>
> Is there a better way to create a new page?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] amenity=taxi vehicle type

2019-01-05 Thread Dave Swarthout
In Alaska, which is largely roadless, there are countless air-taxis and
many water-taxis.

On Sun, Jan 6, 2019 at 7:45 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 5. Jan 2019, at 01:58, Joseph Eisenberg 
> wrote:
>
> Alternately, we could use amenity=motorcycle_taxi and amenity=pedicab(? is
> this the British terminology?)
>
>
>
> there are also water taxis (with boats),  Venice comes to mind, but there
> are also others.
>
> https://en.m.wikipedia.org/wiki/Water_taxi
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] motorcycle tagging

2019-01-05 Thread Dave Swarthout
I have been contacted at least twice by user:ti-lo about changing the
tagging of several motorcycle shops I've added over the years. He is a bit
of an evangelist for the new scheme yet has always been polite while asking
to change my tags. Recently, I checked to see if the tags were documented
in the Wiki and learned that the "new tagging" scheme aligned with his
recommendations. I like the scheme and have always said, sure, go ahead
never thinking that the Wiki had been modified by him (as user:Rtfm) to
push the scheme he favors.

I don't think it's good policy to discourage mappers from coming up with a
new tagging scheme. However, such wholesale changes should be discussed
fully here and perhaps elsewhere but, as someone else pointed out, trying
to get anything approved by the tagging list is a long struggle that often
ends in stalemate. I have often been frustrated by the endless
deliberations that occur on this list when even a relatively small change
in tagging has been suggested.

Consequently, my opinion about what to do is mixed. Certainly, a full
discussion is warranted before going ahead.

Best,
Dave

On Sun, Jan 6, 2019 at 5:48 AM Warin <61sundow...@gmail.com> wrote:

> On 06/01/19 06:51, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 5. Jan 2019, at 08:25, Warin <61sundow...@gmail.com> wrote:
> >>
> >> Not mandatory in OSM ... "Any tags you like".
> >
> > you can use any tags you like in your mapping, but that doesn’t imply
> “changing” tags. It is one thing adding motorcycle:* tags, and another
> removing “old style” tags.
> > Or changing the value of a “standard key” from something well known to
> something “new” (not established) (provided the well known value applies
> according to common understanding).
>
> Thanks for reading the words and not adding to there meaning :)
>
> I too do not encourage changing current tags to some other tag. Only with
> depreciated tags would I encourage there replacement with more current tag
> use.
>
> >
> > And it doesn’t imply changing the tagging recommendations in the wiki
> unilaterally. You can do this on your user page, but not in the common
> space.
> >
> > I agree with Allan’s proposition and ask him to set up a proposal.
>
> Rather than 'set up a proposal' I would ask the contributor (and that is
> not Allen) to discuss the matter here.
>
> Possible problems are that the contributor does not have good English
> skills and maybe reactant to enter into that problem area combined with the
> problem of tagging.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Trailhead tagging

2019-01-02 Thread Dave Swarthout
Peter: " Mapping a trailhead node as I suggested does not stand in the way
of more complex options. My idea: begin with the simplest common element
which supports all the other options. "

+1

On Wed, Jan 2, 2019 at 8:13 PM Peter Elderson  wrote:

> Sometimes it would, sometimes it would not. If the node actually
> represents the start of the trail, it is already in the relation because it
> is part of the way that belongs to the route. In the situation that a
> trailhead node represents a named cluster of helpful facilities/amenities
> in the vicinity of several trails or networks, you wouldn't want to add it
> to all the relations, because a. it's not actually part of the routes and
> b. maintenance of all the routes would be quite error-prone and not really
> intuitive.
>
> A site relation has been suggested for the more complex trailheads. You
> would include the node there, the parking(s), the information booth or
> guide stands, maybe PT-stops, possibly the route relations you can access
> from the site...
>
> Mapping a trailhead node as I suggested does not stand in the way of more
> complex options. My idea: begin with the simplest common element which
> supports all the other options.
>
> Op wo 2 jan. 2019 om 12:04 schreef Tobias Wrede :
>
>> Wouldn't it make sense to add the trail head (node) to a route relation
>> with role=trail_head?
>>
>> Am 01.01.2019 um 12:54 schrieb Peter Elderson:
>> > At this point, I settle for just requiring that it's a named location
>> > visibly designated as access point for one ore more recreational routes.
>> >
>> > So just a node tagged highway=trailhead and name=> trailhead>.
>> >
>> > Which node? Well, if it's just the start with a name on a guidepost,
>> > use the guidepost node. If it's an information board with the name,
>> > use that. If there is a flagpole or a stele or say a statue of the
>> > pioneer who walked it first, use that. If there is none of that, use
>> > the location which presents itself naturally as a starrting point when
>> > you get there. If there is no such location, then it's not a trailhead!
>> >
>> > Anything else: optional, map and tag as seems appropriate.
>> >
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Vr gr Peter Elderson
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2019-01-01 Thread Dave Swarthout
Agree with Graeme. I like the illustration he shared too, "a cape can be
found at the end of a peninsula (and, in my experience, often are) while
you'll never see a peninsula at the end of a cape." The state of Florida is
a peninsula as is India, at least by someone's definition.

On Wed, Jan 2, 2019 at 4:42 AM Graeme Fitzpatrick 
wrote:

> On Wed, 2 Jan 2019 at 02:01, Markus  wrote:
>
>>
>> Is the distinction of peninsulas from capes correct (see section See
>> also)?
>>
>
> I have concerns about the definition of peninsula that you've used "a
> piece of land nearly surrounded by water and *connected to a larger land
> area by an isthmus, that is a narrow strip of land*"
>
> I did see that definition, but most definitions of peninsula that I have
> found don't mention the "narrow strip of land" eg peninsula:  A piece of
> land projecting into water from a larger land mass; cape: A piece or
> point of land, extending beyond the adjacent coast into a sea or lake; a
> promontory; a headland.
>
> Another good explanation, with some examples:
> https://www.quora.com/Whats-the-difference-between-a-cape-and-a-peninsula-They-seem-to-have-different-definitions-that-are-in-practice-actually-the-same-thing.
> As they put it "a cape can be found at the end of a peninsula. Peninsulas
> are not found at the end of capes"
>
> I also give you Cape York Peninsula,
> https://en.wikipedia.org/wiki/Cape_York_Peninsula which is a peninsula
> terminating in Cape York - definitely no "narrow strips of land" involved!
> :-)
>
> Thanks
>
> Graeme
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia

2019-01-01 Thread Dave Swarthout
LeTopographeFou wrote:

> I also reached this conclusion some time ago but looking at how it is
difficult to change something regarding tagging I stop authorizing myself
thinking that such situation CAN be changed. However I'm not >affraid of
such major change if it can bring enhancement. I'm ok to consider a
proposal which would lead to the tourism=accomodation schema.

I think such a page would be useful and I encourage you to write it as a
proposal. It's going to be an uphill battle to promote a change in the
basic tagging at this late date but an accommodation page would be a great
start. As for mappers in countries where the distinction between types of
accommodation is set in legal terms, they can just continue tagging the way
it's always been done.

On Wed, Jan 2, 2019 at 5:47 AM Graeme Fitzpatrick 
wrote:

>
>
> On Tue, 1 Jan 2019 at 23:52, LeTopographeFou 
> wrote:
>
>> I'm ok to consider a proposal which would lead to the
>> tourism=accomodation schema.
>>
>> But I think that whatever we do (new schema vs existing schema) an
>> "Accomodation" wiki page (routing to hotel/motel/... tags) will be helpfull
>> to today route to existing tags and maybe tomorrow explain the new schema.
>>
>
> I agree with most of what has been said here, especially "the only
> practical distinction today is the name on the front sign", however
>
>> Le 01/01/2019 à 03:23, Silent Spike a écrit :
>>
>> the current information there considers motels to be a subclass of hotels
>> (so all motels are hotels, not all hotels are motels).
>>
>> On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard  wrote:
>>>>>
>>>>>> Local licensing authorities do not differentiate between them and
>>>>>> they are regulated identically,
>>>>>>
>>>>> As I mentioned previously, in Australia at least, licensing
> authorities *do* differentiate between them, in that a hotel is licensed
> to sell alcohol, while a motel isn't. Granted, that doesn't effect
> accommodation options, but a motel is not, strictly speaking, a hotel.
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia

2018-12-31 Thread Dave Swarthout
Tobias wrote:

"Now that several comments here indicate that the only practical
distinction today is the name on the front sign I come to think that we
could abandon the tag altogether."

+1

I agree. We tend to "split hairs" in OSM, when in some cases it simply
isn't worth the effort. These objects are just temporary accommodations
that, granted, have varying characteristics. Here in Thailand, it's
virtually impossible to differentiate between a guest_house and a hotel.
And how should one tag facilities that label themselves as a "resort"
(รีสอร์ท)? A better approach might (have been) to use a generic term like
tourism=accommodation as a top level and then describe the facility more
fully with subtags. Of course, we're pretty much stuck with the present
imperfect tagging situation.

Dave

On Mon, Dec 31, 2018 at 10:18 PM Tobias Wrede  wrote:

> In Germany my experience is that actually most hotels in the cities charge
> for parking. On the other hand you find very very few that call themselves
> "motel". I can only think of one currently that does, and it is located
> within a motorway rest area. The exception is the chain Motel One which is
> a very typical _h_otel often located in city centers offering only limited
> parking.
>
> When I think of a motel I always picture those with doors opening to the
> car park from US movies. Now that several comments here indicate that the
> only practical distinction today is the name on the front sign I come to
> think that we could abandon the tag altogether. What value does it generate
> for the data consumer if tourism=motel and tourism=hotel is all but the
> same and practical distinction could for both be made by subtags
> parking=y/n, parking:fee=y/n, etc?
>
> Tobias
>
>
> Am 24.12.2018 um 01:12 schrieb Joseph Eisenberg:
>
> In the USA, we would also assume a motel offers free parking. Hotels may
> charge extra for parking, especial if located downtown or next to an
> airport.
>
> Is this also the case in Europe and Australia?
> On Mon, Dec 24, 2018 at 8:55 AM Dave Swarthout 
> wrote:
>
>> "Today the main difference seems to be the sign out front.  If a hostelry
>> calls itself a motel, it is a motel.  If it calls itself a hotel, it is a
>> hotel.  Local licensing authorities do not differentiate between them and
>> they are regulated identically, so far as I can tell.  I'd say the
>> definition should be based on what is written on the sign on the hostelry."
>>
>> +1
>>
>> That's my main criterion for tagging an accommodation as a  motel. I
>> agree with Volker's points and Allan's view on this.
>>
>> Happy Holidays
>>
>> Dave
>>
>> On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard  wrote:
>>
>>> Motel = MOtor hoTEL
>>>
>>> The major difference between a 'hotel" and a "motel" originally was the
>>> configuration of the building with respect to parking.  At a traditionally
>>> designed motel, the cars are parked outside the units, which typically open
>>> to the outdoors, not to a hallway, so that patrons of the motel may come
>>> and go freely to their automobiles.  Length of stay is immaterial.
>>>
>>> The first motels appeared on the Lincoln Highway in the 1920s, if memory
>>> serves, and had little carports capable of accommodating a Model T
>>> Ford-sized automobile next to a cabin (yes, the first motels featured
>>> cabins, not rooms in a larger building).
>>>
>>> Then along came Motel 6, so called because it charged $6 per night back
>>> in the day (it featured coin-operated TVs and you paid extra for everything
>>> but the bed, bath, and four walls).  Many Motel 6s had hallways, and that
>>> changed the design, but they still catered to transients en route from
>>> Point A to Point B.
>>>
>>> Today the main difference seems to be the sign out front.  If a hostelry
>>> calls itself a motel, it is a motel.  If it calls itself a hotel, it is a
>>> hotel.  Local licensing authorities do not differentiate between them and
>>> they are regulated identically, so far as I can tell.  I'd say the
>>> definition should be based on what is written on the sign on the hostelry.
>>> These are my two cents' worth based on 30+ years of travel, including a few
>>> cross-country trips across America as well as extensive on-ground travel in
>>> Mexico, Russia, and central Europe.
>>>
>>> Cheers and Merry Christmas to all!
>>> apm-wa
>>>
>>>
>>> On Sun, Dec 23, 2018 at 4:33 AM bkil  wrote:
>>>
>>>&g

Re: [Tagging] Trailhead tagging

2018-12-31 Thread Dave Swarthout
I think tagging trailheads as nodes would work for the great majority of
the trailheads I've seen over the years. The first node of a designated
footway can be tagged as highway=trailhead, a name or other related tagging
added to that, and other amenities such as parking lots, waste bins,
toilets and the like can be tagged as nodes, or in some cases, relations.
Many of the trailheads I've mapped have no other facilities associated with
them, they are merely the beginning of a designated footway or hiking
trail. In the definition in the Wiki, one could make it legal for relations
to be tagged this way in order to accommodate those trailheads that
encompass a range of amenities along with the trailhead itself.

Dave

PS: Happy New Year 2019

On Mon, Dec 31, 2018 at 9:52 PM Tobias Wrede  wrote:

> Hi eveyone,
>
> Am 21.12.2018 um 19:55 schrieb Peter Elderson:
> > Well, in Nederland I'm through, got them all. To initiate a rendering
> > on osm-carto the usage should increase by some 500+ (now on 1400+). I
> > need Germany or Italy!
>
> While on vacation I have mapped trail heads in the US pretty much the
> way Kenny has described it. I've never come across the trail head tag so
> far. In the US trail heads I have encountered were often marked as such
> having some signpost giving information on length, difficulty,
> accessibility etc. And often there was a road sign saying "xyz trail
> head". Often there is a single or very few trails departing there and
> each trail only has one or two access points that are called a trail
> head. (disclaimer: I am sure there are other situations but these are
> the ones I have encountered while on vacation).
>
> In Germany, though, the concept of trail head is not so widely used for
> hiking trails. Very often trails are interconnected forming a mesh and
> are accessible from various locations. What we rather have are marked
> parking lots called "Wanderparkplatz", i. e. "hiking parking lot". There
> is even an official traffic sign:
>
> https://de.wikipedia.org/wiki/Datei:Zeichen_317_-_Wandererparkplatz,_StVO_1992.svg.
>
> The more fancy ones have a map of the surroundings showing all hiking
> trails of the area, possibly with length, hiking duration and
> difficulty. Often there is a waste bin, sometimes a pickinick table,
> very often it's only a few parking spots off the road crossing a forest.
> These hiking parking lots are very often not dedicated to a certain
> trail, though. Often you find them in places where there are footways
> but no marked or named hiking trails at all.
>
> As far as I see we don't currently designate these hiking parking lots
> as such. They are just amenity parking connected to some paths/hiking
> routes plus possibly having an information board mapped. I wouldn't be
> opposed somehow tagging the Wanderparkplatz designation, not sure a
> highway-tag would be right with the amenity, though.
>
> Having this said there are of course also some trail heads in Germany
> that more fit to what I described for the US or what you might have in
> the Netherlands. But they are the minority here I would say.
>
> all the best for the new Year
> Tobias
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal – RFC – place=peninsula

2018-12-27 Thread Dave Swarthout
" I would think all of these should come under natural=x, & should be
mapped as they are named: =headland, =cape, =peninsula, =promontory etc etc
"

+1 That's been my general practice as well. The designations of cape,
point, peninsula, headland, etc., are all arbitrary and come from
historical usage.

On Fri, Dec 28, 2018 at 4:14 AM Graeme Fitzpatrick 
wrote:

>
> On Thu, 27 Dec 2018 at 19:05, Martin Koppenhoefer 
> wrote:
>
>>
>> > Is there an upper cut-off where things stop being a peninsula?
>>
>> Hmmm ... not really.
>>
>> No indeed! When I did some looking into it, Europe can actually be
> considered to be a peninsula off Asia!
>
>
>> is there a difference to a “cape”? What about a promontory? Shall we
>> distinguish these, and if yes how and according to which criteria?
>>
>
> Same thing then applies to headland & isthmus? The natural=cape wiki makes
> reference to See Also natural-isthmus (but the page doesn't exist!) & lists
> natural=headland (also doesn't exist) as a Possible Tagging Mistake. Why?
>
> When I've looked at a few headlands I know, a couple of them are listed as
> place=locality, name=Indian Head, which, to me, doesn't really ring true?
>
> I would think all of these should come under natural=x, & should be
> mapped as they are named: =headland, =cape, =peninsula, =promontory etc etc
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Top up

2018-12-26 Thread Dave Swarthout
"top up" is commonly used in Thailand for adding money to a cell phone
balance. My bank's website, Kasikorn Bank, uses that exact term and offers
a way to "top up" your phone online.

On Thu, Dec 27, 2018 at 7:54 AM Tom Pfeifer  wrote:

> On 26.12.2018 19:05, bkil wrote:
> > Please don't confuse top ups with refilling:
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink
>
> No I don't confuse it. The refilling proposal is about refills without
> additional charge.
> To top-up a drink is purchasing a new one without wasting another clean
> glass.
>
> > I think "top up" is standard terminology in the UK for increasing the
> balance of prepaid mobile
> > phone accounts.
>
> By which standard? I think it is marketing slang, as it makes no sense
> semantically.
>
> > top_up:credit_card:‹brand›=yes;no
>
> As said, if the amount is pre-paid, it is not a credit card. It might be a
> debit card because you
> have to have the money in advance.
>
> tom
>
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal – RFC – place=peninsula

2018-12-26 Thread Dave Swarthout
I would not disagree with the reasoning fur the use of either tag but have
used natural=peninsula extensively in my Alaska mapping so I prefer going
forward with that one.

Dave

On Thu, Dec 27, 2018 at 2:02 AM Markus  wrote:

> On Wed, 26 Dec 2018 at 19:23, Martin Koppenhoefer
>  wrote:
> >
> > Being this about a landform I would tend to prefer the natural key for
> it, although the use of place isn’t defacto limited to man made places
> (particularly locality) either.
>
> A peninsula is a land form, on the other hand, we're also using
> place=* for islands, islets and continents (as well as oceans and
> seas), which are also land forms.
>
> But i were fine with natural=peninsula too. The main thing for me is
> that we can agree on one tag.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] request for review: OSM wiki rewording of tourism=motel based on Wikipedia

2018-12-23 Thread Dave Swarthout
"Today the main difference seems to be the sign out front.  If a hostelry
calls itself a motel, it is a motel.  If it calls itself a hotel, it is a
hotel.  Local licensing authorities do not differentiate between them and
they are regulated identically, so far as I can tell.  I'd say the
definition should be based on what is written on the sign on the hostelry."

+1

That's my main criterion for tagging an accommodation as a  motel. I agree
with Volker's points and Allan's view on this.

Happy Holidays

Dave

On Mon, Dec 24, 2018 at 6:27 AM Allan Mustard  wrote:

> Motel = MOtor hoTEL
>
> The major difference between a 'hotel" and a "motel" originally was the
> configuration of the building with respect to parking.  At a traditionally
> designed motel, the cars are parked outside the units, which typically open
> to the outdoors, not to a hallway, so that patrons of the motel may come
> and go freely to their automobiles.  Length of stay is immaterial.
>
> The first motels appeared on the Lincoln Highway in the 1920s, if memory
> serves, and had little carports capable of accommodating a Model T
> Ford-sized automobile next to a cabin (yes, the first motels featured
> cabins, not rooms in a larger building).
>
> Then along came Motel 6, so called because it charged $6 per night back in
> the day (it featured coin-operated TVs and you paid extra for everything
> but the bed, bath, and four walls).  Many Motel 6s had hallways, and that
> changed the design, but they still catered to transients en route from
> Point A to Point B.
>
> Today the main difference seems to be the sign out front.  If a hostelry
> calls itself a motel, it is a motel.  If it calls itself a hotel, it is a
> hotel.  Local licensing authorities do not differentiate between them and
> they are regulated identically, so far as I can tell.  I'd say the
> definition should be based on what is written on the sign on the hostelry.
> These are my two cents' worth based on 30+ years of travel, including a few
> cross-country trips across America as well as extensive on-ground travel in
> Mexico, Russia, and central Europe.
>
> Cheers and Merry Christmas to all!
> apm-wa
>
>
> On Sun, Dec 23, 2018 at 4:33 AM bkil  wrote:
>
>> I've made a major rewording of this tag. Please review and don't hesitate
>> to comment or improve if I've mistakenly changed the meaning of the tag:
>>
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Atourism%3Dmotel=revision=1755686=1561324
>>
>> Source: based on Wikipedia and recent mapping experience:
>> https://www.openstreetmap.org/changeset/65702446#map=9/47.1412/18.6632
>>
>> It also looks like some have used the word motel for what should have
>> been pensions and guest houses around here, I'll also fix these later.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Trailhead tagging

2018-12-21 Thread Dave Swarthout
I have tagged a few trailheads in Alaska using the tag highway=trailhead on
a node followed by a tag for its name. I was under the impression that the
tag was well-known and not in some sort of limbo. Other trailhead features
if present, e.g., information boards or maps, I generally map separately.

On Fri, Dec 21, 2018 at 9:36 PM Peter Elderson  wrote:

> Designated starting point for multiple routes into a nature area.  There
> is a designed marking pole or stele, information boards, seats or benches,
> free parking space nearby. This one is in a small village:
>
> https://www.google.nl/maps/@52.4336993,6.834158,3a,75y,191.07h,84.64t/data=!3m6!1e1!3m4!1sby0P5NTeyqR3fyrgDNqCOA!2e0!7i13312!8i6656?hl=nl
>
> Here is another one, with emphasis on Parking. On the left behind the
> parking is the actual access point to the trails.
>
> https://www.google.nl/maps/@51.6284198,5.0889629,3a,76.4y,32.53h,96.56t/data=!3m6!1e1!3m4!1sy3HdYWJ2zZ1rw1ozqJyrXw!2e0!7i13312!8i6656?hl=nl
>
> The operators are governmental bodies. They publish the lists on
> recreation websites. Each province has its own list. VVV of course
> lists/presents them as well.
>
>
> These points are designed for trail access.
>
> Op vr 21 dec. 2018 om 14:31 schreef Andy Townsend :
>
>> Can you give a few examples of what trailheads are to you?  There's a
>> clearly defined American concept, it isn't not really used much in British
>> English.  Also what do you mean by "official" below - is there some kind of
>> VVV list or similar?
>>
>> Best Regards,
>>
>> Andy
>> On 21/12/2018 11:54, Peter Elderson wrote:
>>
>> I would like to revive the trailhead proposal,
>> https://wiki.openstreetmap.org/wiki/Proposed_features/trailhead
>>
>> After discussions in the Dutch user community, a list of all Dutch
>> trailheads was compiled and systematically entered as nodes tagged
>> highway=trailhead, name=, tourism=information,
>> information=board or map. Many trailheads were already present in OSM,
>> there we just did some additional tagging.
>>
>> In the US, trailheads are all maintained on OSM by a national operator.
>> Japan has lots of trailheads, I don't know how they are maintained. In
>> Europe, no systematical OSM-tagging appears to take place, except for the
>> Dutch base.
>>
>> I think it deserves a push.
>>
>> Any thoughts on the matter?
>>
>> --
>> Vr gr Peter Elderson
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Vr gr Peter Elderson
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

2018-12-06 Thread Dave Swarthout
I have no idea how to tag a shop selling *salumeri*  but I do know that
shop=butcher and butcher=pork is totally wrong for a shop that sells cold
cuts. Johnparis is quite right that a butcher is someone who slices and
packages raw meat. In American English, the closest approximation for a
shop selling assorted cold cuts is deli. It's very unlikely that a butcher
would ever be involved in a deli operation.

Dave

On Thu, Dec 6, 2018 at 4:29 PM Johnparis  wrote:

> Cold cut, in American English anyway, is any sliced meat that is packaged
> and sold chilled. Often pork based (ham and sausages like bologna are
> popular) but also other meats like turkey.
>
> shop=butcher + butcher=pork is what the wiki suggests.
>
> I personally think of a butcher as someone who slices and packages raw
> meat, but the wiki is clear that shop=butcher is for any sort of meat shop.
>
> John
>
>
> On Thu, Dec 6, 2018 at 9:46 AM Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> On 5. Dec 2018, at 22:08, Sergio Manzi  wrote:
>>
>> P.S.: ... but if I want my *salumeria *to show up on the map, I *have to*
>> "*lie for the rendering*" and tag it as a shop=deli: but'I'm not happy
>> at all...
>>
>>
>>
>> no you don’t have to, it will rather be counterproductive, because if
>> everybody does like this they will never reach the limit that the rendering
>> team will consider rendering them.
>>
>> A dictionary lookup suggests “cold_cut”, are there any native speakers
>> who know what a salumeria is and if that term could work/apply ?
>>
>> 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
>


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


Re: [Tagging] How to map a sliding section of the Alaska Pipeline

2018-11-26 Thread Dave Swarthout
Michael,
Thanks for the suggestions. I'm on the road so can't reply in detail but
I'll get back to you and the list before long.

Dave

On Sun, Nov 25, 2018 at 5:17 PM Michael Patrick  wrote:

> > ... There is a short section of the Trans-Alaska pipeline that crosses a
> well-known fault line where it is attached to slides to allow lateral
> movement in case of an earthquake. I split the pipeline way and added a
> note to the section but that probably isn't visible to most data consumers.
> Any ideas?
>
> OMG, Thank You Dave!
>
> I love ontological edge cases -  and this is certainly good one. :-)
>
> I'd add something like "Deliberate Operator Movement" or "Directed
> Movement" or some such to my description. These sort of joints are quite
> common once one is cued to notice them.
>
> A friend of mine pointed on that a clear distinction was the pure
> unidirectional ( along one path ) of rail-lines, whether it's road trains,
> maglevs, or rail roads. There's no up/down or side ways component except
> through a split, curve, or join in the track, where in the case of a
> movable gantry there is usually a lifting, rotating, or conveying occurring
> in addition to along the track axis. And as an additional note, regardless
> of the type of point of contact ( rail, tire, magnetic ) the term for what
> directs the travel is a 'track' ( unfortunately already occupied by the
> road term ).
>
> > If it is moveable it is a gantry crane.  A gantry per se can be
> immobile, right?
>
> The immobile case ( like the fixed support for signs ) isn't that common,
> as far as I could tell - in the sign case, the immobile case was more
> commonly more simply called a 'bridge', probably because the spanning part
> on even movable gantries and cranes is called a bridge.
>
> > Maybe not a rail line in the conventional sense, but I tagged an
> (unfortunately disused) children's train in Ashgabat
> https://www.openstreetmap.org/way/429019713 as a railway even though it
> goes around and around, or used to, and has no destination.
>
> Another excellent case. Although it might be said t the origin and
> destination merely have the same location, and differ along time and
> direction path, , and as I noted, it's primary feature is as a conveyance,
> not 'positioning' something for an action. Here the 'rails are rails' in
> two uses (
> http://www.davidheyscollection.com/userimages/0001-dh-thornaby-roundhouse.jpg
> ), but only one is the 'conventional sense' of a rail line - the other rail
> is for positioning.
>
> Michael Patrick
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-24 Thread Dave Swarthout
@Paul,

Agree on the confusion and difficulty in using those blasted protect_class
numbers. Let those issues be resolved in the boundary tag. I'm already
tagging using protect_class along with the boundary tag and for insurance
toss in the boundary:type tag. It's a lot of tagging that could be
simplified immensely if we could just settle on one. IMO,
boundary=aboriginal_lands says it all.

On Sun, Nov 25, 2018 at 8:23 AM Paul Allen  wrote:

> On Sun, Nov 25, 2018 at 12:40 AM Alan McConchie 
> wrote:
>
>>
>> Should we use the single tag boundary=aboriginal_lands for these areas?
>> Or should we deprecate that tag (in other words, reject the proposal) and
>> instead use boundary=protected_area + protect_class=24?
>>
>
> My gut feeling is that protect_class is an abomination.
>
> Numbers are fine, where numbers are appropriate.  Like the address of a
> house, or the service
> number for a bus, or the elevation of a peak.  Protect_class is a
> horrible, ugly mess.  You cannot
> easily figure out which value to use (first check with the WDPA, then try
> to figure out from a gigantic
> look-up table which value to use).  To make it easy for mappers, instead
> of just having a list of
> possible values like "national_park," "historical_reserve" or whatever,
> editors will need a look-up
> table (not difficult to code, but unnecessary) from natural concepts like
> "nature reserve" to 57
> (or whatever the number is).  All data consumers like apps will need a
> lookup table to translate from
> number to concept so users can make sense of it (or put up with the
> information that "You are now
> entering a 37").  People using the query tool with the standard carto will
> either have to then go through
> the wiki to do a lookup or such a lookup will have to be built into the
> code that handles queries.
>
> Gut feeling, late at night: anything has to be better than protect_class.
> I must be missing something
> since it presumably went through the approval process and passed, and
> people actually use it, but
> right now it looks like Satan conceived it to torment mappers before they
> die.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Digest, Vol 110, Issue 135 Trans Alaska oil line

2018-11-23 Thread Dave Swarthout
Hi Nick,

No, I had not. But it's a good suggestion.

On Sat, Nov 24, 2018 at 5:35 AM St Niklaas  wrote:

> Hi Dave,
>
>
> Did you thought about movable=yes just as an extra value ?
>
>
> Greetz
>
>

-- 
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] How to map a sliding section of the Alaska Pipeline

2018-11-23 Thread Dave Swarthout
This isn't a big issue but Warin's post about rails used to move big
objects.  Then someone replied with some illustrations of gantries and that
triggered my curiosity.   There is a short section of the Trans-Alaska
pipeline that crosses a well-known fault line where it is attached to
slides to allow lateral movement in case of an earthquake. I split the
pipeline way and added a note to the section but that probably isn't
visible to most data consumers.

Any ideas?

Photo here
<https://www.dropbox.com/s/209xatghack8m35/Trans_Alaska_Pipeline_Denali_fault_shift.jpg?dl=0>:
https://www.dropbox.com/s/209xatghack8m35/Trans_Alaska_Pipeline_Denali_fault_shift.jpg?dl=0

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


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

2018-11-17 Thread Dave Swarthout
Despite the remaining problem of just how best to map the Iarge Alaskan bay
that started this conversation, it's been very interesting. For now, I'll
just let it remain as a node and hope that a better label rendering
solution for a water body as large as Cook Inlet comes along during my
lifetime. I will decide whether to use multipolygons to show smaller bays
and straits on a case by case basis.

Thanks to all for your contributions.

Alaska Dave


On Sun, Nov 18, 2018 at 4:51 AM Paul Allen  wrote:

> On Sat, Nov 17, 2018 at 9:30 PM Kevin Kenny 
> wrote:
>
>>
>> It is sounding as if Frederik and Christoph are willing to tolerate
>> limited experiments as long as we mostly don't damage the coastline,
>>
>
> Life would be so much easier if we had a sandbox.
>
>
>> and keep our areas small enough not to break the toolchain.
>>
>
> I was contemplating generalizing Cardigan Bay.  Maybe a few dozen nodes.
> But now you've made me
> worry that it's not just the node count I should be concerned about but
> also the size of the area
> enclosed.  Like I said, if only we had a sandbox...
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-16 Thread Dave Swarthout
That node too was left behind by mistake. I just now deleted it.

The problem with using a way is that I can't see it. And I bet most current
map products can't render it either. That someone with special cartographic
skills can render it is good to know but it doesn't really help my
situation. If those nodes can do the job you claim they for them, then
someone needs to make it work that way on OSM, or OSMAnd.

I don't know why Daniel made the choice to map that huge bay with
multipolygons but calling it pollution isn't going to help matters.

On Fri, Nov 16, 2018 at 6:26 PM Christoph Hormann  wrote:

> On Friday 16 November 2018, Dave Swarthout wrote:
> >
> > To answer Christoph's question about Chickaloon Bay and the node for
> > the same bay, I simply forgot to delete the redundant node after I
> > finished. Interestingly, the label for the new multipolygon fell only
> > slightly to the east of the node so its placement was fairly
> > accurate. However, in order to see the name on that node, one must
> > zoom in so far that you have no idea whatsoever of the physical
> > extent of the actual object. I know, that's a rendering issue. Still,
> > the reason many of us enjoy mapping is so we can see the results of
> > our labors somehow, preferably on a map, so it's a powerful incentive
> > to do things in such a way that results in visualization. There is an
> > enduring tension in the OSM world that we're always seeking to
> > balance and this discussion is largely about where that balance lies.
>
> Yes, as already said i understand that and this is why i do not
> primarily blame you or other mappers for using non-verifiable drawings
> to map bays and straits but Daniel for incentivizing that for
> ultimately selfish reasons.
>
> As a data user i am relatively relaxed on this because it is not a big
> problem to reduce all these polygon drawings to a node before i use the
> data.  But i would not want to map or do data maintainance in an area
> with such drawings.  I see this as a problem of pollution control.  Not
> to litter the environment, not to pollute the air just because it is
> convenient.
>
> > Also, sorry, I cannot see how representing a strait the size and
> > importance of the Shelikof Strait (every Alaskan knows about this
> > famous water passage) with a single way could work. A way is totally
> > inadequate for such a task. Maybe that trick would work for a narrow
> > strait that resembles a fjord but not for one as large as this one.
>
> Yes, i completely understand how this seems this way but i also know
> that this is due to you not realizing how fairly easily you can
> computationally assess the shape and the size of the street from a
> single properly placed node.  I will keep this case in mind for the
> future as a good example to illustrate that.
>
> Note the current node:
>
> https://www.openstreetmap.org/node/561722
>
> is of course not suitably placed.  Correct position would be around
> here:
>
>
> https://www.openstreetmap.org/?mlat=57.9877=-154.0407#map=9/57.9877/-154.0407
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-15 Thread Dave Swarthout
s 'place a
> single- or multi-line upright label on a point' needs the information.
> You've given a very clever 'second best' approach to determining that
> information when only a point is available - and I'm likely to find myself
> using it because of the current state of the map data, so thank you for
> that.
>
> Nevertheless, I think it would be much preferable to allow mappers to
> communicate their intent. When mappers add a bay, inlet, gulf, fjörd, ...
> to the map, they can be presumed to know what extent they would like the
> object to have. What harm does it do if we give them a way to describe that
> knowledge to others? Why the insistence on restricting the data model so
> that we must use a brittle reconstruction technique rather than allowing
> mappers to enter the extent of the object and data consumers to see it?
>
> The two arguments that I hear so far appear to amount to:
>
> - if any portion of an object's boundary is spatially indefinite, then
> that object may not be represented as an area.
>
> Farewell to several counties and townships in the northern part of my
> state, then.
>
> - carrying the data for bays is not scalable.
>
> In that case, we need to open a much broader discussion of general
> categories of data that we need to exclude from OSM in order to manage the
> size of the data base or the complexity of the computations. I surely don't
> want to start seeing conflicts between better- and worse-mapped regions
> over perceived inequities in the allocation of server resources! If instead
> of data volume, the concern is the complexity of processing large objects,
> then it would perhaps be better addressed by a rule that "no area feature
> should exceed more than X km², have a mapped boundary length of y km, or
> require more than z nodes for its representation" - and then work out how
> we want to handle exceptions like countries, large islands, and large lakes
> and seas. (That's then the right time to discuss what to do about bays,
> straits, estuaries, and similar features.) The argument would also have to
> distinguish between the cost of maintaining the data on the server - the
> real OSM - and the cost of processing the data in the OSM-Carto rendering
> chain - OSM's public face. If there's a way to have the information in the
> actual OSM database but not in the main renderer, or have the pipeline
> generalize it to a lower-cost but less informative form, that would be
> better than discarding it entirely.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-15 Thread Dave Swarthout
@Christoph,

Thanks for the feedback and the references to the previous discussions
about this topic. The first reference to an earlier discussion on this list
was particularly useful. From your email and that thread, I gather that you
are opposed to mapping bays and straits as multipolygons. That comes
through loud and clear.  But there are others who disagree. I think both
sides make valid arguments and I tend to agree with those who say go ahead
and use multipolygons. It seems to me a better choice but that choice is
not without its drawbacks. One I've already mentioned, and it was touched
on in the thread as well, that of adding complexity to the map. You say
that should be left to renderers to deal with, even imperfectly, in ways
that are difficult for the non-specialist to understand. Okay, I'm fine
with that. It's a ton of work to create multipolygons in order to force OSM
to represent bays the way I would like to see them, so I'm not going to
continue my practice of converting them to multipolygons. Nor will I try to
"simulate" the Cook Inlet with an approximate area. a "labeling polygon",
as you described it. I reckon I'll have to leave that to better future
rendering software

But the thread was interesting and I would like to make a few observations
while I have your attention. Some have argued that defining the outside of
a bay is difficult. I think that is not a big problem in my part of the
world because I can access a very reliable source of geographic information
via the USGS Topo map overlay.  Most bays are fairly easy to outline with
coastline and a simple way connecting the two extremes. Straits too are
usually fairly easy to define spatially with the help of those maps.
Straits are important geographic features and I think the use of
multipolygons to define them is a useful methodology. Absolute accuracy is
hard to attain but it doesn't matter all that much. What someone piloting a
fishing boat in heavy weather wants to know is, am I in this bay or am I in
the Shelikof Strait?  If the Shelikof Strait (240 km long and 40-48 km
wide), is represented by a mere node, I doubt that it would be possible to
know one way or the other.

However, because of its size and importance to Alaskans, I used the trick
you advised against. I used segments of the Kodiak Borough boundary to
define the north and south edges of the strait and then simply closed the
area with straight way segments to create an area rather than adding
hundreds of small sections of coastline to a large multipolygon created for
the purpose. Not very accurate but better IMO than a node.

I might go back and change that someday but at the moment I'm prepared to
leave it as it is. There are so many other mapping chores to do in Alaska
it boggles the mind.

Cheers,

Dave





On Thu, Nov 15, 2018 at 6:11 PM Christoph Hormann  wrote:

> On Thursday 15 November 2018, Dave Swarthout wrote:
> > [...]
> >
> > I was thinking it would be much easier and perhaps even better to
> > just draw an approximate shape consisting of maybe 20 or 30 nodes,
> > big enough to define the area and cause it to render, but easy to
> > draw and without involving any multipolygons. The issue here is
> > admittedly one I am pursuing to get these water bodies to render in a
> > manner proportional to their size and I suspect that many will be
> > against it on that basis alone. Still, I thought it worthwhile to
> > mention my idea here and see what you think about it as a "shorthand"
> > solution.
>
> I think it is good you bring this up because many mappers have been
> doing exactly that without asking - See for example:
>
> https://www.openstreetmap.org/way/548210592
> https://www.openstreetmap.org/way/544856564
>
> To put it right upfront:  This is a bad idea.  As you say the main
> motivation for doing this is to make a bay show up in the map.
> OSM-Carto has made the decision to incentivize this kind of mapping -
> and as i like to point out to derivate from its self declared goal to
> support mappers in consistent mapping towards steering mappers to map
> in a way that is convenient for style developers.
>
> The 'polygons is universally the preferred way of mapping no matter if
> verifiable or not' and 'way_area equals cartographic importance'
> concepts have been meanwhile extended to natural=strait in OSM-Carto -
> thereby not only incentivizing against mapping with nodes but also
> against mapping with linear ways.
>
> To be fair:  There are other map styles that do essentially the same so
> it is not appropriate to exclusively blame OSM-Carto for this but it is
> the only style that due to being rendered on OSMF infrastructure has a
> true obligation not to do this.
>
> Mapping bays with polygons is always non-verifiable to a large extent.
> Mapping bays with polygons

[Tagging] Using multipolygons to map bays in Alaska

2018-11-14 Thread Dave Swarthout
Since the long thread I started about multipolygons  [1
<https://lists.openstreetmap.org/pipermail/tagging/2018-October/040062.html>]
is sort of winding down, I thought it best to start a new one to discuss
something I've been doing since learning from that thread of the amazing
power of the multipolygon data structure. Alaska has hundreds of bays and
straits that have been added to OSM as nodes many years ago via an import
(Tiger?). The nodes contain useful information but because they're only
nodes cannot provide any visual representation of the size or extent of
bigger bays and straits. I've begun to use multipolygon relations to show
them more prominently using sections of coastline as the ways and then
drawing a connecting way across the mouth of the bay or strait to complete
the outer ring. This structure then defines the bay and when rendered it
shows up nicely on the OSM slippy map.

However, this method means that under certain circumstances some of those
ways end up as members of several multipolygons. For example, the coastline
might be part of a boundary, and in addition define a wooded or wetland
area so it might be confusing to new mappers who might be put off by the
complexities, as I was for a long time. That's one consideration. The other
is the question about using this technique to map truly large bays like
Cook Inlet. This is the reason I'm posting this question. Here is the first
paragraph of the Wikipedia entry for the Inlet:

Cook Inlet (Dena'ina: Tikahtnu) stretches 180 miles (290 km) from the Gulf
of Alaska to Anchorage in south-central Alaska. Cook Inlet branches into
the Knik Arm and Turnagain Arm at its northern end, almost surrounding
Anchorage. On its south end merges with Shelikof Strait, Stevenson
Entrance, Kennedy Entrance and Chugach Passage.

So, I could mouse along the coastline adding pieces of it to a new relation
until I have the entire Inlet surrounded, then draw a way from Elizabeth
Island on the east side to the other side to define its mouth. I copy the
tags from the existing node to the multipolygon and delete the node. But
with a water body the size of Cook Inlet, that's a lot of work. I mapped
Cook Inlet's Turnagain Arm [2
<https://www.openstreetmap.org/relation/8921978#map=9/61.1074/-149.5541>]
the other day and it involved adding 14 ways as outers. How many will a
multipolygon covering the entire Cok Inlet require?

I was thinking it would be much easier and perhaps even better to just draw
an approximate shape consisting of maybe 20 or 30 nodes, big enough to
define the area and cause it to render, but easy to draw and without
involving any multipolygons. The issue here is admittedly one I am pursuing
to get these water bodies to render in a manner proportional to their size
and I suspect that many will be against it on that basis alone. Still, I
thought it worthwhile to mention my idea here and see what you think about
it as a "shorthand" solution. Besides, I'm betting some other useful
information will issue from the discussion.

Dave

[1]
https://lists.openstreetmap.org/pipermail/tagging/2018-October/040062.html
[2] https://www.openstreetmap.org/relation/8921978#map=9/61.1074/-149.5541
-- 
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


Re: [Tagging] Petroleum extraction

2018-11-13 Thread Dave Swarthout
The big oil fields in Alaska have no pumping rigs. There are hundreds of
wellheads littering the landscape but none are what I would think of as a
pumping rig. I don't really know much about the oil industry but I have
mapped a bunch of wells in Prudhoe Bay and was surprised to learn just how
numerous those wells are in a big field like Prudhoe. I'm presuming that
the oil in Prudhoe is under enough pressure to push it to the surface,
unlike in Texas or Pennsylvania where the pumping rigs that lift the oil to
the surface, shown in the first reference, are in common use.

Also, FYI, the tag used for the Trans-Alaska Pipeline to indicate what is
being carried is substance=oil. I chose that over content=oil because it
seemed to me that content was more commonly applied to tanks. There is no
clear guideline for choosing one over the other AFAIK.

Download and take a look at this with JOSM and DigitalGlobe-Premium imagery
if you're interested. Most of the BP waypoints are in the Prudhoe Bay area.
(See Bp Exploration (Alaska) Inc1004, for example). I'm not sure now where
I obtained it or how current the data is but it's interesting nonetheless.
It contains coordinates for all the oil wells in Alaska.

https://www.dropbox.com/s/shohs21a7us3pvc/All%20Alaska%20Oil%20Well%20WPs.gpx?dl=0

Cheers,

Dave

On Tue, Nov 13, 2018 at 9:00 PM Daniel Koć  wrote:

> Hi,
>
> We are trying to make rendering for petroleum wells in OSM Carto, but it
> seems to be twisted:
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/3494
>
>
> There are two different, probably overlapping tags for that, and both
> have some problems:
>
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpumping_rig
>
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpetroleum_well
>
>
> For pumping rig it's clear that there's a rig on the ground and you can
> even add what is being extracted, but it's not clear if this should be
> substance=oil or content=oil.
>
> For petroleum well it's not clear whether there is a rig or not (there
> are some sealed petroleum wells with no other equipment). Tagging both
> is impossible in a simple way, since both use man_made key.
>
> My idea is to simply move all the petroleum wells with a rig into
> man_made=pumping_rig + substance/content=oil.
>
> What do you think about it?
>
>
> --
> "Excuse me, I have some growing up to do" [P. Gabriel]
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] رد: رد: New rag to draw node name with rotate angle

2018-11-10 Thread Dave Swarthout
Martin's example illustrates what I've been doing with bays and straits in
Alaska lately. Before I started doing this, all the bays in Alaska were
marked with simple nodes that were imported many years ago from GNIS or
somewhere. I hated that because they were all but invisible on most map
renderings. Now, I split the coastlines that define the bay into ways which
then become the boundaries of the bays, exactly as Mariusz Staniszewski did
with the Bay of Biscay. Finally, after looking at the bay's extent on the
USGS Topo map, I close the multipolygon with a way defining the end of the
bay. I copy the GNIS node tags to the multipolygon and then delete the
node.  Now, the GNIS data, the names and extent show up beautifully on the
OSM slippy map and presumably many other maps.

Straits were not marked in any way, neither by nodes from GNIS or other
mappers (Alaska has very few mappers and I'm the top OSM contributor
there). Now, with the help of multipolygons, I have a way to define straits
or narrows and to have the names render nicely. Take a look at the simple
multipolygon for Sitkalidak Passage (id:8891978) here:
https://www.openstreetmap.org/relation/8891978#map=14/57.2123/-153.2423

So, it seems that label rendering is a function of both how a place like a
bay or strait is mapped as well as the realities of displaying labels in a
readable fashion. I'm excited to have put into place a system that works
quite nicely and doesn't duplicate any nodes to accomplish something I've
wanted to do since I started using OSM.

Cheers,

Dave



On Sun, Nov 11, 2018 at 3:14 AM Mateusz Konieczny 
wrote:

> 10. Nov 2018 14:52 by hubais...@outlook.com:
>
> For OpenStreetMap rendrer:
>
> *https://www.openstreetmap.org/search?whereami=1=-1.406%2C0.220#map=3/-18.56/24.43
> <https://www.openstreetmap.org/search?whereami=1=-1.406%2C0.220#map=3/-18.56/24.43>*
>
> *Somalia, Madagasikara,Yemen **اليمن, Oman **عمان will be best if they
> have a rotate angle*
>
> *India does not appear, Kynia has a chance to appear if Somalia has rotate
> angle also Ghana have chance to appear if down vertically*
>
>
> Note that Default map style  on the OSM main page is not using place nodes
> for rendering countries.
>
>
> It is using relations like https://www.openstreetmap.org/relation/305138
>
>
> And, yes it is ignoring label role as it is a horrible idea.
>
>
> --
>
>
> Different map styles require different label placement (as different map
> styles display
>
>
> different objects, may use labels in different languages, labels may use
> different style
>
>
> and it may be desirable to avoid blocking some objects with label - for
> example standard map
>
>
> may prefer label of coastal town to be placed on sea, map displaying sea
> routes would prefer
>
>
> to place town label inland). As result placement of this nodes is
> optimized for specific map styles,
>
>
> making them form of tagging for the renderer. )
>
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-10 Thread Dave Swarthout
Mateusz,

The problem is how to get enough agreement and understanding to correct the
Wiki. You can see how difficult that would be when even the regular
contributors to the tagging list can't agree on what's correct. Imagine how
overwhelmed new mappers must feel when they work on their first relations.
Hell, until a few weeks ago, I tried never to get involved with any but the
simplest ones. I have created many riverbank multipolygons and grouped a
few geographic features, like the Groble ponds that began this thread, but
even those uses involved lots of back and forth among us.

Yes, the Wiki is far from perfect. That's a big reason we have these
endless debates. But how should we go about fixing it? An additional issue
for me is the difficulty of adding information to the Wiki. I've been a
programmer in my earlier life so I'm not a newbie when it comes to looking
at and interpreting code but the markup language for the Wiki is, IMHO,
simply horrible.  Someone once suggested I write up a Proposal for a tag I
was thinking about. No thanks. I have better things to do with my time than
to try to learn how that infernal formatting works.

Best,
Dave

On Sun, Nov 11, 2018 at 3:21 AM Mateusz Konieczny 
wrote:

> 8. Nov 2018 02:59 by daveswarth...@gmail.com:
>
> Another part of the problem is the Wiki that we treat as our bible.
>
>
> I  am not sure whatever anyone present on this mailing list is doing this.
> In case that someone is doing it: remember that WIki is missing plenty of
> documentation
> and many parts are outdated or represent rather who was last editor rather
> than reality.
>
> Anyway, I encourage everybody to improve problematic pages.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Estimated values for height

2018-11-09 Thread Dave Swarthout
You can also use height=* for both and add a "source:height=estimated /
measured" tag with that to have a value that is usable by the apps and
tools but still keeping the information that it was only estimated ! ;-)

An excellent solution, Lionel

On Fri, Nov 9, 2018 at 5:06 PM marc marc  wrote:

> look at the current values in height, you understand from their
> round values that they are massively estimated.
>
> my preference is therefore to use height and make 2 changset
> to put a changeset tag related to the source
> of the measurement: measured <> estimated
>
> Le 09. 11. 18 à 10:57, Lionel Giard a écrit :
> > You can also use height=* for both and add a "souce:height=estimated /
> > measured" tag with that to have a value that is usable by the apps and
> > tools but still keeping the information that it was only estimated ! ;-)
> >
> >
> > Lionel
> >
> >
> >
> > Le ven. 9 nov. 2018 à 10:19, Dave Swarthout  > <mailto:daveswarth...@gmail.com>> a écrit :
> >
> > There is already an est_width tag (Taginfo 77,000). I see no reason
> > why you couldn't use est_height, which has over 1000 instances in
> > Taginfo.
> >
> > Dave
> >
> > On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
> > mailto:cascaf...@gmail.com>> wrote:
> >
> > I'm going to import a small dataset of trees. Some tree heights
> > are defined as "measured", some as "estimated".
> >
> > About estimated values, I've found a wiki definition only for
> > width [1]: shall I
> > derive an est_height tag,
> > go for most popular taginfo solutions,
> > simply assign an estimated value to height tag?
> >
> >
> >
> > [1] https://wiki.openstreetmap.org/wiki/Key:est_width
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > --
> > Dave Swarthout
> > Homer, Alaska
> > Chiang Mai, Thailand
> > Travel Blog at http://dswarthout.blogspot.com
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org <mailto: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
>


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


Re: [Tagging] Estimated values for height

2018-11-09 Thread Dave Swarthout
There is already an est_width tag (Taginfo 77,000). I see no reason why you
couldn't use est_height, which has over 1000 instances in Taginfo.

Dave

On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni 
wrote:

> I'm going to import a small dataset of trees. Some tree heights are
> defined as "measured", some as "estimated".
>
> About estimated values, I've found a wiki definition only for width [1]:
> shall I
> derive an est_height tag,
> go for most popular taginfo solutions,
> simply assign an estimated value to height tag?
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Key:est_width
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-09 Thread Dave Swarthout
water)
> allways belong to the members and not any encompassing relation such as
> relation:waterway.
> man_made=pipeline looks like on of those tags I would always put on the
> members,
> not the relation.
>
> Richard
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-08 Thread Dave Swarthout
Also agreed.
I'm not saying anything about the route tag. We're talking about tags other
than route or type, which actually set up the relation. The additional tags
that describe the route or multipolygon either go on the relation or the
ways depending on their scope, but not both.

On Thu, Nov 8, 2018 at 5:31 PM Peter Elderson  wrote:

> And route=foot does not mean al the components are footpaths.
>
> Op do 8 nov. 2018 om 11:05 schreef Andy Townsend :
>
>> On 08/11/2018 01:59, Dave Swarthout wrote:
>> > To my way of thinking, a tag in the relation implicitly applies to
>> > every member of the relation.
>>
>> No.  Think of a long-distance footpath - that may have an operator, or
>> it may have tags that apply specifically to the footpath route. It may
>> also run along a road for a short distance - it doesn't mean that the
>> footpath "operator" is the "operator" of the road.
>>
>> Best Regards,
>>
>> Andy
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Vr gr Peter Elderson
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-08 Thread Dave Swarthout
I totally agree, Andy. So yes, if someone has tagged the relation with an
operator and in reality, there are different operators (or none) for some
parts of the route, those parts should have tags to indicate the change.

My illustrative case involves a pipeline that (AFAIK) has only one operator
(oops, owner) so it's not the same situaiton. But don't hold me to
specifics. I'm trying to illustrate a point and my choice of tag and value
to do it may have been wrong. I just checked Wikipedia and the pipeline is
owned by the Alyeska Pipeline Service Company so please substitute owner
for operator just for the purposes of the illustration.

At any rate, using my reasoning, if an operator or owner tag doesn't apply
to the route as a whole, it should appear on the individual ways and not in
the relation. However, for the TAPS, such items as owner apply to the
entire route, just as do Wikidata and Wikipedia tags, substance, etc. IMO,
those tags belong on the relation and are not necessary on the individual
ways.

Best,
Dave




On Thu, Nov 8, 2018 at 5:05 PM Andy Townsend  wrote:

> On 08/11/2018 01:59, Dave Swarthout wrote:
> > To my way of thinking, a tag in the relation implicitly applies to
> > every member of the relation.
>
> No.  Think of a long-distance footpath - that may have an operator, or
> it may have tags that apply specifically to the footpath route. It may
> also run along a road for a short distance - it doesn't mean that the
> footpath "operator" is the "operator" of the road.
>
> Best Regards,
>
> Andy
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-07 Thread Dave Swarthout
Yves,
" mapping a way is simpler than a relation for most."
I totally understand that. In fact, in the first of those references, the
opening statement is " Usually the pipeline is mapped just with simple
ways".I think that's a valid approach for short pipelines but this thing is
huge. Whoever created it used a relation for whatever reason and I think it
was a good decision. Now, however, we're faced with mapping and
understanding it. The Wiki hasn't been much help and, obviously, there is
disagreement among member of this group as to what is right and proper.

Trying to understand exactly what a relation is and how it relates to its
constituent parts was, and is, the reason for my comments to this thread.
It's been a very valuable thread for me because through it, I've learned a
lot. The video put together by Adam Franco has completely revolutionized my
mapping of complex boundaries and water bodies. this short tutorial.
<https://youtu.be/x7SPb0JtheA> Thanks again, Adam

Cheers,
Dave

On Thu, Nov 8, 2018 at 12:21 PM Yves  wrote:

> Dave,
> Not that what you say doesn't make sense, cause it does.
> However I just think that the wiki is not the bible (it's a wiki),
> secondly OSM is not that square as it is made to be edited by hand.
> Keep it simple here just means that mapping a way is simpler than a
> relation for most.
> Yves



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


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

2018-11-07 Thread Dave Swarthout
irst one is
obvious but the second and third? What would a route of pipeline markers
be? What about a route of pipeline stations? One wonders where these
examples came from. An email list? Or are they just reasonable guesses made
by someone who was pressed for time and wasn't very thorough in vetting the
choices he left us?

It's no wonder we're confused about pipeline routes.

That said, I need to get back to my mapping projects. I've tried everything
I can think of to justify my actions and it's wearing me out. I promise not
to change any of your previously tagged ways on relations. You guys can
continue to tag the ways on relations if you wish. I'll wait patiently for
the day when map products fully understand what a relation is and can
render it properly without tagging each and every member way.

Respectfully,
Dave


On Thu, Nov 8, 2018 at 3:55 AM Paul Johnson  wrote:

> On Wed, Nov 7, 2018 at 2:07 PM Yves  wrote:
>
>> Agreed with Martin here, I would be amazed that the name of a pipeline
>> would contradict the name of one of its section being something else than a
>> pipeline.
>>
>>>
>  I'm not super familiar with them compared to railroads, but similar
> naming conventions exist.  Branches and trunks often have differing names
> while being part of the same overall pipeline.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-07 Thread Dave Swarthout
Thanks,
I added it to my styles and promise to try it soon.

Dave

On Wed, Nov 7, 2018 at 4:12 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Dave,
> reg. a rule for mkgmap: A simple approach would be to add a rule in the
> relation style so that the tag man_made=pipeline is added to all way
> members
> of the relation which don't already have a man_made tag:
> #pipelines
> type=route & route=pipeline
> {
> apply way {
> add man_made=pipeline;
> }
> }
> Maybe use set instead of add to catch cases like relation 3220256 where
> some
> long ways are tagged as man_made=cutline
> I leave it to you to find out how you can transfer the other tags like the
> name of the route relation. The default style contains samples for that.
>
> Gerd
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-06 Thread Dave Swarthout
PS:

Gerd and I are not at war here. We just don't agree on the correct way to
proceed. In fact, I have had lots of help from him when developing maps for
my Garmin and will need his help in the future, no doubt. Maybe to convince
him to write the code in mkgmap to better "see inside" relations to dig out
the details. I know for a fact that without a man_made=pipeline tag on
those ways, my current style sheet won't find them and will be unable to
render them. Unless I get help from Gerd. LOL

On Wed, Nov 7, 2018 at 2:27 PM Dave Swarthout 
wrote:

> It's true. Gerd and I have gone round and .around on this topic. Gerd has
> tried to convince me that I should not remove any tags of the ways
> contained in the existing Alaska pipeline relation and I'm convinced that
> the only tags that belong on those ways are the ones that make that
> particular way different from any other ways. Hence, tags like location,
> and bridge, properly belong on the ways. Obviously, you can't include
> bridge=yes and layer=1 in any top level relation. Those sorts of attributes
> belong on the way and only on the way. I have tried to convince him that
> any attribute or characteristic that applies to the pipeline in its
> entirety, belongs on the relation and not on the pipeline way itself. It
> doesn't hurt to have them there but it's unnecessary and I also argue,
> having those duplicated tags makes maintaining the relation rather messy.
>
> I provided two examples from the Wiki and a part of a response earlier in
> this thread from Kevin Kenny to support my argument that state that
> individual ways in a multipolygon or relation should not be tagged unless
> their characteristics require it.  If you're working with a route=road and
> the surface changes, you split the way and mark it so. Same with maxspeed
> or number of lanes. The characteristics are those of the way, not the
> entire route, and rightly belong only on the way.  In the case of the
> pipeline, tags like man_made=pipeline, substance=oil, operator, Wikipedia
> and Wikidata tags, belong in the relation. The people who first added the
> pipeline to OSM did it both ways, probably to guarantee that it would be
> visible to OSM or other data consumers, but I don't know.
>
> I believe the people that cautioned us in the Wiki, people that I assume
> know more about it than either Gerd or me, to add tags to a way contained
> in a relation only when its characteristics or attributes are different
> from the overall route characteristics. I take their meaning literally.
> Gerd disagrees but gives no proof for his assertion.
>
> So there you have it. We're stuck.
>
> Dave
>
>
>
> On Wed, Nov 7, 2018 at 12:27 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi all,
>>
>> after reading the last comments in this thread I tried again to convince
>> Dave that the rather special rules for multipolygon relations cannot be
>> used
>> for all types of relations, esp. not those with route=pipeline and that he
>> should not remove tags like man_made=pipeline from ways of such a
>> relation,
>> see this long discussion:
>> https://www.openstreetmap.org/changeset/64027881
>>
>> I give up now because for me a type=multipolygon relation is something
>> completely different and Dave insists that it is are not. Seems we are
>> both
>> frustated now :-(
>>
>> Gerd
>>
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>


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


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

2018-11-06 Thread Dave Swarthout
It's true. Gerd and I have gone round and .around on this topic. Gerd has
tried to convince me that I should not remove any tags of the ways
contained in the existing Alaska pipeline relation and I'm convinced that
the only tags that belong on those ways are the ones that make that
particular way different from any other ways. Hence, tags like location,
and bridge, properly belong on the ways. Obviously, you can't include
bridge=yes and layer=1 in any top level relation. Those sorts of attributes
belong on the way and only on the way. I have tried to convince him that
any attribute or characteristic that applies to the pipeline in its
entirety, belongs on the relation and not on the pipeline way itself. It
doesn't hurt to have them there but it's unnecessary and I also argue,
having those duplicated tags makes maintaining the relation rather messy.

I provided two examples from the Wiki and a part of a response earlier in
this thread from Kevin Kenny to support my argument that state that
individual ways in a multipolygon or relation should not be tagged unless
their characteristics require it.  If you're working with a route=road and
the surface changes, you split the way and mark it so. Same with maxspeed
or number of lanes. The characteristics are those of the way, not the
entire route, and rightly belong only on the way.  In the case of the
pipeline, tags like man_made=pipeline, substance=oil, operator, Wikipedia
and Wikidata tags, belong in the relation. The people who first added the
pipeline to OSM did it both ways, probably to guarantee that it would be
visible to OSM or other data consumers, but I don't know.

I believe the people that cautioned us in the Wiki, people that I assume
know more about it than either Gerd or me, to add tags to a way contained
in a relation only when its characteristics or attributes are different
from the overall route characteristics. I take their meaning literally.
Gerd disagrees but gives no proof for his assertion.

So there you have it. We're stuck.

Dave



On Wed, Nov 7, 2018 at 12:27 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
> after reading the last comments in this thread I tried again to convince
> Dave that the rather special rules for multipolygon relations cannot be
> used
> for all types of relations, esp. not those with route=pipeline and that he
> should not remove tags like man_made=pipeline from ways of such a relation,
> see this long discussion:
> https://www.openstreetmap.org/changeset/64027881
>
> I give up now because for me a type=multipolygon relation is something
> completely different and Dave insists that it is are not. Seems we are both
> frustated now :-(
>
> Gerd
>
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-04 Thread Dave Swarthout
Let me try to clarify what I'm saying again. Gerd writes:

If we follow Daves idea one might create a relation combining a few things
that have the same tag, e.g. all building=residential in a town, name it
something like "residential buildings" and finally remove the tags from
those buildings. I hope nobody thinks this would be a good idea.

I m would never do anything like that. If you can follow my reasoning,
you'll see that for the example you're using my argument would say that
those ways that comprise the buildings would stay on those ways and not on
the relation. That's' because the object "building" requires a way that is
tagged specifically as a building and as such, according to my reasoning,
properly belongs on the way and only on the way. If the buildings are part
of a group that is an entity, like a university for example, then create a
relation and place its name there along with whatever other tags apply to
the university as a whole; owner, website, etc., and then add the building
ways to it. The tags for the buildings, each with the tags that apply to
it, be it office, dormitory, whatever, are placed on the way only and the
buildings render as they do if even if they were not part of a relation.
One must look a little closer to determine that they're part of something
larger.

Gerd also said:

"I think Dave wants to use relations as a general method to remove
redundancy. The idea is not new and I think there similar discussions
before. I think one of the arguments against it was that many editors are
not able to handle relations good enough, I fear this is still true. I think
the same problem is on the consumer side'

Not at all. Using relations properly could indeed reduce redundancy, and
that was the goal of my editing of the Alaska pipeline, but my aim for
starting this thread was to discuss relations and learn to use them better.

Also, Gert mentioned rendering. Let me repeat what I said earlier in this
thread about rendering. Rendering, while it's an important concern for all
of us, really shouldn't be a part of this discussion. We're trying to learn
how to best use a very powerful method of mapping a complex world. Whether
or not something shows up on the map (is rendered) is not what I'm talking
about here.



On Sun, Nov 4, 2018 at 4:15 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> If we follow Daves idea one might create a relation combining a few things
> that have the same tag, e.g. all building=residential in a town, name it
> something like "residential buildings" and finally remove the tags from
> those buildings. I hope nobody thinks this would be a good idea.
>
> Reg. the TAP pipeline (I was the complaining user that Dave mentioned): I
> did not even know that something like a route=pipeline exists before I saw
> that Dave removed the tags from the member way. The same seems to be true
> for JOSM developers because the way is no longer rendered as a pipeline in
> JOSM.
> Well, that might be something that should be fixed in JOSM.
>
> I think Dave wants to use relations as a general method to remove
> redundancy. The idea is not new and I think there similar discussions
> before. I think one of the arguments against it was that many editors are
> not able to handle relations good enough, I fear this is still true. I
> think
> the same problem is on the consumer side:
> A renderer or routing app has to know which types of relations might
> contain
> information that has to be transferred to the members, it cannot do that
> with a simple rule like "if a way is the member of a relation, copy all
> attributes of the relation to the way". Just think about cases where a
> highway is member of several route relations.
> So, if one starts to remove tags from members because the relation repeats
> the tag he has to make sure that this is a well established method. Not
> sure
> if this is the case for pipelines?
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-03 Thread Dave Swarthout
Mateusz wrote:

"Both methods are not very easy but are necessary very rarely and it allows
to avoid
problematic "half of tags is here, half in this relation" that is highly
problematic for mappers"

I realize it can be done this way but it's a ton of work (quote: not very
easy) compared to making one simple edit to tag the entire collection of
ways. I simply cannot understand why anyone would prefer this method over
the much easier one of merely adding or editing a tag in the relation. As
for your comment:  "half of tags is here, half in this relation"; frankly
that problem wouldn't exist if people were tagging relations properly in
the first place.

On Sat, Nov 3, 2018 at 5:30 PM Mateusz Konieczny 
wrote:

> 3. Nov 2018 00:00 by daveswarth...@gmail.com:
>
> To make matters worse, let's just say you misspelled the Wikipedia tag
> value. You meant to write "wikipedia=en:Trans-Alaska Pipeline System" but
> forgot to include the "en:" prefix. Back you go to your editor, editing all
> 280 pieces again. That's why I say tagging it this way is a maintenance
> nightmare.
>
>
> (1) First method: download area with relation in JOSM, download all
> relations members,
>
> use "select members" in relation listing menu.
>
>
> --
>
>
> (2) It can be also relatively easily done with help of overpass turbo.
>
>
> Search with overpass turbo wizard
>
> wikipedia="en:Trans-Alaska Pipeline System" global
>
>
> results are in https://overpass-turbo.eu/s/DkY
> One may use "Export" button to send this data to your editor.
>
> Both methods are not very easy but are necessary very rarely and it allows
> to avoid
> problematic "half of tags is here, half in this relation" that is highly
> problematic for mappers.
>
>

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


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

2018-11-03 Thread Dave Swarthout
I've been saying that I believe tagging that applies to an entire relation
should be placed ONLY on the relation and NOT on the individual ways,
UNLESS, there is some characteristic of the way that requires different
tagging. I gave examples using the Trans Alaska Pipeline but this reasoning
extends to other cases. Just now, I came across this statement in the Wiki
concerning islands in a river system:

"To map islands in a river you can use a multipolygon
<https://wiki.openstreetmap.org/wiki/Relations/Multipolygon> relation and
the island and the main river bank should be included in the relation. The
main riverbank way (way 1 in image above) will have the role 'outer' and
the way for the island (way 2 in image above) will have the role 'inner'. *When
mapping with multipolygon relations do not tag the member ways with
waterway=riverbank as well - this is wrong. Member ways should be untagged
unless they have a separate meaning on their own (like barrier
<https://wiki.openstreetmap.org/wiki/Key:barrier>=retaining_wall
<https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dretaining_wall>)"*

(*BOLD TEXT* is my addition) This is exactly what I've been saying
*. Member ways should be untagged unless they have a separate meaning on
their own. *

There you have it. It's a logical system of tagging and makes perfect sense
both from an initial standpoint and for ease of maintenance later on.

On Sat, Nov 3, 2018 at 5:34 PM Mateusz Konieczny 
wrote:

> 3. Nov 2018 11:30 by davefoxfa...@btinternet.com:
>
> Duplication of data leads to confusion, wasted time & errors.
> Please refrain from mapping in this way.
>
>
> Please refrain from demanding that other stop mapping in way that is
> commonly accepted.
>
>
> Suggesting, promoting and explaining alternatives is fine, but claiming
> that one way is sole
>
> acceptable while it is untrue is irritating.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-02 Thread Dave Swarthout
Of course. The Trans Alaska Pipeline is as good an example as any. It is a
man_made oil pipeline that stretches 1300 km across the entire state of
Alaska. The relation contains 280 members. The reason there are so many
members is because the pipeline way has been split into many individual
pieces, separate ways, that have certain differing characteristics, e.g.
where it runs underground or crosses a river on a bridge. The tagging for
any specific way deals with those differing characteristics. A section
might run for several miles underground and then emerge. At that point the
pipeline way must be split into a section with location=underground and the
emergent section with location=overground. Now it comes to a river that it
crosses on a bridge. The pipeline way is split again into a section that
has the tags bridge=yes and layer=1. You do the same thing to a highway
where the number of lanes changes, or maxspeed. Each change requires you to
split the way.

Now say you've been tagging each piece with all the tags required rather
than the relation. You decide to add a Wikipedia tag to the pipeline. Using
your method, you must edit every piece of the pipeline, all 280 sections of
it, and add the Wikipedia tag. Tagging the relation with the Wikipedia
entry, however, requires only one edit. To make matters worse, let's just
say you misspelled the Wikipedia tag value. You meant to write
"wikipedia=en:Trans-Alaska Pipeline System" but forgot to include the "en:"
prefix. Back you go to your editor, editing all 280 pieces again. That's
why I say tagging it this way is a maintenance nightmare.

I would only use tags on a particular way when its characteristics demand
it. Tags that apply to the entire pipeline belong in the relation. Tags
like the Wikipedia tag, substance=oil, man_made=pipeline, operator,
alt_name, etc., belong on the relation. However, tags like bridge and
location, tags that apply to individual sections or ways, get applied to
the ways and not the relation because they don't apply to the entire
pipeline.

On Sat, Nov 3, 2018 at 4:25 AM Mateusz Konieczny 
wrote:

> 2. Nov 2018 01:04 by daveswarth...@gmail.com:
>
>  The only tags that should appear on the ways themselves are attributes of
> those ways, for example, location=overground or location=underground, and
> tags for bridge and layer. Everything else, Wikidata, substance=oil,
> man_made=pipeline, etc, should appear only on the relation.
>
>
> I am not convinced that it is a good idea.
>
>
>
> If those tags appear on each way in addition to the relation, maintaining
> any consistency in the tagging on this beast would be almost impossible.
>
>
> Can you give examples of task that you claim to be almost impossible?
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-11-01 Thread Dave Swarthout
Allan, I'm not about to remove any tags from the highways in Turkmenistan.
This isn't about an edit war. It's about trying to do things in the most
efficient way possible. Using your highway as an example, let's say it has
dozens of segments, each tagged with ref and other items as you indicated.
Now let's say the ref changes. Someone must go in and retag every piece of
your highway system; every bridge, every tunnel and every section that has
a different number of lanes, a different maxspeed, or a different "local"
name. It's a tricky operation at best and easily avoided. Because if that
ref tag appears only in the relation, changing it involves only one edit,
that of the ref tag inside the relation. The tags you're using on
individual pieces of the highway are fine. I'm not saying you shouldn't
continue to do what you have been doing. I'm only asking what is the
correct way.

Also, whether the relation renders the way one desires or not shouldn't be
part of this discussion. We all want the stuff we map to be visible on the
map products we use. But if certain relations aren't showing up on maps
it's the map products that need to be fixed rather than our tagging
methodology.

Respectfully,
Dave

On Fri, Nov 2, 2018 at 8:44 AM Allan Mustard  wrote:

> I don't see a problem with duplicating a tag in both the relation and
> sections of the object.  In my case I have been mapping the national
> highway network of Turkmenistan the last few months.  I have created
> relations so that all segments belong to one or more highways (P-1 from
> Ashgabat to Koneurgench, for example).  However, most map renderers will
> not indicate that, plus the road is known to locals in most areas by that
> name, so I have also added it to the name=* and ref=* tags.  Too much
> data?  I don't think so.  Each tag serves a slightly different purpose, and
> the relation serves a wholly different purpose and is not visible in most
> map products.
>
> Please don't go to the Turkmenistan map and delete all my hand-entered
> tags on the highways!
>
> Allan Mustard
>
> On 11/2/2018 5:04 AM, Dave Swarthout wrote:
>
> Putting aside the discussion about type for a moment, this topic relates
> to a discussion I'm having with a user about tags and multipolygons,
> specifically where the tags go, so I believe it fits into this discussion.
> I removed the tags from the ways for a section of the Trans Alaska Pipeline
> (TAP) because those same tags were on the relation itself. The user asked
> in a changeset comment why I had done that. I replied that IMO, any tags
> that applied to the pipeline as a whole belong on the relation and need
> not, indeed should not, be repeated on each way. The TAP is 1300 km long,
> has countless bridges and sections where it is underground and then
> overground. The only tags that should appear on the ways themselves are
> attributes of those ways, for example, location=overground or
> location=underground, and tags for bridge and layer. Everything else,
> Wikidata, substance=oil, man_made=pipeline, etc, should appear only on the
> relation. The folks who added the pipeline mostly via Tiger imports many
> years ago tagged both. When I would occasionally add or replace a section,
> I was always careful to copy all the tags from a neighboring section to the
> new section. Now, I think that is incorrect.
>
> If those tags appear on each way in addition to the relation, maintaining
> any consistency in the tagging on this beast would be almost impossible. I
> have done quite a bit of re-aligning of the TAP over the years as our
> available imagery improves but have always been tentative about removing
> those redundant tags thinking I would get around to it someday. In fact, it
> seems apparent that this is one major reason relations were invented,
> especially for objects like routes — to ensure tagging consistency and
> connectedness between the many individual member ways that comprise the
> whole.
>
> So, what is the correct and accepted way to tag something like the TAP?
>
> Dave
>
> On Sat, Oct 13, 2018 at 7:17 AM Kevin Kenny 
> wrote:
>
>> why not a multipolygon? I agree that you don’t need additional tags for a
>>> group relation, just type=group, a name and the members, but for a site you
>>> would need something that describes the site, a tag for a group of water
>>> areas, so as long as all the members are areas (or parts), a multipolygon
>>> would be better.
>>>
>>
>> When the lakes themselves are complex multipolygons with many islands,
>> repeating that data for the group is likely to be a maintenance nightmare.
>> (I know this from curating boundary=protected_area relations that include
>> partial shorelines on such lakes. It's especially fun when the bounda

  1   2   3   4   5   6   >