Fine for me.
Yves
Le 30 septembre 2018 06:19:21 GMT+02:00, Dave Swarthout
a écrit :
>Correct. I will split the river way at either end of the bend and apply
>the section tags to that piece only. The river continues to have its
>own
>name tag while the bend has only the tags needed to identify i
Correct. I will split the river way at either end of the bend and apply
the section tags to that piece only. The river continues to have its own
name tag while the bend has only the tags needed to identify it as a
section with special characteristics, and also a name
On Sun, Sep 30, 2018 at 10:33
I still think that if this feature is there to document the language of the
name tag, we should reuse the default_language [1] -- it is already set on
more than 200 large regions, covering most of the world. What's the point
of duplicating it? If there is a region where name could be in 2 or more
I'm surprised to learn that a major developer has reservations and concerns
about OSM relations. I don't like them much either. Small ones like simple
riverbanks and lakes containing islands are okay but when they get large,
they're difficult to understand and nearly impossible to debug. There are
Any opinions on the order of the tag?
Just a couple of people have said that default:language would be preferred
to language:default.
It will take some time to update the proposal page, so I would like a few
more opinions
Joseph
On Thu, Sep 27, 2018 at 10:16 AM Joseph Eisenberg <
joseph.eisenb.
I think this is a good solution for your situation; tagging bends and
reaches. It should work for other types of waterways too.
I assume in this example you will be splitting the way (waterway=river) at
the beginning and end of the bend? So there are no overlapping or duplicate
ways.
On Sun, Sep 3
Would it be helpful if there were several simpler database primitives for
several of the simplest types of relations?
I know people have already talked for years about adding a true area object
(which now we imitate with closed ways)
Could we also have a linear feature made up of ways only? This
> On Sep 29, 2018, at 6:56 PM, Paul Johnson wrote:
>
> I honestly don't understand why, ten years since it's introduction as OSM's
> third basic primitive, there's still this weirdly unnatural aversion to
> relations, even though they're quite a powerful primitive in our toolbox.
From my own p
Unfortunately, this topic has gotten split into two threads making it
difficult to follow. In trying to summarize, let's not be overly concerned
with rendering issues or whether this scheme can be fully modeled on OSM.
We can deal with rapids, hazards, etc., using existing tagging or develop
new t
Unfortunately, this topic has gotten split into two threads making it
difficult to follow. In trying to summarize, let's not be overly concerned
with rendering issues or whether this scheme can be fully modeled on OSM.
We can deal with rapids, hazards, etc., using existing tagging or develop
new ta
On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson wrote:
> I'm still against using forward/backward on nodes, it really feels like a
> hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because
On Sat, 29 Sep 2018 at 02:58, Philip Barnes wrote:
> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>
Phil
Do you have an example of a pedestrian crossing that OSMand warns you of,
as I don't see (or maybe just don't notice?)
On Sun, 30 Sep 2018 at 08:58, Paul Johnson wrote:
>
> I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>
Maybe because
On Sun, 30 Sep 2018 at 00:54, SelfishSeahorse
wrote:
>
> On Sat, 29 Sep 2018 at 00:29, Michael Booth wrote:
>
> I fail to understand the difference between a
> man_made=communications_tower and man_made=tower +
> tower:type=communication. Aren't all towers far visible landmarks?
> When is a towe
I believe rapids always will cover the width of a river, just like a
waterfall. Rapids form where the channel of a river heads downhill at a
steeper grade, and water wants to follow The exception would be a river
that has split in two at a flat spot up above the rapids (eg the Niagra
river splits a
How about demountable buildings, which are "supposed" to be temporary (but
I know of some at schools that have been in place for +30 years now!)
eg https://www.lloydsauctions.com.au/insider/portable-buildings/
Thanks
Graeme
___
Tagging mailing list
Tag
On Sat, 29 Sep 2018 at 18:19, Colin Smale wrote:
> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
How about permanent "lanes" (moored rows of buoys) for rowing races /
practice - not sure how y
Re: "I would not discard the idea of using some kind of relation for this
(type=route is not suitable, or is it?). It is the most flexible way to tag
as it allows for overlapping entities and avoids duplication of ways."
In theory, it would be great to be able to build up a long river from many
ne
On Fri, Sep 28, 2018 at 11:09 AM Bryan Housel wrote:
> I actually mentioned the issue in Milano.
>
> Essentially `traffic_sign`, `traffic_sign:forward` and
> `traffic_sign:backward` need to be treated as "object" tags as things are
> now.
>
> Let’s just do `traffic_sign=*` and consider the others
On Fri, Sep 28, 2018 at 11:58 AM Philip Barnes wrote:
>
>
> On 28 September 2018 17:31:18 BST, Kevin Kenny
> wrote:
> >On Fri, Sep 28, 2018, 5:34 AM Marc Gemis wrote:
> >
> >> I still highway=give_way and highway=stop with
> >> direction=forward/backward (which is used by OsmAnd AFAIK).
> >
> >
I've separated the proposal for non-inclusive drink refilling from the
drinking water cases. Anticipating a discussion, I'm replying to part
of Tom's most recent insights in the new RFC here (unfortunately, I've
copied some extra parts there too that is relevant here instead):
https://lists.openst
I've sliced part of the drinking proposal to a new page. I've copied
the related comments.
So the question here is what would be the most efficient, most
intuitive way to tag places where you can refill your drink for free
(or for a discounted price?) after having purchased the first glass.
https
Hi
On Sat, 29 Sep 2018 at 00:29, Michael Booth wrote:
>
> The Wiki definition is: "a huge tower for transmitting radio applications
> It is often made from concrete and usually a far visible landmark."
> https://wiki.openstreetmap.org/wiki/Tag:man%20made=communications%20tower
>
> Looking a
sent from a phone
> On 27. Sep 2018, at 15:05, François Lacombe wrote:
>
> Should it be building:prefabricated or something else?
along the lines of my reply above, I would suggest structure:prefabricated=yes
facade:prefabricated=yes
etc.
of course there should be definitions what is intende
sent from a phone
> On 28. Sep 2018, at 02:39, Dave Swarthout wrote:
>
> I keep coming back to Martin's place=river_bend. Adding a name=Harper Bend
> along with that tag would solve the problem in a straightforward manner,
> would not be confused with the specialized whitewater tagging schem
I would prefer to stay close to real life if possible. We should
choose/adapt our tagging model to match reality, and not try to force
reality into unnatural boxes. If real life has the possibility of
overlaps, we should allow for that. Making the way for "river_feature"
colinear with any existing
For the rare case a 'section' should have two names, the smallest part can have
it I guess.
Instead of section or reach, there's :part, like in building:part.
Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg
a écrit :
>Practically, if the ways overlap, it may be hard to render the nam
Practically, if the ways overlap, it may be hard to render the name labels
and interpret the data.
I’m imagining a routing app for boaters or paddlers. It could announce the
name of each new reach, bend and section, and also warn of hazards: “bridge
in 400 meters”, “Rock hazard”, “rapids ahead, gr
Yes, yes, of course. Quite right, Yves, and Martin.
>> waterway=river
>> name=Tanana River
>> waterway=section
>> section=bend
>> section:name=Harper Bend
>You can't use waterway=section + waterway=river on the same way, and you
>shouldn't map overlapping ways for obvious reasons.
I made that sam
river_feature would be fine as well as it would imply that it doesn't
need to be a linear feature, a node would also be OK (for small named
bays etc?)
Lets have a go at agreeing the basic principles of what we are trying to
achieve.
* there can be contiguous linear sections of a river which can
On 29/09/18 18:09, Martin Koppenhoefer wrote:
sent from a phone
On 29. Sep 2018, at 00:53, Dave Swarthout wrote:
waterway=river
name=Tanana River
waterway=section
section=bend
section:name=Harper Bend
I like what we've come up with so far. Any more suggestions?
this suggests 2 distinct (l
sent from a phone
> On 29. Sep 2018, at 00:53, Dave Swarthout wrote:
>
> waterway=river
> name=Tanana River
> waterway=section
> section=bend
> section:name=Harper Bend
>
> I like what we've come up with so far. Any more suggestions?
this suggests 2 distinct (likely overlapping way) objects
32 matches
Mail list logo
