[Tagging] network tag on route relations

[Mike Thompson]

Hello,

According to the wiki[0], it seems that the network tag has different
meanings and possible values based upon if it is applied to a route
relation where route=road vs. route=bicycle/mtb/foot/etc.

If I am understanding this correctly, when route=road, network= the
specific network that the road is part of, for example, a US Interstate
would be US:I[2]

For bicycle/mtb/foot etc. it seems that the network tag indicates the scope
of the network, for example a nationwide network cycling network would
network=ncn[1]

1) Why can't the network tag have consistent meaning across all route
types? For a mapper, as well as a data user, this is confusing.
2) The scope of a cycling/walking/etc. network should be evident from the
geographic extent of its members, so isn't network=icn/ncn/etc. redundant?
In any event, if the specific network is specified, it will, in most cases,
also indicate the general scope.

Mike

[0] https://wiki.openstreetmap.org/wiki/Key:network
[1]
https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes
[2]https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

On Sun, Jul 12, 2020 at 11:48 AM Robert Skedgell  wrote:

> On 12/07/2020 15:48, Mike Thompson wrote:
> > Hello,
> >
> > According to the wiki[0], it seems that the network tag has different
> > meanings and possible values based upon if it is applied to a route
> > relation where route=road vs. route=bicycle/mtb/foot/etc.
> >
> > If I am understanding this correctly, when route=road, network= the
> > specific network that the road is part of, for example, a US Interstate
> > would be US:I[2]
> >
> > For bicycle/mtb/foot etc. it seems that the network tag indicates the
> > scope of the network, for example a nationwide network cycling network
> > would network=ncn[1]
> >
> > 1) Why can't the network tag have consistent meaning across all route
> > types? For a mapper, as well as a data user, this is confusing.
> > 2) The scope of a cycling/walking/etc. network should be evident from
> > the geographic extent of its members, so isn't network=icn/ncn/etc.
> > redundant? In any event, if the specific network is specified, it will,
> > in most cases, also indicate the general scope.
> How do you know the scope of a network if there is no tag to indicate
> that member routes belong to it?
>
> The very short NCN route 425 in south-east London is network=ncn because
> it's a Sustrans route. THe scope of the route is very local, but the
> scope of the network is national. Without the network tag, how would a
> renderer or router determine whether it was an ncn, rcn or lcn? All
> three exist in Greater London.
> https://www.openstreetmap.org/relation/4247567
>

Ideally?  Make it work like the route=road networks.  "network=UK"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mark Wagner]

On Sun, 12 Jul 2020 19:36:10 +0200
mbranco2  wrote:

> Maybe images was shot in a particular season, and the soil condition
> is not always the same?
> Well, if I check several imageries and in all of them I see a
> "desertic land", I'm confident I can map that area with the tag we're
> talking about. And I think it doesn't matter if for few days a year
> (or few days in several years...) it will rain and there will be -
> for few days - a bit of vegetation: it's not an OSM mapping rule, to
> map the "main" characteristic of an item?

You've got to be careful when doing this, since imagery dates are not
random.  For example, six out of seven local imagery options are from
early or mid summer, while the seasonal ponds don't dry up until late
summer.  (The seventh option is from peak spring flood.)

-- 
Mark

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

Re: [Tagging] network tag on route relations

[Mark Wagner]

On Sun, 12 Jul 2020 17:51:29 +0200
Peter Elderson  wrote:

> Aren't Interstate and US evident from the geographic extent as well?
> 

The US has two national highway networks:

* The Interstate Highway System, major high-speed roads connecting
  major cities.
* The United States Numbered Highway System (commonly referred to as
  the "US Highways"), medium-speed roads routed to connect as many
  settlements as reasonably possible.

Detecting from extent also runs into the problem that Interstate spur
and loop routes almost never cross state lines.

-- 
Mark

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

[Tagging] site relations for city walls?

[Martin Koppenhoefer]

Someone has made a site relation for the Aurelian citywalls in Rome. 
Does this make sense to you?
We‘re speaking of a generally linear object of many kilometers length, in parts 
fragmented / interrupted.

Cheers Martin 

sent from a phone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Martin Koppenhoefer]

sent from a phone

> On 12. Jul 2020, at 20:32, Mark Wagner  wrote:
> 
> The US has two national highway networks:
> 
> * The Interstate Highway System, major high-speed roads connecting
>  major cities.
> * The United States Numbered Highway System (commonly referred to as
>  the "US Highways"),


