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

[Graeme Fitzpatrick]

As far as I'm concerned, it can go to vote!

Thanks

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

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

[دار الآثار للنشر والتوزيع-صنعاء Dar Alathar-Yemen]

I am talking about nodes not areas or ways. Most of seas in OSM are tagged on 
node element. Also countries most of them are tagged on node element




من: Kevin Kenny 
‏‏تم الإرسال: 01/ربيع الأول/1440 09:09 م
إلى: Tag discussion, strategy and related tools
‏‏الموضوع: Re: [Tagging] New rag to draw node name with rotate angle

‪On Fri, Nov 9, 2018 at 12:06 PM ‫دار الآثار للنشر والتوزيع-صنعاء Dar 
Alathar-Yemen‬‎ mailto:hubais...@outlook.com>> wrote:‬
I suggest new tag to tell map render to draw the node name with a specified 
rotate angle not horizontal. We need this for some seas like Red Sea, and Suez 
Gulf in Egypt.

I have serious doubts whether encoding the rendering in the map in such a way 
is a good idea.

A renderer that wished to label an area with an angled label could readily 
determine the angle for itself, by computing the principal axes of the area, 
and if its eccentricity exceeds a specified value, rotating the label to align 
with the major axis.

An even better rendering could be achieved by computing the morphological 
skeleton of the area, and placing the label along some smooth curve that 
approximates the medial axis.

There are also algorithms that handle curved label placement in the presence of 
interfering labels, although they are somewhat less well developed. One such is 
described in Mathieu BARRAULT, "A methodology for placement and evaluation of 
area map labels." _Computers, Environment and Urban Systems_ 25 (2001), pp. 
33-52.
http://geoinformatics.ntua.gr/courses/admcarto/lecture_notes/name_placement/bibliography/barrault_2001.pdf

Barrault describes the process of choosing a family of circular arcs that well 
approximate the general contour of an area feature. Figure 3 of the paper is 
informative about what criteria his heuristic takes into account for 'goodness' 
of placement. Figures 10 and 11 show what the algorithm achieves on sample 
elongated figures and Figures 13-14 show what it can do in the presence of 
interfering labels.

To place this task on the mapper forecloses on the possibility that a renderer 
can do it better.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Allan Mustard]

Kind folks,

Comments on the proposal tapered off after Eugene's November 4 post, so
I plowed through the comments and have rewritten and moved the
amenity=consulate proposal to office=diplomatic.  You may find the
rewritten proposal here:

https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Now, unless there is consensus that we need another two weeks of
comment, I intend within the next two days to submit this proposal for a
vote.  If you object to this and believe we need another two weeks of
comments since amenity=consulate was moved to office=diplomatic, please
say so!  I'm happy either way, and thank you all for your interest,
ideas, and comments.

Very best regards to all,
apm-wa

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

Re: [Tagging] Government Archives

[Allan Mustard]

Most of what government consists of services.


On 11/10/2018 5:07 AM, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 8. Nov 2018, at 02:12, Warin <61sundow...@gmail.com> wrote:
>>
>> An archive is a place that stores old information.
>> Humm .. is giving me access to that information a service?
>
> both, storing historic information and providing access to it, could be seen 
> as services.
>
> Cheers, Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Government Archives

[Martin Koppenhoefer]

sent from a phone

> On 8. Nov 2018, at 02:12, Warin <61sundow...@gmail.com> wrote:
> 
> An archive is a place that stores old information.
> Humm .. is giving me access to that information a service?


both, storing historic information and providing access to it, could be seen as 
services.

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

Re: [Tagging] Government Archives

[Martin Koppenhoefer]

sent from a phone

> On 7. Nov 2018, at 20:52, marc marc  wrote:
> 
> building value is what the building look like.
> what a government building look like ? no idea...


it depends on the country, its political culture and history, the age and scope 
of the building, but government buildings will often be recognizable, 
particular buildings, there are different levels functionally and also 
according to the admin level, representative buildings like ministries and 
other headquarters, townhalls, but also more basic office buildings, etc.