that’s the norm elsewhere too, e.g. in Germany Autobahn and Bundesstraße or in 
Italy autostrada and strada statale, or in France autoroute and route national.

IMHO we would not even need a network tag for these cases, as it is visible 
from the ref.

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

Re: [Tagging] site relations for city walls?

[Taskar Center]

Why is the relation type on the Berlin Wall a “collection” rather than 
“boundary”?

Thanks,
Anat


Sent from my mobile. Please excuse brevity and typos.

> On Jul 12, 2020, at 11:52 AM, yo paseopor  wrote:
> 
> Big sense, nerver forget.
> What about that?
> 
> https://www.openstreetmap.org/relation/6651797#map=11/52.5183/13.2976
> 
> Health (more now than never) and maps
> yopaseopor
> 
>> On Sun, Jul 12, 2020 at 8:44 PM Martin Koppenhoefer  
>> wrote:
>> Someone has made a site relation for the Aurelian citywalls in Rome. 
>> Does this make sense to you?
>> We‘re speaking of a generally linear object of many kilometers length, in 
>> parts fragmented / interrupted.
>> 
>> Cheers Martin 
>> 
>> sent from a phone
>> ___
>> 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] network tag on route relations

[Peter Elderson]

Suppose XXn for recreational networks should go.
What do I do with all the route relations neatly tagged as
lwn, lcn, lhn, lpn, ..,and the r..n, n.n and i.n ?

Removing the tags without a working alternative will clear a lot of charts
and maps which present the routes to users for navigation, information and
export.

There are many more of those routes than of the road routes.

I think such a proposal should be driven by something more than perceived
inconsistency*. Is there an actual pressing problem with the current
tagging?

* I do not share this view. The network is a text field and can have any
value indicating the network in a workable way. For roads, as I understand
it, an hierarchical/federative abbreviation system has been worked out, but
that is not valid for recreational routes. So these use a different
notation system, where for instance the country doesn't get named because
that is redundant. Also the particular numbering system doesn't go in the
network, but per network and operator in the ref (if present) or per area
in the colour tag. Numbers and colors are freely reused even within one
operator's network, so you can't catch this in a fixed hierarchy. Feel free
to try though.

Best, Peter Elderson


Op zo 12 jul. 2020 om 21:04 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 12. Jul 2020, at 20:32, Mark Wagner  wrote:
> >
> > The US has two national highway networks:
> >
> > * The Interstate Highway System, major high-speed roads connecting
> >  major cities.
> > * The United States Numbered Highway System (commonly referred to as
> >  the "US Highways"),
>
>
> that’s the norm elsewhere too, e.g. in Germany Autobahn and Bundesstraße
> or in Italy autostrada and strada statale, or in France autoroute and route
> national.
>
> IMHO we would not even need a network tag for these cases, as it is
> visible from the ref.
>
> 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] network tag on route relations

[Peter Elderson]

Aren't Interstate and US evident from the geographic extent as well?

If deducted from geographic extent, what would be the extent for local and
regional? Would the US need an interstate tag? Would a hiking trail through
a relatively small nature area crossing boundaries between countries, be
local, regional or international?

In Europe, the classification as local, regional, national and
international is very common with long trails/routes.Different countries
'map' their recreationale routes onto this classification. I think the
classification is useful.

The n in network=..n seems redundant, the .. is very useful and
seems to meet wide acceptance among users, the .. again looks
redundant to me because route= already gives the transport.

OTOH, what's the harm? A road network is not a recreational route network,
and therefore it has different network classifications. Does not confuse
me. At all.

Best, Peter Elderson


Op zo 12 jul. 2020 om 16:49 schreef Mike Thompson :

> Hello,
>
> According to the wiki[0], it seems that the network tag has different
> meanings and possible values based upon if it is applied to a route
> relation where route=road vs. route=bicycle/mtb/foot/etc.
>
> If I am understanding this correctly, when route=road, network= the
> specific network that the road is part of, for example, a US Interstate
> would be US:I[2]
>
> For bicycle/mtb/foot etc. it seems that the network tag indicates the
> scope of the network, for example a nationwide network cycling network
> would network=ncn[1]
>
> 1) Why can't the network tag have consistent meaning across all route
> types? For a mapper, as well as a data user, this is confusing.
> 2) The scope of a cycling/walking/etc. network should be evident from the
> geographic extent of its members, so isn't network=icn/ncn/etc. redundant?
> In any event, if the specific network is specified, it will, in most cases,
> also indicate the general scope.
>
> Mike
>
> [0] https://wiki.openstreetmap.org/wiki/Key:network
> [1]
> https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes
> [2]https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jarek Piórkowski]

On Sun, 12 Jul 2020 at 13:36, mbranco2  wrote:
> ...
> And I think that we could map such characteristic even with only imagery 
> (without direct survey), because it's a "macro" feature, as is a wood or a 
> scrub.
> ...
> Surely it could be useful if botanists and/or geologists could better specify 
> (with more specific tags) the cause: no rain? pollution? specific 
> ground-conditions such as presence of salt or sulfur?
> ...
> Some references:
> - "Barren vegetation" [1]  (..."Regions on the earth’s surface where soils 
> are dominating the ecosystems with little to no plant cover are often 
> referred to as “Barren”. )
> [1] https://en.wikipedia.org/wiki/Barren_vegetation

This Wikipedia article seems to me to use "barren vegetation" to refer
to large areas covered in grasses and/or shrubs. That does not really
seem to match images in
https://wiki.openstreetmap.org/wiki/Proposed_features/Ground#Examples
nor in 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground#Examples
. I would suggest the proposal needs more images to define what would
be included and what wouldn't.

--Jarek

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

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

[Joseph Eisenberg]

The link [2] to https://www.hq.nasa.gov/iwgsdi/Barren_Land.html has these
categories:

*1.2.2.2.1 Bare Exposed Rock*: Those ecosystems characterized by areas of
bedrock exposure, desert pavement, scarps, talus, slides, volcanic
material, rock glaciers, and other accumulations of rock without vegetative
cover.

This is mostly covered by natural=bare_rock or natural=scree (or
natural=shingle) currently.

*1.2.2.2.2 Beaches*: Those ecosystems along shorelines characterized by
smooth sloping accumulations of sand and gravel. The surface is stable
inland, but the shoreward part is subject to erosion by wind and water and
to deposition in protected areas.

This is natural=beach, or natural=wetland + wetland=tidalflat, or
natural=shingle, possibly overlapping with water (if below the high tide
line or high water line).

*1.2.2.2.3 Dry Salt Flats*: Those ecosystems occurring on the flat-floored
bottoms of interior desert basins that do not qualify as wetlands.

We don't have a good tag for this, as Christoph mentioned previously,
probably because these features are rare in Europe.

*1.2.2.2.4 Mixed Barren Land*: Those regions in which a mixture of barren
land features occurs and the dominant land use occupies less than
two-thirds of the area. This includes, for example, a desert region where
combinations of salt flats, sandy areas, bare rock, surface extraction, and
transitional activities could occur in close proximity.

We should map these areas based on the most specific area: natural=sand,
natural=bare_rock, landuse=quarry, etc.

*1.2.2.2.5 Sandy Areas Other Than Beaches*: Those ecosystems composed
primarily of dunes -- accumulations of sand transported by wind. ...

This is usually mapped as natural=sand

*1.2.2.2.6 Strip Mines, Quaries, and Gravel Pits*: Those regions where
vegetative cover and overburden are removed to expose such deposits as
coal, iron ore, limestone, and copper. This includes inactive, unreclaimed,
and active strip mines, quarries, borrow pits, and gravel pits until other
cover or use has been established.

Mapped as landuse=quarry

*1.2.2.2.7 Transitional Areas*: Those regions that are in transition from
one land use activity to another. This transitional phase occurs when, for
example, forest lands are cleared for agriculture, wetlands are drained for
development, or when any type of land use ceases as areas become
temporarily bare as con- struction is planned for such future uses as
residences, shopping centers, industrial sites, or subur- ban and rural
residential subdivisions. This also includes land being altered by filling,
such as occurs in spoil dumps or sanitary landfills. (Definition Source: A
Land Use and Land Cover Classification System for Use with Remote Sensing
Data)

This might be landuse=landfill, landuse=construction, or landuse=brownfield
in many cases. Areas where trees have been recently cleared are somewhat
debatable, if it's not certain what the area is transitioning into, but
there is landuse=meadow + meadow=transitional for areas of grass that are
transitioning into scrub or early woodland again.

So we certainly need a new tag for salt flats, and I agree that there are
some places like badlands and deserts with clay soils where we don't have
well established tags for unvegetated areas, but many types of "barren"
land can already be mapped with existing tags. That's why it's important
that new tags are precisely defined.

– Joseph Eisenberg

On Sun, Jul 12, 2020 at 10:37 AM mbranco2  wrote:

> I hope that this discussion and the related proposal wiki page will lead
> to a solution, because I found several times, mapping in Africa with HOT
> projects, "desertic lands" and I didn't find a tag for this.
>
> If we search the Internet for "barren soil", we can find a lot of
> ground-level related images.
>
> And I think that we could map such characteristic even with only imagery
> (without direct survey), because it's a "macro" feature, as is a wood or a
> scrub.
>
> Maybe images was shot in a particular season, and the soil condition is
> not always the same?
> Well, if I check several imageries and in all of them I see a "desertic
> land", I'm confident I can map that area with the tag we're talking about.
> And I think it doesn't matter if for few days a year (or few days in
> several years...) it will rain and there will be - for few days - a bit of
> vegetation: it's not an OSM mapping rule, to map the "main" characteristic
> of an item?
>
> Surely it could be useful if botanists and/or geologists could better
> specify (with more specific tags) the cause: no rain? pollution? specific
> ground-conditions such as presence of salt or sulfur?
>
> For the main tag, I think that "natural" is the right key (being already
> natural=sand/bare_rock/shingle/scree...).
> About the value, I'd prefer a botanic or geologist suggest us the best
> word.
>
> Some references:
> - "Barren vegetation" [1]  (..."Regions on the earth’s surface where soils
> are dominating the 

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

[mbranco2]

I hope that this discussion and the related proposal wiki page will lead to
a solution, because I found several times, mapping in Africa with HOT
projects, "desertic lands" and I didn't find a tag for this.

If we search the Internet for "barren soil", we can find a lot of
ground-level related images.

And I think that we could map such characteristic even with only imagery
(without direct survey), because it's a "macro" feature, as is a wood or a
scrub.

Maybe images was shot in a particular season, and the soil condition is not
always the same?
Well, if I check several imageries and in all of them I see a "desertic
land", I'm confident I can map that area with the tag we're talking about.
And I think it doesn't matter if for few days a year (or few days in
several years...) it will rain and there will be - for few days - a bit of
vegetation: it's not an OSM mapping rule, to map the "main" characteristic
of an item?

Surely it could be useful if botanists and/or geologists could better
specify (with more specific tags) the cause: no rain? pollution? specific
ground-conditions such as presence of salt or sulfur?

For the main tag, I think that "natural" is the right key (being already
natural=sand/bare_rock/shingle/scree...).
About the value, I'd prefer a botanic or geologist suggest us the best word.

Some references:
- "Barren vegetation" [1]  (..."Regions on the earth’s surface where soils
are dominating the ecosystems with little to no plant cover are often
referred to as “Barren”. )
- "Barren land" [2] (an old web page from NASA: "...ecosystems in which
less than one third of the area has vegetation or other cover. In general,
Barren Land has thin soil, sand, or rocks."). This web page cites "A Land
Use and Land Cover Classification System for Use with Remote Sensor Data",
a free paper you can find in Google Books too.
- "Barren soil is starving Africans" [3]

Other examples of "desertic" lands:
- Bonneville (USA) [4] (maybe some of you saw World's Fastest Indian, the
lovely movie with Anthony Hopkins :-) )
- La Leona (Patagonia) [5]

Ciao!
Marco (mbranco2 / UNGSC-mbranco2)

[1] https://en.wikipedia.org/wiki/Barren_vegetation
[2] https://www.hq.nasa.gov/iwgsdi/Barren_Land.html
[3] https://www.nature.com/news/2006/060327/full/060327-15.html
[4] https://en.wikipedia.org/wiki/Bonneville_Salt_Flats
[5] https://visitpatagonia.com.ar/en/activities/petrified-forest-la-leona/





Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] site relations for city walls?

[yo paseopor]

Big sense, nerver forget.
What about that?


https://www.openstreetmap.org/relation/6651797#map=11/52.5183/13.2976

Health (more now than never) and maps
yopaseopor

On Sun, Jul 12, 2020 at 8:44 PM Martin Koppenhoefer 
wrote:

> Someone has made a site relation for the Aurelian citywalls in Rome.
> Does this make sense to you?
> We‘re speaking of a generally linear object of many kilometers length, in
> parts fragmented / interrupted.
>
> Cheers Martin
>
> sent from a phone
> ___
> 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] site relations for city walls?

[Martin Koppenhoefer]

sent from a phone

> On 12. Jul 2020, at 20:53, yo paseopor  wrote:
> 
> Big sense, nerver forget.
> What about that?
> 
> https://www.openstreetmap.org/relation/6651797#map=11/52.5183/13.2976