I’m not saying you can recognize every government building from the outside, 
but this doesn’t imply the whole category wouldn’t make sense.

Cheers, Martin 


> some are retail building,
> some archives are in a industrial-look building, ...

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

Re: [Tagging] Reversible Road tagging

[Richard]

On Fri, Nov 09, 2018 at 07:59:22PM +0100, yo paseopor wrote:
> One little point
> 
> Untill now GPS navigation is orientative, not compulsory, obligatory or
> have-to-do. So instead your Osmand says you go in opposite direction, you
> drive, you decide. No kamikaze please.

correct, but it is not our intention to produce data that is better suited for
kamikaze drivers than normal users.. is it?

> yopaseopor
> PD: conditional lanes tagging situation would be interesting with a new tag
> (forward/backward/reversible), for example...
> 
> lanes:forward=1
> lanes:backward=1
> lanes:reversible=1
> reversible:forward=Mo-Su 07:00-09:00,15:30-17:30
> reversible:backward=Mo-Su 9:00-15:30
> reversible:closed=Mo-Su 17:30-07:00

Imho conditional restrictions have everything we need, it provides perhaps a 
little
bit more than that and we should pick one preferred method.

https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Evaluation_of_conflicting_restrictions
- mentions lanes and directional restrictions explicitly

so perhaps
lanes=0
lanes:forward:conditional=2 @ (09:00-17:00)
lanes:backward:conditional=2 @ (17:01-8:59)

I suspect there might be some places already tagged somehow similar like this 
but can't find them now..

As it has not been implemented in any routers that I know about it might be
good to ask in the issue trackers of some routers if they have an idea what 
would be reasonably easy to implement.

Richard

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

Re: [Tagging] Slipways (for boats)

[Warin]

On 10/11/18 05:03, Paul Allen wrote:
On Fri, Nov 9, 2018 at 5:59 PM Andy Mabbett > wrote:


The wiki tells us to use "leisure=slipway":

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dslipway

but many slipways are primarily for search-and-rescue, fishing craft,
small ferries or other non-leisure uses.

What would be a better tag?


I hesitate to suggest it, because it's viewed as a "miscellaneous" 
tag, but in this case it seems

rather appropriate.  amenity=slipway.

Of course, it may take a while (possibly a very long while) before 
renderers catch up, so
people will continue to use leisure, so the renderer people will say 
it's not used enough, as

will the editor people, so you may decide to stick with leisure.



Unfortunately leisure=slipway is the one 'inuse'. Changing it will take 
effort and time.


I would suggest man_made=slipway .. they all have had some efforts by 
humans to make them.

I'd stay away from amenity as much as possible.


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

Re: [Tagging] Reversible Road tagging

[yo paseopor]

One little point

Untill now GPS navigation is orientative, not compulsory, obligatory or
have-to-do. So instead your Osmand says you go in opposite direction, you
drive, you decide. No kamikaze please.

yopaseopor
PD: conditional lanes tagging situation would be interesting with a new tag
(forward/backward/reversible), for example...

lanes:forward=1
lanes:backward=1
lanes:reversible=1
reversible:forward=Mo-Su 07:00-09:00,15:30-17:30
reversible:backward=Mo-Su 9:00-15:30
reversible:closed=Mo-Su 17:30-07:00

On Thu, Nov 8, 2018 at 11:12 PM Richard  wrote:

> On Thu, Nov 08, 2018 at 04:05:49PM -0500, Jack Burke wrote:
>
> > Following the KISS principle, barrier node tagging might be the way to
> go,
> > at least initially.
> >
> > Barrier tagging Pros:
> > * Easy to implement in routing (e.g., OsmAnd's routing.xml can process a
> > node as barrier=1 or barrier=-1 based on the opening_hours times).
>
>
> note that OsmAnd doesn't do any time dependent routing, or at it least it
> didn't do it for a very long time.
>
> > Barrier tagging Cons:
> > * Having a hard time thinking of any.
>
> might work to some extent but I see it as important deficit that the
> directionality
> of the road isn't modelled.. sooner or later it will cause disaster.
> Imagine routers
> to issue commands like "turn around and follow the road in opposite
> direction" when the
> diver missed an exit for example.
> Also, just one single entry point that someone has forgotten to tag with a
> barrier
> or has the wrong time information and the router will send kamikaze
> drivers in the wrong
> direction into the expressway.
>
> My thought would be to have a variable time dependent number of lanes in
> each
> direction.
>
> Or "oneway" with conditional restrictions
>  https://wiki.openstreetmap.org/wiki/Conditional_restrictions
>
> Richard
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

‪On Fri, Nov 9, 2018 at 12:06 PM ‫دار الآثار للنشر والتوزيع-صنعاء Dar
Alathar-Yemen‬‎  wrote:‬

> I suggest new tag to tell map render to draw the node name with a
> specified rotate angle not horizontal. We need this for some seas like Red
> Sea, and Suez Gulf in Egypt.
>

I have serious doubts whether encoding the rendering in the map in such a
way is a good idea.

A renderer that wished to label an area with an angled label could readily
determine the angle for itself, by computing the principal axes of the
area, and if its eccentricity exceeds a specified value, rotating the label
to align with the major axis.

An even better rendering could be achieved by computing the morphological
skeleton of the area, and placing the label along some smooth curve that
approximates the medial axis.

There are also algorithms that handle curved label placement in the
presence of interfering labels, although they are somewhat less well
developed. One such is described in Mathieu BARRAULT, "A methodology for
placement and evaluation of area map labels." _Computers, Environment and
Urban Systems_ 25 (2001), pp. 33-52.
http://geoinformatics.ntua.gr/courses/admcarto/lecture_notes/name_placement/bibliography/barrault_2001.pdf

Barrault describes the process of choosing a family of circular arcs that
well approximate the general contour of an area feature. Figure 3 of the
paper is informative about what criteria his heuristic takes into account
for 'goodness' of placement. Figures 10 and 11 show what the algorithm
achieves on sample elongated figures and Figures 13-14 show what it can do
in the presence of interfering labels.

To place this task on the mapper forecloses on the possibility that a
renderer can do it better.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[OSMDoudou]

Looks like encouraging “tagging for the renderer”.

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

Re: [Tagging] Slipways (for boats)

[Paul Allen]

On Fri, Nov 9, 2018 at 5:59 PM Andy Mabbett 
wrote:

> The wiki tells us to use "leisure=slipway":
>
>https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dslipway
>
> but many slipways are primarily for search-and-rescue, fishing craft,
> small ferries or other non-leisure uses.
>
> What would be a better tag?
>

I hesitate to suggest it, because it's viewed as a "miscellaneous" tag, but
in this case it seems
rather appropriate.  amenity=slipway.

Of course, it may take a while (possibly a very long while) before
renderers catch up, so
people will continue to use leisure, so the renderer people will say it's
not used enough, as
will the editor people, so you may decide to stick with leisure.

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

[Tagging] Slipways (for boats)

[Andy Mabbett]

The wiki tells us to use "leisure=slipway":

   https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dslipway

but many slipways are primarily for search-and-rescue, fishing craft,
small ferries or other non-leisure uses.

What would be a better tag?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Public Transport Timetables

[rmikke]

Paul Allen wrote
> On Thu, Nov 8, 2018 at 9:43 PM Graeme Fitzpatrick <

> graemefitz1@

> >
> wrote:
> 
>> Simple way may just be multiple timetable tags -
>> "timetable:red_busline=URL*" "timetable:blue_busline=URL*"
>>
> 
> That was a suggestion I made earlier in the thread, but nobody responded
> either way.  Only problem
> with that is do we insist on the operator name even when there's only one
> operator?  Probably best
> if we do.  Of course, then there's the problem of ensuring mappers use a
> consistent name for an
> operator, and how we handle collisions.  It looks like traveline has
> assigned unique operator
> codes for UK operators and it would seem very sensible to re-use those.

But that may not work so well outside UK.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

[Tagging] New rag to draw node name with rotate angle

[دار الآثار للنشر والتوزيع-صنعاء Dar Alathar-Yemen]