it’s a type=collection though, not a site. And questionable in parts, as the 
Berlin wall is often/sometimes still visible from fragments or remaining 
infrastructure (also small things like lights, light poles, cable attachments, 
etc.), but in many places there are no visible traces left...

In Rome the situation is different because the walls mostly have survived, and 
where arterial roads have cut through they are often holes in the wall, 
(sometimes also removed entirely though).

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

Re: [Tagging] site relations for city walls?

[Martin Koppenhoefer]

sent from a phone

> On 12. Jul 2020, at 21:14, Taskar Center  wrote:
> 
> Why is the relation type on the Berlin Wall a “collection” rather than 
> “boundary”?


it’s a collection of remaining traces of a boundary (which btw was never a 
„line“ in the geometric sense, because there always was a buffer that made it a 
zone around the boundary, and it never was the actual political boundary, which 
was towards the Western Berlin side, because the wall was built inside the 
Eastern Berlin area).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Robert Skedgell]

On 12/07/2020 15:48, Mike Thompson wrote:
> Hello,
> 
> According to the wiki[0], it seems that the network tag has different
> meanings and possible values based upon if it is applied to a route
> relation where route=road vs. route=bicycle/mtb/foot/etc.
> 
> If I am understanding this correctly, when route=road, network= the
> specific network that the road is part of, for example, a US Interstate
> would be US:I[2]
> 
> For bicycle/mtb/foot etc. it seems that the network tag indicates the
> scope of the network, for example a nationwide network cycling network
> would network=ncn[1]
> 
> 1) Why can't the network tag have consistent meaning across all route
> types? For a mapper, as well as a data user, this is confusing.  
> 2) The scope of a cycling/walking/etc. network should be evident from
> the geographic extent of its members, so isn't network=icn/ncn/etc.
> redundant? In any event, if the specific network is specified, it will,
> in most cases, also indicate the general scope.  
How do you know the scope of a network if there is no tag to indicate
that member routes belong to it?

The very short NCN route 425 in south-east London is network=ncn because
it's a Sustrans route. THe scope of the route is very local, but the
scope of the network is national. Without the network tag, how would a
renderer or router determine whether it was an ncn, rcn or lcn? All
three exist in Greater London.
https://www.openstreetmap.org/relation/4247567


> Mike
> 
> [0] https://wiki.openstreetmap.org/wiki/Key:network
> [1]
> https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes
> [2]https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format


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

Re: [Tagging] network tag on route relations

[Clay Smalley]

On Sun, Jul 12, 2020 at 3:08 PM Peter Elderson  wrote:

> I still don't understand why you tag "US" while it's obviously a bunch of
> roads in the US. or Interstate when the road clearly crosses state lines. I
> think that"s more redundant than tagging "we classify this route as a
> regional route", even though it might cross two national borders in a few
> places and half the roads are outside our borders, and we don't know the
> current operator or provider.
>

Because they are two separate networks with roughly the same geographical
scope. How would you distinguish Interstate 30 from US Route 30, which are
hundreds of miles away from each other?

Some Interstate highways do not cross state lines themselves, but the idea
behind the name is that the network as a whole does. Regardless, that's
just the name for our national freeway network.

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

Re: [Tagging] site relations for city walls?

[Martin Koppenhoefer]

sent from a phone

> On 13. Jul 2020, at 00:11, Volker Schmidt  wrote:
> 
> I do consider a site relation a fitting approach for a city wall.


its use would also go against the wiki definition which states: „ This relation 
is not to be used in cases where the element can be represented by one or more 
areas and neither linear ways nor nodes outside these areas would have to be 
included or excluded from within these areas“

clearly the remains of the Aurelian walls can be nicely  represented by areas. 
Indeed it seems a good representation to map them as buildings, and people 
including myself have started to do it some time ago.

Generally I believe the requirement for a site relation that its constituting 
parts should be in the same town, is not strict enough. A handful of objects 
scattered around in a town are not a „site“. A site means things are 
concentrated around a point, and when there are more things in the other side 
of the town that somehow belonged to it, they would be considered off site, 
i.e. their relationship would come from other aspects, not because they are 
part of the same „site“.

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

Re: [Tagging] network tag on route relations

[Mike Thompson]

On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson  wrote:

> Aren't Interstate and US evident from the geographic extent as well?
>
Yes, that is my point, or at least it is evident with the current mapping
practice.  Road routes are not tagged (at least not according to the wiki)
with network=nrn/rrn/etc.  Whether a road network is national, or
otherwise, is evident for two reasons:
1) All the routes with the same network tag will be spread across some
geographic extent. So, one could see that there are routes all across the
US with "network=US:I" and could conclude that this is a national network.
2) By the network tag itself, for example, in the "network=US:I" tag, there
is no smaller jurisdiction indicated after US, so it must be a national
network.