I suggest new tag to tell map render to draw the node name with a specified 
rotate angle not horizontal. We need this for some seas like Red Sea, and Suez 
Gulf in Egypt.

Also some african countries like Togo and Benin will be best if its names are 
drwan with rotate angle. Also Somalia name will be better if drawn with 45 deg.

Simply we can add:

rotate-angle=45

Or

label-rotate=45

hubaishan

حبيشان




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

Re: [Tagging] Public Transport Timetables

[Paul Allen]

On Thu, Nov 8, 2018 at 11:21 PM Graeme Fitzpatrick 
wrote:

>
> On Fri, 9 Nov 2018 at 08:02, Paul Allen  wrote:
>
>> If I understand it correctly (quite possibly not) your examples are not
>> GTFS feeds but timetables
>> derived from them.
>>
>
> Ugh, now you're asking questions that are way, way beyond me! Any
> thoughts, anyone (& does it make any difference?)
>

Several of the links posted here were for human-readable timetables.  They
may have been
created from GTFS data, but they're not raw GTFS data.  They're what a
typical user would
want to see.  But they're not directly usable by routers.  A router would
have to "screen scrape" the
timetable and try to parse the data into a usable form.  Each operator
would need their own
parser.  The parser might have to be rewritten if the operator made even
minor changes to the
layout of the timetable.

The GTFS data is in a standardized form designed for things like routers to
understand.  See
this example: https://developers.google.com/transit/gtfs/examples/gtfs-feed
- it's not something
an average human will be able to use.

I think we definitely need timetable=* for human-type data consumers.  I
think we probably also need
gtfs=* for router type data consumers.

Only problem with that is do we insist on the operator name even when
>> there's only one operator?  Probably best
>> if we do.
>>
>
> Do we need to? I guess it may depend on the individual bus stop - if
> there's only one timetable, then just timetable=, if there's multiples then
> timetable:translink=* + timetable:skybus=* +timetable:greyhound=*, each as
> a separate tag going to a different URL. *Much* simpler than relations or
> whatever, & I like simple! :-)
>

Yes, but many of the stops around here serve more than one route.  And some
of those routes
have had (in the past) more than one operator and may do so again - council
policy not to let a
single operator have too large a slice of the pie occasionally meant two
operators for one route.

Of course, then there's the problem of ensuring mappers use a consistent
>> name for an operator
>>
>
> Probably get's down to local knowledge? I know that everything here is
> covered by the Translink network, even though there are multiple companies
> running buses on that network, with SkyBus running between the airport &
> the major hotels. You know that you have Green Buses & Red Buses (or
> perhaps Bysiau Coch? :-))
>

Brodyr Richards. :)


>  in your area. Leave the naming to the mapper, as all we're really
> interested in is the correct URL for that stop.
>

I was also thinking of the problem where "Green Bus" in Detroit is an
entirely different entity from
"Green Bus" in Kansas City.  It is desirable to have both consistency and
uniqueness.  Which is
why re-using identifiers by Translink, Traveline and other national public
transportation organizations
is probably a good idea (where possible) and one we should promote in the
wiki entry when (if) we
write it.

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

Re: [Tagging] Estimated values for height

[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  > > 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 
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > --
> > Dave Swarthout
> > Homer, Alaska
> > Chiang Mai, Thailand
> > Travel Blog at http://dswarthout.blogspot.com
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> Tagging 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

[marc marc]

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

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

Re: [Tagging] Estimated values for height

[Lionel Giard]

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  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 
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[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] Feature Proposal - RFC - Tramtrack on highway

[Nikulainen, Jukka K]

Dear all!

Thank you for the insightful critical comments for the tag proposal.

I have now changed the tag value from a bicycle=* acces key to a railway= -key. 
I have also changed and updated the Rationale, Tagging and Applies to -fields 
according to the comments received here and on the talk page. Thanks again to 
everyone that commented and especially to Mateusz for the pictures. I'll try to 
get a few pictures too (of very gloomy November Helsinki) once I have the time.

See the changed proposal page at:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tramtrack_on_highway

And please do keep the comments coming! It seems that the rationale is in order 
and that there is indeed need for such a tag. Hopefully, we'll get to voting as 
soon as the tag values and tagging practices for it are ironed out.

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

[Tagging] Estimated values for height

[Cascafico Giovanni]

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

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

[Gerd Petermann]

I think it gets easier when you think of a relation as a data structure that
allows to combine links to other objects with tags. That's what it is,
nothing more. Only the tags give a hint about the meaning of this
combination, and one always has to bear in mind that different mappers might
see different meanings, not talking about simple errors.

This is also the explanation for the problems reg. the consumers and
editors. Without a general rule each type of relation needs a lot of code to
allow rendering and proper editing support. A relation type that is not
often used or that is used with unclear meaning is not likely to find a
supporting programmers.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

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

[Dave Swarthout]

Martin said:
" tags on the way apply to the way, those on the relation to tag relation
as a whole. There is no general inheritance from the relation to its
members."

When I made my statement about inheritance I tried to choose my words
carefully. I said that those tags only _implicitly_ apply to all the ways
in the relation because it's certainly not obvious that they do, or might.
If a Wikidata tag appearing in the relation doesn't apply to every way,
that means it would have to appear on each and every way, which would be,
in my opinion, both illogical and needlessly redundant. However, if it does
apply, then what are we to make of Martin's claim that there is no general
inheritance? It makes no sense, from a software designer's perspective, to
create a data structure that behaves one way for certain objects and
differently for others and then not specify that behavior in some way for
all to see.

Kevin said:
" So -- a physical attribute (highway=*, surface=*, building=*, bridge=*,
whatever...) always goes on a physical object (a node, way, or
multipolygon). Relations other than multipolygons are not physical objects,
but conceptual groupings. They get the attributes that belong to the
groupings - name, operator, contact information, network, reference,
Wikipedia, website,  They do not get attributes of the physical objects
that compose them - those attributes belong to the objects and are not
generally understood to be inherited from the relation."

Sidestepping any talk about multipolygons for now, my contention that
rendering issues have influenced OSM mappers to apply tags to every way has
been supported many times in this long thread. In Kevin's most recent post,
he says, "Also, because of various issues with data modeling, 'ref=*' sort
of has to be there [on the ways], but that's a whole other discussion".
Indeed it is, but nevertheless, it's often problems with rendering that
motivate people to place tags on ways that rightfully belong only on the
relation.
Kevin goes on to say, Relations ... are not physical objects but conceptual
groupings. They get the attributes that belong to the grouings- name,
operator, Wikipedia, etc. They do not get the attributes of the physical
objects that compose them - those attributes belong to the objects and are
not generally understood to be inherited from the relation."

One of the things I'm trying to learn here is just how those rules and that
understanding came about.

Gerd wrote earlier in this thread about my (admitted) desire to use
relations to reduce data redundancy. He said: "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." I understand, but should those sorts of conseiderations
really influence how we use relations? If so, it's like the cart driving
the horse, so to speak. It's not a perfect world and my somewhat idealistic
approach to this whole problem may indeed be foolish but I still feel that
we mappers should be the driving force behind how we map things, not data
consumers or writers of editors.

IMO, part of the problem here, as I've said several times already, is the
poorly written Wiki that leaves us in a quandary when trying to reason out
the proper usage of relations. I'll bet nobody on this list can show me a
place in the Wiki where it says that relations can contain no tags that
refer to physical properties of objects. In fact, there's no explanation of
the data structure at all. (Or maybe there is and I just haven't found it
yet.) If someone can provide some evidence other than someone's opinion
that a relation should not contain any tags that are concerned with
physical characteristics of its member ways, I'll think to myself, that's
really short-sighted, but if it's the law, I'll accept it and move on.

Either way, I've learned a lot and will benefit from this discussion going
forward.

Dave



On Fri, Nov 9, 2018 at 5:39 AM Richard  wrote:

> On Tue, Nov 06, 2018 at 11:26:49PM -0600, Gerd Petermann 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 :-(
>
> my experience with waterways tells me that "essential tags" (like
> natural=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 woul