If a hiking route was tagged with network=US:FS (Forest Servies) for
example, one could see that (if that practice was generally followed), that
there the Forest Service operates hiking routes all across the US (and not
anywhere else), and thus that such a network was national in scope.  And,
the scope would be evident from the network tag itself, as there is no
smaller jurisdiction following "US" in the network tag.

In anyevent, my main point is we should be consistent and treat all route
relations the same.  If it is desirable to explicitly know the scope, why
not have a "scope" tag, or leave the scope in the network tag, and have a
new tag for "specific_network" (or whatever folks want to call it).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Mike Thompson]

On Sun, Jul 12, 2020 at 10:49 AM Robert Skedgell  wrote:

>
> The very short NCN route 425 in south-east London is network=ncn because
> it's a Sustrans route. THe scope of the route is very local, but the
> scope of the network is national. Without the network tag, how would a
> renderer or router determine whether it was an ncn, rcn or lcn? All
> three exist in Greater London.
I am not saying get rid of the network tag, I am saying we should be
consistent.  In the above case, if  network=UK (instead of network=ncn),
one would know it is national. First because the UK is a nation and there
is no smaller jurisdiction that follows "UK" in the tag, and because there
would be cycle routes all over the UK where network=UK.

Using this method, which seems to be in use for road routes, would allow us
to indicate the specific network which a route is part of, instead of just
the "scope" of the network.  So in the US, for a hiking route I could say
network=US:FS and everyone would know that it is a national network
operated by the US Forest Service. One might say that is what the
"operator" tag is for, but some agencies or jurisdictions operate multiple
networks, and this would be reflected in the network tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Peter Elderson]

Well, recreational routes and networks simply are not that organized, and 
jurisdiction or authority doesn't apply to most of them. I guess that is why 
the values are more generic. 

I still don't understand why you tag "US" while it's obviously a bunch of roads 
in the US. or Interstate when the road clearly crosses state lines. I think 
that"s more redundant than tagging "we classify this route as a regional 
route", even though it might cross two national borders in a few places and 
half the roads are outside our borders, and we don't know the current operator 
or provider.

Peter Elderson

> Op 12 jul. 2020 om 23:41 heeft Mike Thompson  het 
> volgende geschreven:
> 
> 
> 
> 
>> On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson  wrote:
>> Aren't Interstate and US evident from the geographic extent as well?
> Yes, that is my point, or at least it is evident with the current mapping 
> practice.  Road routes are not tagged (at least not according to the wiki) 
> with network=nrn/rrn/etc.  Whether a road network is national, or otherwise, 
> is evident for two reasons:
> 1) All the routes with the same network tag will be spread across some 
> geographic extent. So, one could see that there are routes all across the US 
> with "network=US:I" and could conclude that this is a national network.
> 2) By the network tag itself, for example, in the "network=US:I" tag, there 
> is no smaller jurisdiction indicated after US, so it must be a national 
> network.
> 
> If a hiking route was tagged with network=US:FS (Forest Servies) for example, 
> one could see that (if that practice was generally followed), that there the 
> Forest Service operates hiking routes all across the US (and not anywhere 
> else), and thus that such a network was national in scope.  And, the scope 
> would be evident from the network tag itself, as there is no smaller 
> jurisdiction following "US" in the network tag.
> 
> In anyevent, my main point is we should be consistent and treat all route 
> relations the same.  If it is desirable to explicitly know the scope, why not 
> have a "scope" tag, or leave the scope in the network tag, and have a new tag 
> for "specific_network" (or whatever folks want to call it).
> 
> ___
> 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] network tag on route relations

[Robert Skedgell]

On 12/07/2020 22:50, Mike Thompson wrote:
> 
> 
> On Sun, Jul 12, 2020 at 10:49 AM Robert Skedgell  > wrote:
> 
>>
>> The very short NCN route 425 in south-east London is network=ncn because
>> it's a Sustrans route. THe scope of the route is very local, but the
>> scope of the network is national. Without the network tag, how would a
>> renderer or router determine whether it was an ncn, rcn or lcn? All
>> three exist in Greater London.
> I am not saying get rid of the network tag, I am saying we should be
> consistent.  In the above case, if  network=UK (instead of network=ncn),
> one would know it is national. First because the UK is a nation and
> there is no smaller jurisdiction that follows "UK" in the tag, and
> because there would be cycle routes all over the UK where network=UK. 
> 
> Using this method, which seems to be in use for road routes, would allow
> us to indicate the specific network which a route is part of, instead of
> just the "scope" of the network.  So in the US, for a hiking route I
> could say network=US:FS and everyone would know that it is a national
> network operated by the US Forest Service. One might say that is what
> the "operator" tag is for, but some agencies or jurisdictions operate
> multiple networks, and this would be reflected in the network tag.
> 

Perhaps prefixing with the country code might work, but you would still have
to convince authors of rendering and routing services that a change from
network=ncn to network=GB:NCN is worth implementing.

Starting with UK presents another problem for consistency, as it's not
an ISO 3166-1-alpha-2 country code, just the abbreviated name of the
country.

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

Re: [Tagging] network tag on route relations

[Mike Thompson]

On Sun, Jul 12, 2020 at 4:53 PM Robert Skedgell  wrote:
>

>
> Starting with UK presents another problem for consistency, as it's not
> an ISO 3166-1-alpha-2 country code, just the abbreviated name of the
> country.
My mistake, should have been "GB"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Mike Thompson]

On Sun, Jul 12, 2020 at 4:08 PM Peter Elderson  wrote:
>
> Well, recreational routes and networks simply are not that organized, and
jurisdiction or authority doesn't apply to most of them. I guess that is
why the values are more generic.
In the US a significant percentage of the  trails are organized and have
some jurisdiction or authority which apply to them. For example, all of the
official numbered trails/roads in our National Forests, trails in our
National Parks (plus trails on land managed by a number of other Federal
agencies that manage and maintain trails), trails in our State Parks (and
state forests, state wildlife areas, etc.), trails in our county/city
parks/natural areas/open spaces (some counties and cities have also banded
together to form "park districts").
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Mike Thompson]

On Sun, Jul 12, 2020 at 4:18 PM Paul Johnson  wrote:
>
> Disambiguation.  US:FS:Hood and US:FS:Ozark are two different national
forest service networks with entirely different numbering schemes.  Plus
network=CA by itself would be Canada, not California, which is US:CA...
Paul, do you have a list of accepted abbreviations for our various National
Forests in the US?  Is it on the wiki?

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

Re: [Tagging] site relations for city walls?

[Andy Townsend]

On 12/07/2020 20:13, Taskar Center wrote:


Why is the relation type on the Berlin Wall a “collection” rather than 
“boundary”?


Over its history as an object in OSM it's had a whole variety of tags.  
Different people have said "This is important!  We should render it!" 
and have sometimes tried to do that by adjusting the tags until they 
found something that rendered.  Other people have tried to change tags 
to better reflect the current reality. 
http://osm.mapki.com/history/relation.php?id=6651797 tells the story.


Personally, I don't think that "boundary" would be a good relation type 
for it because it isn't one - it's the route of a former barrier within 
a boundary.  Compare 
https://www.openstreetmap.org/relation/6651797#map=19/52.51616/13.37698 
with the suburb boundary just to the west.


Best Regards,

Andy



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

Re: [Tagging] site relations for city walls?

[Volker Schmidt]

I do consider a site relation a fitting approach for a city wall.

On Sun, 12 Jul 2020, 22:35 Andy Townsend,  wrote:

> On 12/07/2020 20:13, Taskar Center wrote:
> >
> > Why is the relation type on the Berlin Wall a “collection” rather than
> > “boundary”?
>
> Over its history as an object in OSM it's had a whole variety of tags.
> Different people have said "This is important!  We should render it!"
> and have sometimes tried to do that by adjusting the tags until they
> found something that rendered.  Other people have tried to change tags
> to better reflect the current reality.
> http://osm.mapki.com/history/relation.php?id=6651797 tells the story.
>
> Personally, I don't think that "boundary" would be a good relation type
> for it because it isn't one - it's the route of a former barrier within
> a boundary.  Compare
> https://www.openstreetmap.org/relation/6651797#map=19/52.51616/13.37698
> with the suburb boundary just to the west.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Paul Johnson]

Disambiguation.  US:FS:Hood and US:FS:Ozark are two different national
forest service networks with entirely different numbering schemes.  Plus
network=CA by itself would be Canada, not California, which is US:CA...

On Sun, Jul 12, 2020 at 5:07 PM Peter Elderson  wrote:

> Well, recreational routes and networks simply are not that organized, and
> jurisdiction or authority doesn't apply to most of them. I guess that is
> why the values are more generic.
>
> I still don't understand why you tag "US" while it's obviously a bunch of
> roads in the US. or Interstate when the road clearly crosses state lines. I
> think that"s more redundant than tagging "we classify this route as a
> regional route", even though it might cross two national borders in a few
> places and half the roads are outside our borders, and we don't know the
> current operator or provider.
>
> Peter Elderson
>
> Op 12 jul. 2020 om 23:41 heeft Mike Thompson  het
> volgende geschreven:
>
> 
>
>
> On Sun, Jul 12, 2020 at 9:53 AM Peter Elderson 
> wrote:
>
>> Aren't Interstate and US evident from the geographic extent as well?
>>
> Yes, that is my point, or at least it is evident with the current mapping
> practice.  Road routes are not tagged (at least not according to the wiki)
> with network=nrn/rrn/etc.  Whether a road network is national, or
> otherwise, is evident for two reasons:
> 1) All the routes with the same network tag will be spread across some
> geographic extent. So, one could see that there are routes all across the
> US with "network=US:I" and could conclude that this is a national network.
> 2) By the network tag itself, for example, in the "network=US:I" tag,
> there is no smaller jurisdiction indicated after US, so it must be a
> national network.
>
> If a hiking route was tagged with network=US:FS (Forest Servies) for
> example, one could see that (if that practice was generally followed), that
> there the Forest Service operates hiking routes all across the US (and not
> anywhere else), and thus that such a network was national in scope.  And,
> the scope would be evident from the network tag itself, as there is no
> smaller jurisdiction following "US" in the network tag.
>
> In anyevent, my main point is we should be consistent and treat all route
> relations the same.  If it is desirable to explicitly know the scope, why
> not have a "scope" tag, or leave the scope in the network tag, and have a
> new tag for "specific_network" (or whatever folks want to call it).
>
> ___
> 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] network tag on route relations

[Peter Elderson]

Maybe just tag network=nfn then? Can be applied in any country. Details see 
oprator and ref.

How two distinguish two roads hundreds of miles away from each other? Hm... 
that is a hard question... 

Mvg Peter Elderson

> Op 13 jul. 2020 om 00:33 heeft Clay Smalley  het 
> volgende geschreven:
> 
> 
>> On Sun, Jul 12, 2020 at 3:08 PM Peter Elderson  wrote:
>> I still don't understand why you tag "US" while it's obviously a bunch of 
>> roads in the US. or Interstate when the road clearly crosses state lines. I 
>> think that"s more redundant than tagging "we classify this route as a 
>> regional route", even though it might cross two national borders in a few 
>> places and half the roads are outside our borders, and we don't know the 
>> current operator or provider.
> 
> Because they are two separate networks with roughly the same geographical 
> scope. How would you distinguish Interstate 30 from US Route 30, which are 
> hundreds of miles away from each other?
> 
> Some Interstate highways do not cross state lines themselves, but the idea 
> behind the name is that the network as a whole does. Regardless, that's just 
> the name for our national freeway network.
> 
> -Clay
> ___
> 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] site relations for city walls?

[Yves]

@Martin, the quote from the wiki really looks like a multipolygon definition. 
Would those walls be mapped as a multipolygon instead?

Why do you say "A site means things are concentrated around a point", sites 
relation helps to map disjoint elements, but I don't think I saw anything about 
their repartition. Also it certainly makes no sense to have sites extending 
over extremely large areas.
Yves 

Le 13 juillet 2020 01:14:40 GMT+02:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 13. Jul 2020, at 00:11, Volker Schmidt  wrote:
>> 
>> I do consider a site relation a fitting approach for a city wall.
>
>
>its use would also go against the wiki definition which states: „ This 
>relation is not to be used in cases where the element can be represented by 
>one or more areas and neither linear ways nor nodes outside these areas would 
>have to be included or excluded from within these areas“
>
>clearly the remains of the Aurelian walls can be nicely  represented by areas. 
>Indeed it seems a good representation to map them as buildings, and people 
>including myself have started to do it some time ago.
>
>Generally I believe the requirement for a site relation that its constituting 
>parts should be in the same town, is not strict enough. A handful of objects 
>scattered around in a town are not a „site“. A site means things are 
>concentrated around a point, and when there are more things in the other side 
>of the town that somehow belonged to it, they would be considered off site, 
>i.e. their relationship would come from other aspects, not because they are 
>part of the same „site“.
>
>Cheers Martin 
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging