Re: [Talk-us] Historic 66 as highway=trunk in OK

[Rihards]

On 29.08.19 05:05, Joseph Eisenberg wrote:
> I don't have any local knowledge about old route 66 in OK, but I'd
> like to address the use of highway=trunk in general.
> 
> I'm in favor of using a secondary tags like motorroad=yes and
> expressway=yes, along with other details like lanes=, surface=,
> maxspeed=, etc, to specify expressways, rather than using
> highway=trunk for this.
> 
> Like the distinctions between primary/secondary/tertiary, trunk was
> originally intended to describe the role of a road in the network.
> While most trunk highways are divided and have more than 1 lane in
> each direction in densely-populated areas, it's quite normal for to
> have narrower roads as the main route between 2 cities, in
> sparsely-populated parts of the country.
Or see "Route 1" in
https://wiki.openstreetmap.org/wiki/Is:Map_Features#Ways.

"Route 1 ... is tagged as highway=trunk due to its significance as a
trunk road covering the entire country."

Quoting from https://en.wikipedia.org/wiki/Route_1_(Iceland) :

"Many smaller bridges are single lane, especially in eastern Iceland,
and are constructed of wood or steel. The road is paved with asphalt for
almost all of its length, but there is still a short stretch in eastern
Iceland with unpaved gravel surface."
...
-- 
 Rihards

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-dk] Redningsskilte?

[Jørgen Elgaard Larsen]

På http://osm.elgaard.net/ kan man se et kort med de redningsnumre, der 
mangler/er for meget i OSM.

Jeg prøvede at lave en import (se 
https://www.openstreetmap.org/changeset/62107577), men endte med at reverte den 
på grund af fejl/dubletter. 

Fejlene burde være rettet nu, så det vil være trivielt at lave en ny import. 
Men det efterlader stadig kravet om opdatering... 

Jørgen 



Den 29. august 2019 03.25.02 GMT+07:00, Niels Elgaard Larsen  
skrev:
>Ja, det var da en god ide.
>
>
>==
>Ved brug af data fra Redningsnummer.dk accepterer du at opdatere data
>jævnligt og dermed holde de data du viser omverdenen ajour.
>==
>
>Hvad betyder det for os?
>Betyder det at den person, der begynder at importere data til OSM lover
>at blive med at gøre det?
>
>Og hvad hvis personen ikke gør det?
>OSM kan ikke være forpligtiget til at slette det hele igen.
>
>I øvrigt et fjollet krav. For de finder vel ikke på at flytte samme
>nummer fra een strand til en anden. Og der er ikke noget der forhindrer
>os I at putte en håndfuld redningsnumre i OSM baseret på fx Mapillary. 
>
>==
>Seneste opdateringsdato eller udtræksdato skal angives i brugerflade,
>hvis datasættet trækkes hjem i eget it-system og anvendes eksempelvis
>til at lave offline løsninger.
>==
>
>Vi eller OSM kan ikke forpligte brugerfladesystemer til den slags.
>Men man kan vel sige at selvom selvom redningsnumre kommer i OSM laver
>vi ikke en decideret offline løsning. Og der vil altid være en
>opdateringsdato i OSM.
>
>Men man kunne jo forestille sig at nogen fx lavede en app, der brugte
>redningsnumre fra hele verden baseret på OSM og ikke mente de skulle
>vise opdateringsdatoer i brugerfladen eller ikke kendte til
>redningsnummer.dk's regler.
>
>Jeg spiller bare djævelens advokat her. Jeg synes at det er en god ide.
>Men måske skulle vi for en sikkerheds skyld spørge dem om det ville
>være
>et problem.
>
>
>Anders Hedelund:
>> Er der nogen, der har overvejet at inkludere redningsskilte i OSM?
>> 
>> Det er de grønne, nummerede skilte, der står på strandene langs vore
>> kyster: http://www.redningsnummer.dk
>> 
>> Under "download" står der vilkår for anvendelsen, samt div. filer
>klar
>> til brug.
>> 
>> Billedresultat for redningsnumre
>> 
>> 
>> -- 
>> Med venlig Hilsen Anders Hedelund - and...@xoz.dk  +45 3990 5335 Mob:
>+45 6150 5335 TR: +90 531 831 0220
>> Et liv efter overlevelsen: http://iug.dk 
>> 
>> 
>> ___
>> Talk-dk mailing list
>> Talk-dk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-dk
>> 
>
>-- 
>Niels Elgaard Larsen
>
>___
>Talk-dk mailing list
>Talk-dk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-dk

-- 
Dette er sendt fra min mobiltelefon. Undskyld at jeg fatter mig i korthed.___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Bradley White]

> For example, US Hwy 101 is the main route connecting the cities (e.g.
> Eureka) and towns along the coast of northern California. Right now
> only some segments are tagged as highway=trunk. I would like to
> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> leaves 101 and heads to I-5, at Crescent City.

I did this a year or two ago, then changed it back following the
previous time this discussion came up last year. Someone else has
recently changed it back to trunk in its entirety as you describe (as
well as US 395, CA 70); I explained in a changeset comment that the
"major intercity highway where no motorway exists" definition (per
Highway:International_equivalence) is contentious and not commonly
used, but that I have no plans on reverting their changes.

Caltrans doesn't appear to have "divided" as a requirement for an
expressway build, or even necessarily a freeway (See:(California)
State Highway Map 2005; David Rumsey Map Collection) - these terms are
used to describe the level of access control on a given highway. US
101 through Redwood Ntl Park is signed with "Freeway Entrance" and is
fully access controlled, but is an undivided 4-lane road. Many 2-lane,
undivided roads are considered expressways in California, for example:

- Vasco Road connecting Antioch & Livermore
- Portions of CA 4 west of Angels Camp
- CA 108 east of Sonora (fully access controlled 2-lane road)

Once you know what to look for - reduced access to adjacent
properties, smoothed road geometry (esp. when bypassing old highways),
hard shoulders, usually 65 mph - they aren't too hard to differentiate
from conventional 2-lane highways with no access control. Where these
are obvious I generally tag them as trunk roads as opposed to primary.
Specifically in the case of CA 108, I reject that a fully access
controlled two-lane road is anything less than a trunk, if we have
decided to use 'trunk' to mean 'expressway'. California doesn't use
AASHTO definitions so I won't either.

Reno, NV has a couple urban arteries that straddle the divide between
trunk and primary (specifically: McCarran Blvd/NV 659, Pyramid Hwy/NV
445 north of McCarran, Veterans Pkwy, foothills portion of Mt. Rose
Hwy/NV 431). These roads carry traffic at speeds higher than other
nearby arteries (45-55 mph as opposed to 40 mph). They are built to
the highest level of access control specified by Washoe RTC -
generally no direct access to properties, except for retail/commercial
areas (where access is quite frequent), or rural areas where no other
roads provide access to properties. They range from undivided w/
center turn lane to divided with concrete jersey barriers & headlight
blinders (similar to a freeway). The majority of these roadways have
bike lanes, and many have sidewalks. They are quite similar to San
Jose's expressway system, except for a lack of grade-separated
interchanges. Are these primary, or trunk? I don't really know. They
currently sit at an awkward mix of trunk and primary depending on how
definitively myself and others think they are "expressways" or not.

I don't deny that "divided highway with partial control of access" is
a rigorous definition, with which it is certainly possible to tag
unambiguously with. I just question whether it is a good choice in the
US to use 'trunk' to mean 'expressway' in the same way that 'motorway'
means 'freeway', when the US has a formal freeway system, but lacks a
formal expressway system. Most other countries that also lack a formal
expressway system do not use the trunk/expressway definition (UK,
Canada, etc). In my area, sticking strictly to "divided highway with
partial control of access" means very few highways at all will see
'trunk' tagging. Certainly, this reflects what's on the ground here if
we use this definition - but why use a definition that either has to
be used ambiguously or seldom at all?

I support orthogonalizing expressways & trunk by using
'expressway=yes/no' for access control (maybe
access_control=full/partial/no?), 'highway=trunk' to mean non-freeway
road with national-level importance, and using 'oneway' to denote
whether a highway is divided or not. Then let rendering decide how to
draw the road from there. Want to see formal expressways drawn
separately? 'Expressway=yes' & 'oneway=yes'. Want a more general view
of the most important US highways? 'Highway=trunk'.

As it stands, I will continue to use 'trunk' on any section of highway
that is somewhere between a freeway and a conventional 2-lane highway
per US consensus. Hopefully one of these days consensus will shift.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[stevea]

I chime in as a North American (Upper Midwest, originally) that highway=trunk 
is a not-especially-clear semantic in OSM (here, let's say the lower 48).  I 
understand the history of the tag but agree it is used to mean many things, 
widely, including in the states/regions/areas Joseph mentions; it's a rich 
topic.

So far, discussion about expressway and motorway have been tangentially helpful 
(to me, maybe others).

We had to go "trunk is fuzzy in the USA" there, didn't we?  Yeah, we did, I 
guess.  Tag.  Tag well.

I consider whether to enter Silicon Valley's expressways (G routes) as an 
example of the Urban/Suburban Expressways in our expressway wiki.  Interesting 
bit o' history about those (they are the second of three tax phases of 
becoming-freeway).  They seem sort of frozen where they are now but they do get 
special, real-time data fed, kinda-cool lane signage which keeps traffic 
flowing.  Bikes are welcome on some, yes.

Actually, bike networks in Silicon Valley are an interesting construction 
project, both in the real world and OSM.

Tagging is tagging and discussion about tagging is discussion.  Thanks for good 
discussion.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

I checked and motorroad=yes in used in Spain for "Autovias" which are
like expressways, but they usually allow bicycles, just like many
expressways in the USA.

So the idea that motorroads prohibit bicycles and pedestrians is more
specific to France, Germany and some other countries, while in other
places the tag is more like the USA-specific expressway=* - a divided
highway with somewhat limited access, higher speeds, prioritizing
motor vehicle travel but not necessarily prohibiting bikes.

> I think it'd honestly be easier to get everyone to agree that it's time for 
> lanes=* to include all lanes, not just lanes of a minimum width accessible to 
> a pretty narrow selection of vehicles...

I don't quite understand this comment. Is it about bike lanes?

Are we sure that highway=trunk actually has a clear definition in
North America? It seems to be used differently in several places I've
checked; eg. California vs East Coast vs North Dakota.

On 8/29/19, Paul Johnson  wrote:
> On Wed, Aug 28, 2019 at 9:05 PM Joseph Eisenberg
> 
> wrote:
>
>> I don't have any local knowledge about old route 66 in OK, but I'd
>> like to address the use of highway=trunk in general.
>>
>> I'm in favor of using a secondary tags like motorroad=yes and
>> expressway=yes, along with other details like lanes=, surface=,
>> maxspeed=, etc, to specify expressways, rather than using
>> highway=trunk for this.
>>
>
> Ideally I'd prefer we started using tags that actually reflect what people
> call things in this country and have a lookup table on the wiki someplace
> for national equivalence, ie, highway=expressway, highway=freeway, etc,
> since the US tends to have more levels and nuance than the relatively easy
> "A/B/C/M/U" grading the British have officially that carries over there.
> We don't really have motorroad as a well defined thing here, either, even
> about 3/5ths of the states allow pedestrians and bicycles on most
> freeways.  Using trunks for expressways does give a pretty well defined
> expectation of what you're going to be experiencing as it's used now.
>
> Like the distinctions between primary/secondary/tertiary, trunk was
>> originally intended to describe the role of a road in the network.
>> While most trunk highways are divided and have more than 1 lane in
>> each direction in densely-populated areas, it's quite normal for to
>> have narrower roads as the main route between 2 cities, in
>> sparsely-populated parts of the country.
>>
>
> Well, literally the official designation of the highway, before the project
> jumped outside the UK.
>
>
>> For example, US Hwy 101 is the main route connecting the cities (e.g.
>> Eureka) and towns along the coast of northern California. Right now
>> only some segments are tagged as highway=trunk. I would like to
>> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
>> leaves 101 and heads to I-5, at Crescent City.
>>
>
> I'm not sure that's really worth revisiting so much; seems for the US as we
> have it now.  NE2 nationally torque-tagged everything in network=US:US as
> trunk and that seems to have broken the already established trunk.
>
>
>> The segments that are divided and wider can be tagged expressway=yes,
>> lanes=4, maxspeed=, etc, so if people want to render these differently
>> they can (routers are probably more interested in the number of
>> intersections, traffic signals, lanes, maxspeed, and surface, so the
>> expressway=* tag isn't really needed).
>>
>
> I think it'd honestly be easier to get everyone to agree that it's time for
> lanes=* to include all lanes, not just lanes of a minimum width accessible
> to a pretty narrow selection of vehicles than redefine highway=trunk in
> North America at this point.  Certainly a lot less subjective.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:15 PM stevea  wrote:

>
> > Eeeeh, that's gonna be a hard sell for the most part, most Oklahoma
> expressways are built like this as are parts of Interstate freeways, with
> the only real difference between the two being at-grade intersections and
> limited driveways (as opposed to getting to install driveways virtually
> anywhere you want on it).  Indian Nation Turnpike is a great example of
> this.  Save for being fully controlled access from the get-go meriting a
> motorway tag, it's of substantially the same design and in about the same
> condition as the expressway portions of 66.
> https://openstreetcam.org/details/1119877/3443/track-info
>
> So, trunk is wrong?  Your link appears to display an old road, re-paved
> many times, but I wouldn't call it a bad road, maybe intermediate or good.
>

Well, on the INT it would be, it's tagged as motorway because it's
controlled and limited access with dual carriageway.  The section of 66
we're talking about is trunk because it's only semi controlled and only
loosely limited access.


> > When there's more driveways, it either narrows and becomes a boulevard
> (like US 75 does for a couple kilometers in Okmulgee,
> https://openstreetcam.org/details/1119877/803/track-info;
>
> If but for the driveway, that looks like trunk, but the driveway makes me
> say primary or secondary.
>

Expressways tend to have more rules on how you can connect a driveway up to
one and how frequently they appear, not that driveways are banned nearly
entirely.  They're not anywhere near as common as you might get with a
primary, and driveways are usually but not always grouped together where
they meet the highway compared to what you'd normally expect on a primary.


> > or US 64 does entering Muskogee,
> https://openstreetcam.org/details/1366842/204/track-info)
>
> Nice example of a similar (to above) transitioning to / from "median
> divided road" to "simply double-yellow line divided" (no median).  I don't
> think this is trunk, again, depending on daily traffic and speeds, I'd say
> primary or secondary here, but not trunk.
>

Obviously I disagree.  ODOT might just take up the road and convert it down
to a boulevard later (especially if the impending bordering incipient
expressway revolt starting to take root in places like Muskogee take deeper
root), but that would be pretty typical of an inline transition at the end
of an expressway pretty much anywhere in the midwest.  If all you need to
do beyond severing driveways is add an overpass and ramps to make it a
freeway, you're probably looking at a trunk, it's not always controllable
how things organically develop around edges of towns.  Another good example
is about a mile west where US 69 goes into Muskogee.  It used to be a solid
expressway down to McAlester, but over the course of the 2000s they started
adding grade separated ramps, and this decade they spent severing driveways
and at-grade crossings from Wainright Road to the south end of OK 113
making that 75 km stretch a motorway.

I get the frustration.  There's a lot of Oklahoma that looks weird because
of the expressways seemingly scattergunned across the state.  But, that's a
reflection of reality.  And that reality is a bit of the root cause of the
pushback the public's giving ODOT on new expressways and freeways now,
because there's so much unnecessary capacity that was built up without any
coherent plan or clear justification for building it, often while
overlooking more pressing needs like maintaining what already exists,
bordering on absurdity.


> > or frontages are added to wrangle driveway traffic with connections to
> and from the expressway and the frontage being closer in frequency to what
> you would get for driveways in somewhat rural expressways (for example, the
> George Nigh Expressway in McAlester,
> https://openstreetcam.org/details/48220/5369/track-info),
>
> Here, driveways make me want to hold my nose at trunk (though it otherwise
> looks like one), so again, primary if speeds and ADT #s (daily average
> traffic counts) warrant it, otherwise, secondary.  (Though, large
> 18-wheelers / semis hauling discourages me from saying secondary).
>

That's where things get a little sticky, sure.  ODOT built most of the
expressways and all of the turnpikes with aspirations that Oklahoma would
be as populated as California and often rammed through expressways on that
assumption.  There's just a lot of examples where ODOT tried to kill a fly
with a cruise missile and missed.  AADT on the examples I've given in
Muskogee and McAlester so far are all at least 1.

US 69 examples are 15000 on the motorway portions and in McAlester where
it's an expressway with frontage roads, it's about 20100.  In Muskogee,
where US 69 passes through as a single carriageway primary street, it's
about 22000, getting significantly more traffic than the turnpike a couple
kilometers east.  Plans to build a freeway bypass through the neighborhoods
on the west 

[Talk-bo] Errores en instrucciones Tarea HOT OSM en Roboré

[Marco Antonio]

Hola,

Alguien activó el mapeo en HOTOSM sobre el área residencial de Roboré,
y leyendo las instrucciones menciona:

* alinear todas los caminos a la nueva imagen satelital MAXAR que provee HOTOSM

Es un error, en Bolivia las imagenes satelitales de MAXAR, ESRI tienen
desplazamientos respecto a los datos y no al revés... en la zona
andina se nota más estos desplazamientos, en la zona de los llanos es
menor pero existe desplazamiento

Ya existe ediciones que están realineando las calles, sugiero
contactar y corregir esto en las instrucciones que mencione que se
ajuste el desplazamiento previa edición. La imagen Bing en toda
bolivia no tiene desplazamientos

Abrazos,

Marco Antonio

___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:05 PM Joseph Eisenberg 
wrote:

> I don't have any local knowledge about old route 66 in OK, but I'd
> like to address the use of highway=trunk in general.
>
> I'm in favor of using a secondary tags like motorroad=yes and
> expressway=yes, along with other details like lanes=, surface=,
> maxspeed=, etc, to specify expressways, rather than using
> highway=trunk for this.
>

Ideally I'd prefer we started using tags that actually reflect what people
call things in this country and have a lookup table on the wiki someplace
for national equivalence, ie, highway=expressway, highway=freeway, etc,
since the US tends to have more levels and nuance than the relatively easy
"A/B/C/M/U" grading the British have officially that carries over there.
We don't really have motorroad as a well defined thing here, either, even
about 3/5ths of the states allow pedestrians and bicycles on most
freeways.  Using trunks for expressways does give a pretty well defined
expectation of what you're going to be experiencing as it's used now.

Like the distinctions between primary/secondary/tertiary, trunk was
> originally intended to describe the role of a road in the network.
> While most trunk highways are divided and have more than 1 lane in
> each direction in densely-populated areas, it's quite normal for to
> have narrower roads as the main route between 2 cities, in
> sparsely-populated parts of the country.
>

Well, literally the official designation of the highway, before the project
jumped outside the UK.


> For example, US Hwy 101 is the main route connecting the cities (e.g.
> Eureka) and towns along the coast of northern California. Right now
> only some segments are tagged as highway=trunk. I would like to
> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> leaves 101 and heads to I-5, at Crescent City.
>

I'm not sure that's really worth revisiting so much; seems for the US as we
have it now.  NE2 nationally torque-tagged everything in network=US:US as
trunk and that seems to have broken the already established trunk.


> The segments that are divided and wider can be tagged expressway=yes,
> lanes=4, maxspeed=, etc, so if people want to render these differently
> they can (routers are probably more interested in the number of
> intersections, traffic signals, lanes, maxspeed, and surface, so the
> expressway=* tag isn't really needed).
>

I think it'd honestly be easier to get everyone to agree that it's time for
lanes=* to include all lanes, not just lanes of a minimum width accessible
to a pretty narrow selection of vehicles than redefine highway=trunk in
North America at this point.  Certainly a lot less subjective.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Evin Fairchild]

I totally agree with this! As I've stated before, I've long thought that
most US highways should be tagged as trunk roads. Heck, someone recently
tagged US 101 in Washington as trunk but I have no interest in changing it
back because I agree with the way it's tagged. That would be more in line
with the definition of a trunk road as started on the wiki. And I totally
support the use of the expressway tag.

-Evin

On Wed, Aug 28, 2019, 7:06 PM Joseph Eisenberg 
wrote:

> I don't have any local knowledge about old route 66 in OK, but I'd
> like to address the use of highway=trunk in general.
>
> I'm in favor of using a secondary tags like motorroad=yes and
> expressway=yes, along with other details like lanes=, surface=,
> maxspeed=, etc, to specify expressways, rather than using
> highway=trunk for this.
>
> Like the distinctions between primary/secondary/tertiary, trunk was
> originally intended to describe the role of a road in the network.
> While most trunk highways are divided and have more than 1 lane in
> each direction in densely-populated areas, it's quite normal for to
> have narrower roads as the main route between 2 cities, in
> sparsely-populated parts of the country.
>
> For example, US Hwy 101 is the main route connecting the cities (e.g.
> Eureka) and towns along the coast of northern California. Right now
> only some segments are tagged as highway=trunk. I would like to
> upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
> leaves 101 and heads to I-5, at Crescent City.
>
> The segments that are divided and wider can be tagged expressway=yes,
> lanes=4, maxspeed=, etc, so if people want to render these differently
> they can (routers are probably more interested in the number of
> intersections, traffic signals, lanes, maxspeed, and surface, so the
> expressway=* tag isn't really needed).
>
> On 8/29/19, Paul Johnson  wrote:
> > On Wed, Aug 28, 2019 at 7:04 AM stevea 
> wrote:
> >
> >> Hi Paul, Hi Volker, Hi talk-us:
> >>
> >> The topic begs the question as to what such (usually very) old,
> >> poor-condition (where they ARE poor) roads should be tagged (we limit
> >> ourselves to US roads here because this is talk-us), and at what
> >> granularity.  (Volker COULD do detailed tagging, but I hear loud and
> >> clear
> >> he prefers high-granularity tagging, as do I, though we all recognize
> how
> >> tedious this can be).  And "old 66" is a quintessential example, many
> >> segments are a century old or older:  it is known as "the Mother road"
> by
> >> many.  BTW, many public agencies under the umbrella of Southern
> >> California
> >> Association of Governments are working on developing USBR 66 in
> >> California
> >> for cyclists (the route number choice is no coincidence as some
> >> alignments
> >> follow the old Mother road).  This was actually in OSM as an early
> >> proposed
> >> route, but was removed to conform to USBRS proposed route conventions.
> >> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
> >> will re-enter these data.  It makes sense to pay close attention to the
> >> underlying infrastructure tagging (tertiary, surface, smoothness...) as
> >> we
> >> do so since these are important to cyclists.
> >>
> >
> > So, the segment in question given in the example to me (I don't think the
> > response was intended only for me, so I'm not quoting the whole thing) is
> > https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
> > from November 2018 on it at
> > https://openstreetcam.org/details/1305935/3747/track-info, showing it's
> a
> > pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
> > slowing towards its eastern end, and is currently a part of OK 66.
> >
> > I think a better argument for downgrading from trunk exists in Southern
> > California if it hasn't been downgraded already.  There's some decent
> > chunks east of Indio in San Bernardino County off the top of my head that
> > were clearly constructed as trunks, have since left Caltrans inventory
> and
> > are now county roads, and SB County has just let one side of the road rot
> > off, running both directions undivided on the other (usually the former
> > westbound-only carriageway, from memory, as last I drove it I was going
> > eastbound, the center divider was on my right, and it looked like the
> other
> > side hadn't been usable for at least a decade with weeds and huge cracks
> > growing out of the abandoned carriageway).
> >
> > A case can be made for highway=trunk (for connectivity reasons) yet I do
> >> resonate with "secondary at best" for such old, poor roads.  Tagging
> >> highway=trunk is about as high a classification as the very best
> portions
> >> of this road will ever get, and only on its highest-speed segments which
> >> are divided.  This implies highway=tertiary (MAYBE secondary) where the
> >> road is NOT dual carriageway, as highway=trunk in the USA means "with a
> >> barrier or median separating each direction 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[stevea]

On Aug 28, 2019, at 6:16 PM, Paul Johnson  wrote:
> So, the segment in question given in the example to me (I don't think the 
> response was intended only for me, so I'm not quoting the whole thing) is 
> https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage from 
> November 2018 on it at 
> https://openstreetcam.org/details/1305935/3747/track-info, showing it's a 
> pretty typical Oklahoma expressway, 55 MPH speed limit for most of it, 
> slowing towards its eastern end, and is currently a part of OK 66.

Looks like trunk, tagged as trunk.  Again, I'm not saying every road should be 
downgraded from trunk, merely those which are not trunk, and there certainly 
are some, in Oklahoma, California, as well as many other states along the 
alignment(s).

> I think a better argument for downgrading from trunk exists in Southern 
> California if it hasn't been downgraded already.  There's some decent chunks 
> east of Indio in San Bernardino County off the top of my head that were 
> clearly constructed as trunks, have since left Caltrans inventory and are now 
> county roads, and SB County has just let one side of the road rot off, 
> running both directions undivided on the other (usually the former 
> westbound-only carriageway, from memory, as last I drove it I was going 
> eastbound, the center divider was on my right, and it looked like the other 
> side hadn't been usable for at least a decade with weeds and huge cracks 
> growing out of the abandoned carriageway).

Yes, these are definitely downgradable from trunk.  While JOSM complains about 
the tag, highway=road could be used temporarily, though the "open" (to 
vehicular traffic) might end up being tagged highway=tertiary, the weedy, 
abandoned road likely gets abandoned:highway=unclassified.  I'm not sure if/how 
the latter renders, so it might "look weird,"  but that wouldn't be the first 
time we tag accurately and think "that looks weird."  If it is accurate 
tagging, so be it (how it renders).

> A case can be made for highway=trunk (for connectivity reasons) yet I do 
> resonate with "secondary at best" for such old, poor roads.  Tagging 
> highway=trunk is about as high a classification as the very best portions of 
> this road will ever get, and only on its highest-speed segments which are 
> divided.  This implies highway=tertiary (MAYBE secondary) where the road is 
> NOT dual carriageway, as highway=trunk in the USA means "with a barrier or 
> median separating each direction of traffic" (truly dual carriageway).  Yes, 
> it is appropriate to tag highway=secondary on some segments, I believe these 
> to be in the minority compared to tertiary (which likely makes up the 
> majority of what remains of this route in many states).
> 
> I could see secondary or tertiary for the non-expressway portions (though 
> most of it is state highway, so that would be secondary at lowest for the 
> parts that are currently part of state highways).  But it does have among the 
> longest portions of still-extant expressway portions, mostly still in the 
> state highway inventory here in Oklahoma.

California has state highways which are highway=tertiary (one example is 
Skyline Drive / Hwy 35 in the Santa Cruz Mountains), though I've driven this 
many times and there is one segment which is essentially residential:  the road 
is essentially single-lane (maybe ten feet / 3 m wide), is quite sinuous, has a 
"basic speed law" (drive only as fast as is safe) of approximately 15 MPH 
(narrow, windy) and has family (live-on) farms on either side of it;  
https://www.osm.org/way/37438761.  I entertain good arguments for either 
highway=residential or highway=unclassified on this segment, as 
highway=tertiary seems seriously over-generous.  Yet, it is a state highway, 
linking, say, the mountain village of La Honda with Bear Creek Road access to 
(state) Highway 17, the major artery over the central portion of the Santa Cruz 
Mountains.

> I also say including a surface=* tag is important, so is a smoothness=* tag 
> (though that has its controversies) where this is known or meets / falls 
> below value intermediate (or so).
> 
> I think it's important to disconnect the idea of surface=* and smoothness=* 
> from highway=* in most cases.  If surface and smoothness factored into it, 
> that really opens up I 5 in Portland until relatively recently (like, before 
> about 2013) to question it's motorway status, as it's 50 and 55 MPH speed 
> limits being way too fast without damaging tires on the potholes or 
> hydroplaning the ruts.

I can see something being tagged highway=motorway and smoothness=intermediate 
(or even worse), if they describe that Oregon segment of I-5 before it was 
re-paved.  I think that if a smoothness=intermediate or smoothness=bad tag 
exists, it is there for good reason.

> Let's agree that simply tagging highway=trunk is often incorrect when dual 
> carriageways of highway=tertiary with accurate surface=* (and sure, 
> 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Joseph Eisenberg]

I don't have any local knowledge about old route 66 in OK, but I'd
like to address the use of highway=trunk in general.

I'm in favor of using a secondary tags like motorroad=yes and
expressway=yes, along with other details like lanes=, surface=,
maxspeed=, etc, to specify expressways, rather than using
highway=trunk for this.

Like the distinctions between primary/secondary/tertiary, trunk was
originally intended to describe the role of a road in the network.
While most trunk highways are divided and have more than 1 lane in
each direction in densely-populated areas, it's quite normal for to
have narrower roads as the main route between 2 cities, in
sparsely-populated parts of the country.

For example, US Hwy 101 is the main route connecting the cities (e.g.
Eureka) and towns along the coast of northern California. Right now
only some segments are tagged as highway=trunk. I would like to
upgrade all of it to highway=trunk, up to Hwy 199, where most traffic
leaves 101 and heads to I-5, at Crescent City.

The segments that are divided and wider can be tagged expressway=yes,
lanes=4, maxspeed=, etc, so if people want to render these differently
they can (routers are probably more interested in the number of
intersections, traffic signals, lanes, maxspeed, and surface, so the
expressway=* tag isn't really needed).

On 8/29/19, Paul Johnson  wrote:
> On Wed, Aug 28, 2019 at 7:04 AM stevea  wrote:
>
>> Hi Paul, Hi Volker, Hi talk-us:
>>
>> The topic begs the question as to what such (usually very) old,
>> poor-condition (where they ARE poor) roads should be tagged (we limit
>> ourselves to US roads here because this is talk-us), and at what
>> granularity.  (Volker COULD do detailed tagging, but I hear loud and
>> clear
>> he prefers high-granularity tagging, as do I, though we all recognize how
>> tedious this can be).  And "old 66" is a quintessential example, many
>> segments are a century old or older:  it is known as "the Mother road" by
>> many.  BTW, many public agencies under the umbrella of Southern
>> California
>> Association of Governments are working on developing USBR 66 in
>> California
>> for cyclists (the route number choice is no coincidence as some
>> alignments
>> follow the old Mother road).  This was actually in OSM as an early
>> proposed
>> route, but was removed to conform to USBRS proposed route conventions.
>> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
>> will re-enter these data.  It makes sense to pay close attention to the
>> underlying infrastructure tagging (tertiary, surface, smoothness...) as
>> we
>> do so since these are important to cyclists.
>>
>
> So, the segment in question given in the example to me (I don't think the
> response was intended only for me, so I'm not quoting the whole thing) is
> https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
> from November 2018 on it at
> https://openstreetcam.org/details/1305935/3747/track-info, showing it's a
> pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
> slowing towards its eastern end, and is currently a part of OK 66.
>
> I think a better argument for downgrading from trunk exists in Southern
> California if it hasn't been downgraded already.  There's some decent
> chunks east of Indio in San Bernardino County off the top of my head that
> were clearly constructed as trunks, have since left Caltrans inventory and
> are now county roads, and SB County has just let one side of the road rot
> off, running both directions undivided on the other (usually the former
> westbound-only carriageway, from memory, as last I drove it I was going
> eastbound, the center divider was on my right, and it looked like the other
> side hadn't been usable for at least a decade with weeds and huge cracks
> growing out of the abandoned carriageway).
>
> A case can be made for highway=trunk (for connectivity reasons) yet I do
>> resonate with "secondary at best" for such old, poor roads.  Tagging
>> highway=trunk is about as high a classification as the very best portions
>> of this road will ever get, and only on its highest-speed segments which
>> are divided.  This implies highway=tertiary (MAYBE secondary) where the
>> road is NOT dual carriageway, as highway=trunk in the USA means "with a
>> barrier or median separating each direction of traffic" (truly dual
>> carriageway).  Yes, it is appropriate to tag highway=secondary on some
>> segments, I believe these to be in the minority compared to tertiary
>> (which
>> likely makes up the majority of what remains of this route in many
>> states).
>>
>
> I could see secondary or tertiary for the non-expressway portions (though
> most of it is state highway, so that would be secondary at lowest for the
> parts that are currently part of state highways).  But it does have among
> the longest portions of still-extant expressway portions, mostly still in
> the state highway inventory here in Oklahoma.
>
>
>> I also say including 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 9:10 AM Kevin Kenny  wrote:

> 'Historic US 66' is a bannered and numbered route because of its
> history, not because of its current importance to the road system. The
> constituent ways should be tagged as whatever they are currently in
> the road network. In many places, 'Historic US 66' no longer follows
> the historic route of the road because the road is no longer passable
> or no longer has good connections to the highway network. For example,
> from Flagstaff, Arizona to the New Mexico state line (except for brief
> detours through Winslow and Holbrook) the bannered 'Historic Route 66'
> is highway=motorway because the construction of I-40 obliterated or
> disconnected the old route.  (I don't know whether I-40 actually bears
> the signage anywhere.)
>

It does, sporadically, as of the last time I was that far west on 66.  And
there's also places like in Tulsa where there's multiple old alignments,
all of which are signed as Historic 66.  In order of mundane to strange,
would be its final alignment on what's now I 44, a couple major section
line boulevards across north Tulsa, an otherwise fairly anonymous two lane
road running between flood control ponds in a residential neighborhood,
what's now a quiet light industrial and residential street about a block
from where America's first yield sign once stood, and a staircase.

There are places where the old road exists on the ground and bears the
> name, but are not bannered because a road fails to connect or is no
> longer reliably passable to low-clearance automobiles. The route can
> be followed for some distance east and west of Exit 303, for instance.
> It's at most an 'unclassified' road and connects mostly to tracks. At
> the east end of that run, there's no crossing of I-40, and the road
> simply turns right onto another track. On the other side of the
> freeway, the pavement resumes, but in Petrified Forest it's
> unmaintained and has deteriorated to where it is neither safe nor
> lawful to drive. East of there, it's a track at best, and again ends
> at a freeway crossing without an interchange.  On the far side, it's a
> minor rural road (County Road 7385)
> https://www.openstreetmap.org/way/16792461, then crosses the freeway
> at McCarrell and becomes the freeway frontage road in Chambers. If
> memory serves, some of the tracks that remain in use are no longer
> public rights-of-way, and neither the ranchers nor the Navajo Nation
> welcome visitors on them.
>

Pueblo Laguna still has Indian Road L66, but they've intentionally removed
the pavement, and the signage along the road telling you not to take
pictures and that they do not want visitors makes it pretty clear that
you're merely tolerated so long as you're minding your own business, taking
only memories and leaving only tire tracks in the dust (though I think this
might be in New Mexico...I was conserving the food and water I had on hand
in case I got stuck and was taking the trip solo in a borderline overloaded
car after having emptied a storage unit, so I wasn't exactly traveling
under ideal conditions, L66 was easily the worst-maintained portion I was
willing to risk).


> In western Arizona, from Kingman to Seligman, the historic way is in
> service, is bannered 'AZ 66' and is at least 'secondary'.


About the only other classification I could see for that is primary, and
that's only because of it's relative historical value as a through route
that people come from around the world to drive, and (deep memory dive on
this) it's set up with permanent turnable/foldable signs to work as I 40
Detour in emergencies on the freeway.  ADOT bought the rights to Burma
Shave's branding just to maintain their own Burma Shave signs along that
section (amusingly, these are retroreflective metal signs made to roughly
the same physical specs as the standard MUTCD signs along the road).


> East of
> Seligman, it exists as Crookson Road and 'Old US 66, but diminishes to
> a track and disappears at a corner where it crosses neither I-40 nor
> the Phoenix spur of the Santa Fe. Between there are Flagstaff, there
> are fragmentary tracks, and some, such as
> https://www.openstreetmap.org/way/16792461 are entirely isolated from
> the road network. West of Kingman, it's County Road 10, and at least
> it used to be challenging to drive because it was a narrow and badly
> deteriorated road in mountainous terrain. The only community on the
> route is Oatman, which has enjoyed something of a resurgence as a
> tourist destination, "come see the ghost town where wild burros roam
> the streets." I'd say it's probably 'tertiary' because in that desert,
> it doesn't take much to make a road important.
>

It's still pretty rough and it's still a twisty drive, with the speed limit
being 15 MPH in places, IIRC.  Speed limit enforced by burro.  Wanted to
see the fire station for their restored, roofless firetrucks, but the
closest I could legally get to it was a block away because apparently 

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Paul Johnson]

On Wed, Aug 28, 2019 at 7:04 AM stevea  wrote:

> Hi Paul, Hi Volker, Hi talk-us:
>
> The topic begs the question as to what such (usually very) old,
> poor-condition (where they ARE poor) roads should be tagged (we limit
> ourselves to US roads here because this is talk-us), and at what
> granularity.  (Volker COULD do detailed tagging, but I hear loud and clear
> he prefers high-granularity tagging, as do I, though we all recognize how
> tedious this can be).  And "old 66" is a quintessential example, many
> segments are a century old or older:  it is known as "the Mother road" by
> many.  BTW, many public agencies under the umbrella of Southern California
> Association of Governments are working on developing USBR 66 in California
> for cyclists (the route number choice is no coincidence as some alignments
> follow the old Mother road).  This was actually in OSM as an early proposed
> route, but was removed to conform to USBRS proposed route conventions.
> If/as USBR 66 turns into a Caltrans (DOT) route proposal to AASHTO, OSM
> will re-enter these data.  It makes sense to pay close attention to the
> underlying infrastructure tagging (tertiary, surface, smoothness...) as we
> do so since these are important to cyclists.
>

So, the segment in question given in the example to me (I don't think the
response was intended only for me, so I'm not quoting the whole thing) is
https://www.openstreetmap.org/way/14678570/.  OpenStreetCam has footage
from November 2018 on it at
https://openstreetcam.org/details/1305935/3747/track-info, showing it's a
pretty typical Oklahoma expressway, 55 MPH speed limit for most of it,
slowing towards its eastern end, and is currently a part of OK 66.

I think a better argument for downgrading from trunk exists in Southern
California if it hasn't been downgraded already.  There's some decent
chunks east of Indio in San Bernardino County off the top of my head that
were clearly constructed as trunks, have since left Caltrans inventory and
are now county roads, and SB County has just let one side of the road rot
off, running both directions undivided on the other (usually the former
westbound-only carriageway, from memory, as last I drove it I was going
eastbound, the center divider was on my right, and it looked like the other
side hadn't been usable for at least a decade with weeds and huge cracks
growing out of the abandoned carriageway).

A case can be made for highway=trunk (for connectivity reasons) yet I do
> resonate with "secondary at best" for such old, poor roads.  Tagging
> highway=trunk is about as high a classification as the very best portions
> of this road will ever get, and only on its highest-speed segments which
> are divided.  This implies highway=tertiary (MAYBE secondary) where the
> road is NOT dual carriageway, as highway=trunk in the USA means "with a
> barrier or median separating each direction of traffic" (truly dual
> carriageway).  Yes, it is appropriate to tag highway=secondary on some
> segments, I believe these to be in the minority compared to tertiary (which
> likely makes up the majority of what remains of this route in many states).
>

I could see secondary or tertiary for the non-expressway portions (though
most of it is state highway, so that would be secondary at lowest for the
parts that are currently part of state highways).  But it does have among
the longest portions of still-extant expressway portions, mostly still in
the state highway inventory here in Oklahoma.


> I also say including a surface=* tag is important, so is a smoothness=*
> tag (though that has its controversies) where this is known or meets /
> falls below value intermediate (or so).
>

I think it's important to disconnect the idea of surface=* and smoothness=*
from highway=* in most cases.  If surface and smoothness factored into it,
that really opens up I 5 in Portland until relatively recently (like,
before about 2013) to question it's motorway status, as it's 50 and 55 MPH
speed limits being way too fast without damaging tires on the potholes or
hydroplaning the ruts.

Let's agree that simply tagging highway=trunk is often incorrect when dual
> carriageways of highway=tertiary with accurate surface=* (and sure,
> smoothness=*) tags would be much more accurate and preferred.
>

Eeeeh, that's gonna be a hard sell for the most part, most Oklahoma
expressways are built like this as are parts of Interstate freeways, with
the only real difference between the two being at-grade intersections and
limited driveways (as opposed to getting to install driveways virtually
anywhere you want on it).  Indian Nation Turnpike is a great example of
this.  Save for being fully controlled access from the get-go meriting a
motorway tag, it's of substantially the same design and in about the same
condition as the expressway portions of 66.
https://openstreetcam.org/details/1119877/3443/track-info

When there's more driveways, it either narrows and becomes a boulevard
(like US 75 does for 

Re: [OSM-talk-fr] Traductions de page wiki OSM en français

[François Lacombe]

Salut à tous,

J'ai apporté ma pierre à l'édifice de la traduction avec les pages
suivantes :
https://wiki.openstreetmap.org/wiki/FR:Tag:pipeline%3Dvalve
https://wiki.openstreetmap.org/wiki/FR:Key:valve
https://wiki.openstreetmap.org/wiki/FR:Key:handle
https://wiki.openstreetmap.org/wiki/FR:Key:actuator
https://wiki.openstreetmap.org/wiki/FR:Key:turn_to_close
https://wiki.openstreetmap.org/wiki/FR:Key:line_attachment
https://wiki.openstreetmap.org/wiki/FR:Tag:line_attachment%3Dsuspension
https://wiki.openstreetmap.org/wiki/FR:Tag:line_attachment%3Danchor
https://wiki.openstreetmap.org/wiki/FR:Tag%3Aline_attachment%3Dpin
https://wiki.openstreetmap.org/wiki/FR:Tag%3Aline_attachment%3Dpulley
https://wiki.openstreetmap.org/wiki/FR:Key:telecom

A noter que désormais, pour les pages existant depuis un certain temps, les
traductions des infosbox en tête de page peuvent être directement faites
dans les DataItems correspondants
Pour cela, dans l'infobox, cliquez sur le petit crayon gris à côté de la
description. Un nouveau monde va s'ouvrir à vous.
Il suffit normalement de supprimer le champ dans le wikicode de l'infobox
pour qu'il aille automatiquement chercher ce qui est disponible dans le
dataitem (photos, primitives autorisées, statut, combinaisons...)
Les pages seront plus facilement tenues en cohérence entre les différentes
langues.
Plus d'informations : https://wiki.openstreetmap.org/wiki/Data_items
(Désolé pas encore disponible en français)

Bonne soirée

François


Le mar. 27 août 2019 à 19:34,  a écrit :

> J'ai un soucis avec https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
>
> J'ai l'impression d'avoir fait planter le serveur (j'ai juste demander à
> éditer un wiki code, donc c'est sans doute un hasard).
>
> --
>
> [39d923ab34c0d9133165ff3b] 2019-08-27 17:33:07: Erreur fatale de type «
> Wikimedia\Rdbms\DBQueryError »
>
> --
>
> MediaWiki internal error.
>
> Original exception: [c100f4745417949dd22aaf0c] 2019-08-27 17:30:56: Fatal
> exception of type "Wikimedia\Rdbms\DBQueryError"
>
> Exception caught inside exception handler.
>
> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to
> show detailed debugging information.
>
>
> Le 25/08/2019 à 13:57, gnrc69 via Talk-fr - talk-fr@openstreetmap.org a
> écrit :
>
> Hello tout le monde,
>
> Les pages suivantes sont aussi traduites en FR :
> https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
> https://wiki.openstreetmap.org/wiki/FR:Séparateur_de_valeur_point-virgule
>
> Merci aux relecteurs potentiels
>
> gnrc69 - OSM Lyon
>
> --
> *De: *g...@laposte.net
> *À: *"severin.menard" 
> , "Discussions sur OSM en français"
>  
> *Cc: *hot-francoph...@openstreetmap.org
> *Envoyé: *Vendredi 9 Août 2019 15:24:17
> *Objet: *Re:  [OSM-talk-fr] Traductions de page wiki OSM en français
>
> Hello tous,
>
> Je viens de terminer la traduction en FR des pages :
>
> https://wiki.openstreetmap.org/wiki/Key:drinking_water
> https://wiki.openstreetmap.org/wiki/FR:Espaces_de_noms
>
> Si certains veulent faire une relecture, car mon prof de langue a encore
> beaucoup à apprendre, il s'appelle G...gle !
>
> PS: ATTENTION pour "abandoned", il existe une page EN et partiellement FR
> https://wiki.openstreetmap.org/wiki/Key:abandoned: dont la traduction est
> à terminer ;
> mais aussi une page EN non traduite en FR
> https://wiki.openstreetmap.org/wiki/Key:abandoned qui devrait se limiter
> aux recommandations de non-utilisation de abandoned=*
> Il pourrait aussi être judicieux de fusionner les deux pages.
>
> Amicalement
> gnrc69 OSM Lyon
>
> --
> *De: *"severin.menard via Talk-fr" 
> 
> *À: *talk-fr@openstreetmap.org, hot-francoph...@openstreetmap.org
> *Cc: *"severin.menard" 
> 
> *Envoyé: *Jeudi 11 Juillet 2019 22:03:58
> *Objet: * [OSM-talk-fr] Traductions de page wiki OSM en français
>
> Bonsoir à tous,
>
> J'ai traduit en français la semaine dernière la page wiki intitulée *Any
> tag you like* qui explique les fondamentaux de la création d'attributs
> dans OSM :
>
> https://wiki.openstreetmap.org/wiki/FR:Cr%C3%A9er_un_attribut_qui_manque
>
> J'ai remarqué que pas mal de pages wiki en lien dans cette page restaient
> en mal de traduction en français, si certains sont motivés :
>
> https://wiki.openstreetmap.org/wiki/Names#Localization
> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
> https://wiki.openstreetmap.org/wiki/FR:Espaces_de_noms
>
> Même chose pour certaines clés, par exemple :
>
> https://wiki.openstreetmap.org/wiki/Key:drinking_water
> https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
>
> Séverin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> 

Re: [Talk-de] Karte mit shop=yes Orten

[Hauke Stieler]

Moin,

aber auch ein Geschäft an/in einer Tankstelle geht doch genauer als "ja,
da ist ein Geschäft" oder nicht? Manchmal ist ja ein halber Supermarkt
drin, manchmal aber auch nur ein kleiner Laden mit Snacks und Getränken.

Finde nicht, dass das ein false-positive ist, auch das Wiki verstehe ich
so, dass es durchaus genauer geht [0]. Und wenn man nichts genaueres
weiß/erkennen kann, dann ist das leider so, aber immerhin hat man es
versucht ;)

Grüße
Hauke

[0]
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services

On 28.08.19 23:36, Michael Bemmerl wrote:
> Moin,
> 
> Hauke Stieler schrieb:
>> da ja ab jetzt Orte mit "shop=yes" im Carto-Style nicht mehr gerendert
>> werden, habe ich mir mal angeschaut welche das sind und eine Karte für
>> Deutschland erstellt.
>>
>> https://umap.openstreetmap.fr/en/map/shopyes-in-deutschland_358119
> 
> Auf der Karte sind die Tankstellen nicht herausgefiltert worden. Somit
> sind da viele false positive drin.
> 
> Grüße,
> Michael
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Karte mit shop=yes Orten

[Michael Bemmerl]

Moin,

Hauke Stieler schrieb:
> da ja ab jetzt Orte mit "shop=yes" im Carto-Style nicht mehr gerendert
> werden, habe ich mir mal angeschaut welche das sind und eine Karte für
> Deutschland erstellt.
> 
> https://umap.openstreetmap.fr/en/map/shopyes-in-deutschland_358119

Auf der Karte sind die Tankstellen nicht herausgefiltert worden. Somit
sind da viele false positive drin.

Grüße,
Michael


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-es] Ediciones masivas en España

[Miguel Sevilla-Callejo]

Hola,

Estoy totalmente de acuerdo con Jorge, la cosa es saber cómo abordar el 
tema para, primero, documentarlo, y luego realizar los cambios de manera 
escalonada.


Y con esto último quiero decir que se realicen las ediciones de modo que 
no se generen conjuntos de cambios muy grandes que puedan suponer un 
problema de cara a revisiones posteriores en los datos.


Quizá la manera de realizarlo por lotes y/o por regiones concretas.

Yo cuando me he encontrado estas etiquetas las voy corrigiendo poco a 
poco según me voy moviendo por el mapa. Veasé, por ejemplo, que el otro 
día encontré un amenity=toilet (sin la "s" final) y me di una vuelta por 
el globo a corregir unos cuantos.


Ah! iD también te sugiere automáticamente el cambio de etiquetado.

¿Cómo se ha realizado en ocasiones anteriores?

Ya diréis.

Un saludo

Miguel

On 28/08/2019 22:27, Jorge Sanz Sanfructuoso wrote:

Buenas

Estoy de acuerdo en todo lo que dices y dispuesto ayudar. Creo que se 
debería tratar por esta lista de correo las tareas de qué se quiere 
hacer y como para poder aprobarlos. Y dejarlo documentado en la wiki.


La pagina de la wiki de Deprecated_features no la conocía. Es un buen 
punto de partida. Estado mirando unas cuantas y he corregido alguna 
suelta que había en España comprobándola a mano. Se puede coger el 
listado y mirar cuales es posible hacer de manera automatizada, que no 
todas se puede. Y mirar cuales compensa porque si son pocos se tardara 
menos a mano, pero ya que se comprueba arreglarlo a mano. Es un 
listado muy grande así que podemos repartirlo y comprobar qué es útil 
y descartar lo que no, y posteriormente tratar ya la edición masiva.


Algunos de los etiquetados obsoletos el propio validador de JOSM te 
sugiere el cambio al etiquetado actualizado a un solo click y osmose 
también aunque suele ser más rápido con JOSM.


Osmose como suele pasar en tema de correcciones es una herramienta 
indispensable. Hay algunas cosas que osmose solo comprueba en algunos 
países y se puede mirar ampliarlo a España. Pasaba con la comprobación 
de los números de teléfono. Se puede mirar con qué cosas más pasa y 
mirar adaptarlo también a España como se hizo con los números de teléfono.


Yo esta semana y la próxima ando bastante liado, aunque algo puedo 
hacer, pero ya la siguiente puedo dedicarle más tiempo a esto.


Saludos.



El mié., 28 ago. 2019 a las 20:28, Carlos Antonio Rivera 
(mailto:carlos.kapa...@gmail.com>>) escribió:


Hola a todos,
quiero tratar el tema de las ediciones masivas a nivel de España.

He comprobado que hay gran cantidad de etiquetas obsoletas,
inútiles, con errores de escritura y otros problemas que no serían
difíciles de corregir si se hicieran masivamente.
Creo que hay mucho trabajo que se está quedando perdido en el mapa
al estar con errores, y muchos programas no los interpretarán
correctamente.
Esto ayudaría a evitar que los errores se reproduzcan al copiarse
y que la gente novata sobre todo no se líe.

Para esto de las ediciones automatizadas entiendo que debe haber
acuerdos para evitar problemas mayores y tener que revertir
grandes conjuntos de cambios, tal y como se indica en la página

https://wiki.openstreetmap.org/wiki/ES:Código_de_conducta_de_ediciones_automatizadas
Me gustaría saber de qué manera podríamos tratar esto y si hay
gente que se anime a colaborar.
Supongo que lo suyo es hacer tareas o listados con las ediciones,
aprobarlas y que se asignen a usuarios.

En la página
https://wiki.openstreetmap.org/wiki/Deprecated_features se puede
ver un listado de elementos obsoletos, que podríamos ir
comprobando si todavía están en el mapa.
En Osmose se pueden hacer muchos filtros interesantes, como por
ejemplo el de etiquetado desaconsejado
http://osmose.openstreetmap.fr/es/errors/?item=9002=9002001

Aquí un ejemplo de la cantidad de errores de etiquetado
desaconsejado por comunidades:

Sax-spain_andalucia 2994
Sax-spain_aragon 2340
Sax-spain_asturias 264
Sax-spain_canarias 1440
Sax-spain_cantabria 693
Sax-spain_castilla_la_mancha 1211
Sax-spain_castilla_y_leon 1087
Sax-spain_catalunya 1668
Sax-spain_ceuta 3
Sax-spain_comunidad_de_madrid 2051
Sax-spain_comunidad_foral_de_navarra 1247
Sax-spain_comunitat_valenciana 5037
Sax-spain_euskadi 417
Sax-spain_extremadura 515
Sax-spain_galicia 2178
Sax-spain_illes_balears 1545
Sax-spain_la_rioja 68
Sax-spain_melilla 0
Sax-spain_region_de_murcia 991

Me pareció muy bien lo que se hizo hace poco eliminando las
etiquetas /is_in/. Creo que esto simplificó ciertas cosas y
posiblemente haya corregido problemas. De hecho en Nominatim yo
creo que se corrigieron algunos problemas en mi provincia.
He visto también otras ediciones interesantes como las de
corrección de números de teléfonos o armonización de nombres.
Espero que se pueda hacer 

[Talk-de] Karte mit shop=yes Orten

[Hauke Stieler]

Moin,

da ja ab jetzt Orte mit "shop=yes" im Carto-Style nicht mehr gerendert
werden, habe ich mir mal angeschaut welche das sind und eine Karte für
Deutschland erstellt.

https://umap.openstreetmap.fr/en/map/shopyes-in-deutschland_358119

Ich glaube die meisten kann man durchaus genauer mappen als mit
"shop=yes". Wäre ja schade, wenn man Geschäfte auf Grund schwammiger
Tags nicht mehr sieht.

Grüße
Hauke



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-es] Ediciones masivas en España

[Jorge Sanz Sanfructuoso]

Buenas

Estoy de acuerdo en todo lo que dices y dispuesto ayudar. Creo que se
debería tratar por esta lista de correo las tareas de qué se quiere hacer y
como para poder aprobarlos. Y dejarlo documentado en la wiki.

La pagina de la wiki de Deprecated_features no la conocía. Es un buen punto
de partida. Estado mirando unas cuantas y he corregido alguna suelta que
había en España comprobándola a mano. Se puede coger el listado y mirar
cuales es posible hacer de manera automatizada, que no todas se puede. Y
mirar cuales compensa porque si son pocos se tardara menos a mano, pero ya
que se comprueba arreglarlo a mano. Es un listado muy grande así que
podemos repartirlo y comprobar qué es útil y descartar lo que no, y
posteriormente tratar ya la edición masiva.

Algunos de los etiquetados obsoletos el propio validador de JOSM te sugiere
el cambio al etiquetado actualizado a un solo click y osmose también aunque
suele ser más rápido con JOSM.

Osmose como suele pasar en tema de correcciones es una herramienta
indispensable. Hay algunas cosas que osmose solo comprueba en algunos
países y se puede mirar ampliarlo a España. Pasaba con la comprobación de
los números de teléfono. Se puede mirar con qué cosas más pasa y mirar
adaptarlo también a España como se hizo con los números de teléfono.

Yo esta semana y la próxima ando bastante liado, aunque algo puedo hacer,
pero ya la siguiente puedo dedicarle más tiempo a esto.

Saludos.



El mié., 28 ago. 2019 a las 20:28, Carlos Antonio Rivera (<
carlos.kapa...@gmail.com>) escribió:

> Hola a todos,
> quiero tratar el tema de las ediciones masivas a nivel de España.
>
> He comprobado que hay gran cantidad de etiquetas obsoletas, inútiles, con
> errores de escritura y otros problemas que no serían difíciles de corregir
> si se hicieran masivamente.
> Creo que hay mucho trabajo que se está quedando perdido en el mapa al
> estar con errores, y muchos programas no los interpretarán correctamente.
> Esto ayudaría a evitar que los errores se reproduzcan al copiarse y que la
> gente novata sobre todo no se líe.
>
> Para esto de las ediciones automatizadas entiendo que debe haber acuerdos
> para evitar problemas mayores y tener que revertir grandes conjuntos de
> cambios, tal y como se indica en la página
> https://wiki.openstreetmap.org/wiki/ES:Código_de_conducta_de_ediciones_automatizadas
> Me gustaría saber de qué manera podríamos tratar esto y si hay gente que
> se anime a colaborar.
> Supongo que lo suyo es hacer tareas o listados con las ediciones,
> aprobarlas y que se asignen a usuarios.
>
> En la página https://wiki.openstreetmap.org/wiki/Deprecated_features se
> puede ver un listado de elementos obsoletos, que podríamos ir comprobando
> si todavía están en el mapa.
> En Osmose se pueden hacer muchos filtros interesantes, como por ejemplo el
> de etiquetado desaconsejado
> http://osmose.openstreetmap.fr/es/errors/?item=9002=9002001
>
> Aquí un ejemplo de la cantidad de errores de etiquetado desaconsejado por
> comunidades:
>
> Sax-spain_andalucia 2994
> Sax-spain_aragon 2340
> Sax-spain_asturias 264
> Sax-spain_canarias 1440
> Sax-spain_cantabria 693
> Sax-spain_castilla_la_mancha 1211
> Sax-spain_castilla_y_leon 1087
> Sax-spain_catalunya 1668
> Sax-spain_ceuta 3
> Sax-spain_comunidad_de_madrid 2051
> Sax-spain_comunidad_foral_de_navarra 1247
> Sax-spain_comunitat_valenciana 5037
> Sax-spain_euskadi 417
> Sax-spain_extremadura 515
> Sax-spain_galicia 2178
> Sax-spain_illes_balears 1545
> Sax-spain_la_rioja 68
> Sax-spain_melilla 0
> Sax-spain_region_de_murcia 991
>
> Me pareció muy bien lo que se hizo hace poco eliminando las etiquetas
> *is_in*. Creo que esto simplificó ciertas cosas y posiblemente haya
> corregido problemas. De hecho en Nominatim yo creo que se corrigieron
> algunos problemas en mi provincia.
> He visto también otras ediciones interesantes como las de corrección de
> números de teléfonos o armonización de nombres.
> Espero que se pueda hacer mucho más y poder contribuir a ello sin generar
> problemas, que es lo último que queremos.
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanzs.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-dk] Redningsskilte?

[Niels Elgaard Larsen]

Ja, det var da en god ide.


==
Ved brug af data fra Redningsnummer.dk accepterer du at opdatere data
jævnligt og dermed holde de data du viser omverdenen ajour.
==

Hvad betyder det for os?
Betyder det at den person, der begynder at importere data til OSM lover
at blive med at gøre det?

Og hvad hvis personen ikke gør det?
OSM kan ikke være forpligtiget til at slette det hele igen.

I øvrigt et fjollet krav. For de finder vel ikke på at flytte samme
nummer fra een strand til en anden. Og der er ikke noget der forhindrer
os I at putte en håndfuld redningsnumre i OSM baseret på fx Mapillary.  

==
Seneste opdateringsdato eller udtræksdato skal angives i brugerflade,
hvis datasættet trækkes hjem i eget it-system og anvendes eksempelvis
til at lave offline løsninger.
==

Vi eller OSM kan ikke forpligte brugerfladesystemer til den slags.
Men man kan vel sige at selvom selvom redningsnumre kommer i OSM laver
vi ikke en decideret offline løsning. Og der vil altid være en
opdateringsdato i OSM.

Men man kunne jo forestille sig at nogen fx lavede en app, der brugte
redningsnumre fra hele verden baseret på OSM og ikke mente de skulle
vise opdateringsdatoer i brugerfladen eller ikke kendte til
redningsnummer.dk's regler.

Jeg spiller bare djævelens advokat her. Jeg synes at det er en god ide.
Men måske skulle vi for en sikkerheds skyld spørge dem om det ville være
et problem.


Anders Hedelund:
> Er der nogen, der har overvejet at inkludere redningsskilte i OSM?
> 
> Det er de grønne, nummerede skilte, der står på strandene langs vore
> kyster: http://www.redningsnummer.dk
> 
> Under "download" står der vilkår for anvendelsen, samt div. filer klar
> til brug.
> 
> Billedresultat for redningsnumre
> 
> 
> -- 
> Med venlig Hilsen Anders Hedelund - and...@xoz.dk  +45 3990 5335 Mob: +45 
> 6150 5335 TR: +90 531 831 0220
> Et liv efter overlevelsen: http://iug.dk 
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
> 

-- 
Niels Elgaard Larsen

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[Talk-es] Ediciones masivas en España

[Carlos Antonio Rivera]

Hola a todos,
quiero tratar el tema de las ediciones masivas a nivel de España.

He comprobado que hay gran cantidad de etiquetas obsoletas, inútiles, con
errores de escritura y otros problemas que no serían difíciles de corregir
si se hicieran masivamente.
Creo que hay mucho trabajo que se está quedando perdido en el mapa al estar
con errores, y muchos programas no los interpretarán correctamente.
Esto ayudaría a evitar que los errores se reproduzcan al copiarse y que la
gente novata sobre todo no se líe.

Para esto de las ediciones automatizadas entiendo que debe haber acuerdos
para evitar problemas mayores y tener que revertir grandes conjuntos de
cambios, tal y como se indica en la página
https://wiki.openstreetmap.org/wiki/ES:Código_de_conducta_de_ediciones_automatizadas
Me gustaría saber de qué manera podríamos tratar esto y si hay gente que se
anime a colaborar.
Supongo que lo suyo es hacer tareas o listados con las ediciones,
aprobarlas y que se asignen a usuarios.

En la página https://wiki.openstreetmap.org/wiki/Deprecated_features se
puede ver un listado de elementos obsoletos, que podríamos ir comprobando
si todavía están en el mapa.
En Osmose se pueden hacer muchos filtros interesantes, como por ejemplo el
de etiquetado desaconsejado
http://osmose.openstreetmap.fr/es/errors/?item=9002=9002001

Aquí un ejemplo de la cantidad de errores de etiquetado desaconsejado por
comunidades:

Sax-spain_andalucia 2994
Sax-spain_aragon 2340
Sax-spain_asturias 264
Sax-spain_canarias 1440
Sax-spain_cantabria 693
Sax-spain_castilla_la_mancha 1211
Sax-spain_castilla_y_leon 1087
Sax-spain_catalunya 1668
Sax-spain_ceuta 3
Sax-spain_comunidad_de_madrid 2051
Sax-spain_comunidad_foral_de_navarra 1247
Sax-spain_comunitat_valenciana 5037
Sax-spain_euskadi 417
Sax-spain_extremadura 515
Sax-spain_galicia 2178
Sax-spain_illes_balears 1545
Sax-spain_la_rioja 68
Sax-spain_melilla 0
Sax-spain_region_de_murcia 991

Me pareció muy bien lo que se hizo hace poco eliminando las etiquetas
*is_in*. Creo que esto simplificó ciertas cosas y posiblemente haya
corregido problemas. De hecho en Nominatim yo creo que se corrigieron
algunos problemas en mi provincia.
He visto también otras ediciones interesantes como las de corrección de
números de teléfonos o armonización de nombres.
Espero que se pueda hacer mucho más y poder contribuir a ello sin generar
problemas, que es lo último que queremos.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-talk-fr] Removing "WikiProject" prefix

[dcapillae]

Bonjour.

Je ne parle pas français. Pardonnez-moi si je vous écris en anglais.


[En anglais]

Hi,

I am Daniel, from Spain. I would like to change the name of the wiki 
pages related to the France mapping project to remove the "Wikiproject" 
prefix according to the pages name conventions [1].


The name of the pages related to the France mapping project would be 
"France" (name of place) instead of "Wikiproject France", as recommended 
by the wiki conventions. It is a change that I have already made in 
United States [2], Canada [3], Spain [4], Australia [5], New Zealand 
[6], South Africa [7], and all Spanish-speaking countries [8] on the 
Wiki. The pages of Israel, Denmark, Norway, United Kingdom, Italy, 
Germany, India, Russia and Philippines have also been renamed.


All pages with "WikiProject" prefix will be redirected automatically. 
There will be no broken links in any case.  I'll make sure everything 
works correctly, just like now.


Do you like the idea? I have posted this message on the wiki in case you 
prefer to comment there [10].


Thank you for you attention! Greetings from Spain.

Regards,
Daniel

[1] 
https://wiki.openstreetmap.org/wiki/Wiki_organisation#Pages_naming_convention

[2] https://wiki.openstreetmap.org/wiki/United_States
[3] https://wiki.openstreetmap.org/wiki/Canada
[4] https://wiki.openstreetmap.org/wiki/ES:Spain
[5] https://wiki.openstreetmap.org/wiki/Australia
[6] https://wiki.openstreetmap.org/wiki/New_Zealand
[7] https://wiki.openstreetmap.org/wiki/South_Africa
[8] https://wiki.openstreetmap.org/wiki/Category:Spanish_speaking_countries
[9] https://wiki.openstreetmap.org/wiki/Template:Country
[10] 
https://wiki.openstreetmap.org/wiki/FR_talk:WikiProject_France#Removing_.22WikiProject.22_prefix 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Comparing INSPIRE and OpenStreetMap data conference paper

[Simon Poole]

Got to the 1st line of 2nd page and found the 1st error (as papers on OSM go 
that is not bad).

Am 28. August 2019 15:05:09 MESZ schrieb "François Lacombe" 
:
>Hi all,
>
>Noticed this content today, I don't think this has already been posted
>here. If not, sorry for noise.
>
>People of JRC (Joint Research Center) from European Commission released
>a
>research paper about conflating the two approaches of INSPIRE (European
>public data) and OSM.
>https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XLII-4-W14/167/2019/
>
>It gives many insights of usability and accessibility of data in the
>two
>worlds from user perspective which is really interesting - for instance
>-
>to drive change and improvement policies.
>I don't made any conclusion from it for now, it may be interesting to
>discuss about that.
>
>A talk about it will be given tomorrow at FOSS4G conference.
>https://twitter.com/MarcoMinghini/status/1166255122827157504?s=20
>
>All the best
>
>François

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-dk] Redningsskilte?

[Anders Hedelund]

Er der nogen, der har overvejet at inkludere redningsskilte i OSM?

Det er de grønne, nummerede skilte, der står på strandene langs vore 
kyster: http://www.redningsnummer.dk


Under "download" står der vilkår for anvendelsen, samt div. filer klar 
til brug.


Billedresultat for redningsnumre


--
Med venlig Hilsen Anders Hedelund - and...@xoz.dk  +45 3990 5335 Mob: +45 6150 
5335 TR: +90 531 831 0220
Et liv efter overlevelsen: http://iug.dk

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSM-talk] OpenTrailView - updates

[Nick Whitelegg]

Hello Stefan,


Have increased limit to 15 MB now - let me know if you still have problems. 
Still not mobile friendly just yet - will do this when I have the time.


Thanks,

Nick


From: Stefan Baebler 
Sent: 25 August 2019 22:33:38
To: Nick Whitelegg 
Cc: Simon Polster ; osm-talk 
Subject: Re: [OSM-talk] OpenTrailView - updates

Hi!

I have problems uploading full 360°*180° photospheres. All of them are around 
10MB, and could not find any below 5MB to test with. The error does not say 
much - no photo uploaded and no error code.

The size limit should be raised (eg to 15MB) in my opinion as there is no easy 
option to compress such images (eg by lowering the resolution).

Also the website is really hard to use on mobile devices. :-(

Br,
Stefan




V pet., 16. avg. 2019 19:05 je oseba Nick Whitelegg 
mailto:nick.whitel...@solent.ac.uk>> napisala:


Hello Simon,


Glad it's working for you!


It looks like it should be possible to show the view field on the map - a 
Leaflet plugin exists to draw semicircles for example, so I'll have a look into 
that - shouldn't be too difficult to implement.


Thanks,

Nick


From: Simon Polster mailto:sid...@posteo.de>>
Sent: 15 August 2019 18:17:46
To: talk@openstreetmap.org 
mailto:talk@openstreetmap.org>>
Subject: Re: [OSM-talk] OpenTrailView - updates

Looks very nice and works very smoothly for me, thank you!

One functionality I think would be useful for orientation: somehow make
the current viewfield of the panorama visible in the little overview map
(or if that's too difficult to implement at least link the rotation of
the panorama with the overview map so that they always share the same
geographic direction).

Cheers
Simon

Am 06/08/2019 um 16:58 schrieb Nick Whitelegg:
>
> Hi,
>
>
> To follow up my post of a couple of months ago, I have made a few updates to 
> OpenTrailView, a StreetView-like application which allows users to upload 360 
> panoramas which will then be automatically linked using underlying OSM ways, 
> allowing users to navigate from panorama to panorama.
>
>
> It now allows you to login with your OSM credentials, removing the need to 
> create a separate account - in fact I have removed the signup facility so if 
> you signed up before, you should now login using your OSM username instead.
>
>
> It also has a facility to allow you to set the position of a panorama if EXIF 
> latitude and longitude metadata is not present. This can be done either by 
> clicking on the map to position the panorama, or by using a GPX file recorded 
> at the same time to position panoramas automatically by using EXIF and GPX 
> timestamps.
>
>
> URL: https://www.opentrailview.org/
>
>
> 
>
> Gitlab repo: https://gitlab.com/nickw1/opentrailview/
>
>
> Nick
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

[OSM-talk-ie] OSM Awards 2019

[Tadeusz Cantwell]

I am happy to announce that Brian Hollinshead has been shortlisted for the
OSM 2019 award for the Expanding the community award. Vote early and
often!!!
http://awards.osmz.ru/list
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] tag pizza forno a legna

[Francesco Ansanelli]

Il mer 28 ago 2019, 12:41 Martin Koppenhoefer  ha
scritto:

> ho aggiunto oven=gas_fired, speriamo che vada bene ;-)
>
Ottimo!
Grazie

>
> Cheers,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-GB] Wales Coast Path almost finished

[Richard Fairhurst]

I was in holiday in North Wales last week and mapped the biggest 
remaining gap, east from Aberdaron:


https://hiking.waymarkedtrails.org/#?map=13!52.8079!-4.6498

That leaves three smaller gaps around the central Cardigan Bay 
coastline, between Barmouth and Borth:


https://hiking.waymarkedtrails.org/#?map=15!52.6483!-4.0907
https://hiking.waymarkedtrails.org/#?map=14!52.4981!-4.0189
https://hiking.waymarkedtrails.org/#?map=15!52.5799!-3.9411

plus one short one in South Wales near Gowerton:

https://hiking.waymarkedtrails.org/#?map=15!51.6472!-4.0787

Fixing these will mean not only that the WCP is complete in OSM, but 
also, as far as I can tell, that we have full coverage of National 
Trails in England & Wales. So if anyone's going on holiday to West 
Wales, or the Gower, please do map the missing bits and we'll be complete.


cheers
Richard

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-is] Nýjar Mapillary myndir / New Mapillary images

[Svavar Kjarrval]

Góðan dag. [English below]

Nú eru komnar á Mapillary hellingur af nýjum myndum víðs vegar um 
Ísland. Ég hvet ykkur til að nota þær til að leysa OSM athugasemdir og 
önnur vafamál sem kunna að hafa risið, ásamt því að setja inn eða 
staðfesta ýmsar aðrar upplýsingar gagnlegar fyrir OSM.


Með kveðju,
Svavar Kjarrval

English version:
A lot of new Mapillary images are now available for areas in Iceland. I 
encourage you all to use them to solve OSM notes and other issues which 
might have been raised, along with submitting  or confirming other 
information which might benefit OSM.


___
Talk-is mailing list
Talk-is@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-is

Re: [OSM-talk-fr] parking et parking_space

[Christian Quest]

A mon sens, un parking et une place de stationnement réservé sont deux
choses différentes.

Un parking (amenity=parking), c'est un ensemble de places de stationnement,
dans un espace dédié à ça souvent avec une voie dédiée pour y circuler.
Les places de stationnement le long des rues ne sont pas des parkings.

Une place de stationnement réservée (amenity=parking_space) peut être dans
un parking, le long d'une voie de circulation seule ou parmis les autres
places de stationnement.

Pour le stationnement le long des voies de circulation, indiquer
globalement les règles de stationnement est possible, sans aller jusqu'à
détailler les places une à une (sauf pour ceux atteint d'un TOC de
micromapping, aussi appelé "zimmite").

La relation, franchement je ne vois pas du tout son intérêt. Si on ne
renseigne que des parking_space dans un parking sans un indiquer qu'il y a
un parking, je pense qu'on micro-mappe avant de mapper ce que je trouve
ridicule et complique sans intérêt la réutilisation des données.

Le mar. 27 août 2019 à 19:46,  a écrit :

> Le 27/08/2019 à 17:51, marc marc - marc_marc_...@hotmail.com a écrit :
>
> ce sont 2 choses différentes :un parking d'une ou plusieurs places <>
> une/des places dans un parking de plusieurs places).
>
> Ce qui tu dis est plein de bon sens sauf que ça ne correspond pas à la
> définition donnée sur la page amenity.
>
> Là on te dit que soit tu fais une relation avec tous les emplacements
> individuels (parking_space) soit tu fais un polygone global (parking).
>
> D'où ma question.
> Le 27/08/2019 à 17:41, Florimond Berthoux - florimond.berth...@gmail.com
> a écrit :
>
> Problème technique : si je veux connaitre la place handicapée la plus
> proche il me faut vérifier deux tags alors qu'ils représentent le même
> objet physique
>
> Tu fais l'hypothèse qu'il n'y a pas de vicieux à avoir découpé les voies
> en segments d'une place pour indiquer
>
> parking:lane:both, parking:lane:left, parking:lane:right.
>
> Heureusement il n'est pas prévu d'indiquer parking:lane:*:disabled=yes ;-).
>
> Jean-Yvon
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sotm Heidelberg : on y va ensemble ?

[Christine Karch]

Bonjour,

un petit indication pour SotM à Heidelberg: la conférence est presque
complète ...

Á bientôt

Christine

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Historic 66 as highway=trunk in OK

[Kevin Kenny]

On Wed, Aug 28, 2019 at 8:09 AM stevea  wrote:
> The topic begs the question as to what such (usually very) old, 
> poor-condition (where they ARE poor) roads should be tagged (we limit 
> ourselves to US roads here because this is talk-us), and at what granularity. 
>  (Volker COULD do detailed tagging, but I hear loud and clear he prefers 
> high-granularity tagging, as do I, though we all recognize how tedious this 
> can be).  And "old 66" is a quintessential example, many segments are a 
> century old or older:  it is known as "the Mother road" by many.  BTW, many 
> public agencies under the umbrella of Southern California Association of 
> Governments are working on developing USBR 66 in California for cyclists (the 
> route number choice is no coincidence as some alignments follow the old 
> Mother road).  This was actually in OSM as an early proposed route, but was 
> removed to conform to USBRS proposed route conventions.  If/as USBR 66 turns 
> into a Caltrans (DOT) route proposal to AASHTO, OSM will re-enter these data. 
>  It makes sense to pay close attention to the underlying infrastructure 
> tagging (tertiary, surface, smoothness...) as we do so since these are 
> important to cyclists.

It really depends on what we're talking about here. Are we talking
about the places that are bannered with the 'Historic US 66' sign
(with the appearance of a US Highway banner from the 1930s), roads
named 'Old US 66', or the actual ways comprising the historic route of
the road.

'Historic US 66' is a bannered and numbered route because of its
history, not because of its current importance to the road system. The
constituent ways should be tagged as whatever they are currently in
the road network. In many places, 'Historic US 66' no longer follows
the historic route of the road because the road is no longer passable
or no longer has good connections to the highway network. For example,
from Flagstaff, Arizona to the New Mexico state line (except for brief
detours through Winslow and Holbrook) the bannered 'Historic Route 66'
is highway=motorway because the construction of I-40 obliterated or
disconnected the old route.  (I don't know whether I-40 actually bears
the signage anywhere.)

There are places where the old road exists on the ground and bears the
name, but are not bannered because a road fails to connect or is no
longer reliably passable to low-clearance automobiles. The route can
be followed for some distance east and west of Exit 303, for instance.
It's at most an 'unclassified' road and connects mostly to tracks. At
the east end of that run, there's no crossing of I-40, and the road
simply turns right onto another track. On the other side of the
freeway, the pavement resumes, but in Petrified Forest it's
unmaintained and has deteriorated to where it is neither safe nor
lawful to drive. East of there, it's a track at best, and again ends
at a freeway crossing without an interchange.  On the far side, it's a
minor rural road (County Road 7385)
https://www.openstreetmap.org/way/16792461, then crosses the freeway
at McCarrell and becomes the freeway frontage road in Chambers. If
memory serves, some of the tracks that remain in use are no longer
public rights-of-way, and neither the ranchers nor the Navajo Nation
welcome visitors on them.

In western Arizona, from Kingman to Seligman, the historic way is in
service, is bannered 'AZ 66' and is at least 'secondary'.  East of
Seligman, it exists as Crookson Road and 'Old US 66, but diminishes to
a track and disappears at a corner where it crosses neither I-40 nor
the Phoenix spur of the Santa Fe. Between there are Flagstaff, there
are fragmentary tracks, and some, such as
https://www.openstreetmap.org/way/16792461 are entirely isolated from
the road network. West of Kingman, it's County Road 10, and at least
it used to be challenging to drive because it was a narrow and badly
deteriorated road in mountainous terrain. The only community on the
route is Oatman, which has enjoyed something of a resurgence as a
tourist destination, "come see the ghost town where wild burros roam
the streets." I'd say it's probably 'tertiary' because in that desert,
it doesn't take much to make a road important.

For the whole route, I'd say, 'tag the constituent ways as what they
are, and maintain the 'Historic US 66' relation only where the
historic route is marked, or at least named.'  The 'Old US 66' concept
is best left for OHM.

> Are there any fresh, eager readers of this list who wish to delve into a 
> fairly tedious sub-project in OSM:  tagging "their" portion of 66 (and its 
> many remnants, bypasses, used-to-be-segments...) that they know?  The right 
> classifications (as they render) and surface=* and smoothness=* tagging 
> (though, they do not render) would be very welcome ongoing improvements to 
> our fine project.  It could be a state-at-a-time effort to drum up OSM 
> community, it could become a "WikiProject" (though that concept seems to have 
> 

Re: [OSM-talk] OpenStreetMap Carto release v4.22.0

[Mateusz Konieczny]

28 Aug 2019, 08:13 by oleksiy.muzal...@bluewin.ch:

> I did not understand these two changes. I would like to see an example on the 
> map or/and read a wiki article about the building label, the shop label, and 
> the ST_PointOnSurface.
>
> In the two following articles:
>
> https://wiki.openstreetmap.org/wiki/Key:shop
> https://wiki.openstreetmap.org/wiki/Shops
> https://wiki.openstreetmap.org/wiki/Key:building
>
> there is neither word "label", nor "ST_PointOnSurface". I would like to learn 
> about it and, probably, use it.
>
In this case "label" means "displayed name".

In general, in case of map styles it is useful to search also at the 
development site.

For this style it is https://github.com/gravitystorm/openstreetmap-carto 


See 
https://github.com/gravitystorm/openstreetmap-carto/search?o=desc=ST_PointOnSurface=updated=Issues
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Comparing INSPIRE and OpenStreetMap data conference paper

[François Lacombe]

Hi all,

Noticed this content today, I don't think this has already been posted
here. If not, sorry for noise.

People of JRC (Joint Research Center) from European Commission released a
research paper about conflating the two approaches of INSPIRE (European
public data) and OSM.
https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XLII-4-W14/167/2019/

It gives many insights of usability and accessibility of data in the two
worlds from user perspective which is really interesting - for instance -
to drive change and improvement policies.
I don't made any conclusion from it for now, it may be interesting to
discuss about that.

A talk about it will be given tomorrow at FOSS4G conference.
https://twitter.com/MarcoMinghini/status/1166255122827157504?s=20

All the best

François
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Edson Nicolai via Talk-ZA]

Hi Bernelle,

I‘ve added my name to the list. I’ll be checking back to see if there’s any 
update.

Cheers.

Ed Nicolai

Music Video/TV Ad Director - Motion Graphics

Namibia: +264 81 43 31 374
Angola: +244 945 75 23 11
Zambia: +260 967617783

eddynico...@me.com - eddynico...@gmail.com [for emergencies only]

> On 28 Aug 2019, at 1:36 PM, Bernelle Verster  wrote:
> 
> Hi Edson
> 
> Replying to all for interest:
> 
> Team:
> I need team members listed on the page to show strength of numbers,
> basically. So, for starters, please add your name (thanks Geoffrey!).
> Also, please share this bid to your networks!
> 
> Insider knowledge:
> I don't know the OSM community nor do I know the SotM format. I have
> organised the Debian Conference in Cape Town before (DebConf16), which
> I think is a similar culture.
> 
> Format:
> My interest in getting involved, and also my concern that I may
> 'corrupt' the format, is that I am interested in using OSM in games,
> urban metabolism visualisations and information design, and organising
> a conference is a great way to learn and connect. I would like the
> conference to have tracks addressing these things, which hopefully
> would also incentivise creatives and people who otherwise may not be
> interested in OSS mapping stuff to attend - bringing new blood and
> pretty things. I need help to keep the conference true to the SotM
> format.
> 
> Remote participation:
> For accessibility, but also for the increasing concern about
> (long-haul) flights and climate change, I would like a greater
> emphasis on remote participation. Ideally, an avatar in a virtual
> world :) Like, SimCity for OSM! (not that far fetched, but probably a
> lot of work) Ideas needed on how to improve accessibility here.
> 
> Location:
> My current favourite is the University of Cape Town Rondebosch campus,
> as I know how things work there and we have a staff member on the team
> (DebConf16 was held there). I still need a letter of support from a
> relevant department/faculty to give us a venue discount. Does this
> suit people in terms of access, transport, whatever? Other ideas? If
> anyone wants to help with catering or venue quotes, also get in touch
> please. Feel free to add known costs to the wiki as an indication to
> the bid committee, see Heidelberg (this year's SotM) bid as example:
> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2019/Call_for_venues/Heidelberg
> 
> regards
> B
> 
>> On Wed, Aug 28, 2019 at 2:06 PM Edson Nicolai via Talk-ZA
>>  wrote:
>> 
>> Hi Bernelle,
>> 
>> I’m based in Luanda, and couldn’t attend previous conferences, but looking 
>> at the possible dates on the page, I might attend this one.
>> 
>> Let me know what info you might need from me and how I can help at all.
>> 
>> 
>> Ed Nicolai
>> 
>> Music Video/TV Ad Director - Motion Graphics
>> 
>> Namibia: +264 81 43 31 374
>> Angola: +244 945 75 23 11
>> Zambia: +260 967617783
>> 
>> eddynico...@me.com - eddynico...@gmail.com [for emergencies only]
>> 
 On 28 Aug 2019, at 12:59 PM, Bernelle Verster  wrote:
>>> 
>>> Hi
>>> 
>>> I submitted a bid to host the 2020 State of the Map conference in Cape
>>> Town, South Africa [1].
>>> 
>>> The deadline for this bid is Saturday 31 August 2019. At the moment we
>>> have a very small team, and no interest from the OSM community in
>>> South Africa. I am willing to lead the bid but will have to withdraw
>>> if there is not sufficient interest to help organise it.
>>> 
>>> Please add your names and give indications of suitable
>>> venues/locations and catering options if you have opinions on this.
>>> 
>>> regards
>>> Bernelle (indiebio)
>>> 
>>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
>>> 
 On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  
 wrote:
 
 Hi
 
 There is now a bid for Cape Town. I don't have a team yet, so this
 group posting is to call any interested peoples to add their name and
 share ideas for what they'd like to see.
 
 https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
 
 You can find me through email or IRC (indiebio).
 
 regards
 Bernelle
 
> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
> wrote:
> 
> FYI
> 
> -- Forwarded message -
> De : Christine Karch 
> Date: mar. 18 juin 2019 à 23:59
> Subject: [Osmf-talk] SotM 2020
> To: , Talk Openstreetmap 
> 
> 
> 
> Hello OSM community,
> 
> at the moment we have no venue for SotM 2020. There are no candidates
> even yet. Hello world! Is there any OSM community who would like to host
> SotM spontaneous? We extend the call for bids until end of August. We
> would like to present the SotM 2020 in Heidelberg during SotM 2019.
> 
> Please use our wiki form for the formal part of your bid [1]. But don't
> hesitate to ask questions to the SotM working 

Re: [Talk-africa] [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Edson Nicolai via Talk-africa]

Hi Bernelle,

I’m based in Luanda, and couldn’t attend previous conferences, but looking at 
the possible dates on the page, I might attend this one. 

Let me know what info you might need from me and how I can help at all.


Ed Nicolai

Music Video/TV Ad Director - Motion Graphics

Namibia: +264 81 43 31 374
Angola: +244 945 75 23 11
Zambia: +260 967617783

eddynico...@me.com - eddynico...@gmail.com [for emergencies only]

> On 28 Aug 2019, at 12:59 PM, Bernelle Verster  wrote:
> 
> Hi
> 
> I submitted a bid to host the 2020 State of the Map conference in Cape
> Town, South Africa [1].
> 
> The deadline for this bid is Saturday 31 August 2019. At the moment we
> have a very small team, and no interest from the OSM community in
> South Africa. I am willing to lead the bid but will have to withdraw
> if there is not sufficient interest to help organise it.
> 
> Please add your names and give indications of suitable
> venues/locations and catering options if you have opinions on this.
> 
> regards
> Bernelle (indiebio)
> 
> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
> 
>> On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  
>> wrote:
>> 
>> Hi
>> 
>> There is now a bid for Cape Town. I don't have a team yet, so this
>> group posting is to call any interested peoples to add their name and
>> share ideas for what they'd like to see.
>> 
>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
>> 
>> You can find me through email or IRC (indiebio).
>> 
>> regards
>> Bernelle
>> 
>>> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
>>> wrote:
>>> 
>>> FYI
>>> 
>>> -- Forwarded message -
>>> De : Christine Karch 
>>> Date: mar. 18 juin 2019 à 23:59
>>> Subject: [Osmf-talk] SotM 2020
>>> To: , Talk Openstreetmap 
>>> 
>>> 
>>> 
>>> Hello OSM community,
>>> 
>>> at the moment we have no venue for SotM 2020. There are no candidates
>>> even yet. Hello world! Is there any OSM community who would like to host
>>> SotM spontaneous? We extend the call for bids until end of August. We
>>> would like to present the SotM 2020 in Heidelberg during SotM 2019.
>>> 
>>> Please use our wiki form for the formal part of your bid [1]. But don't
>>> hesitate to ask questions to the SotM working group via email.
>>> 
>>> Did you ever consider to provide the unconference format? This could be
>>> an amazing change to what we are used. Or should we just meet for a
>>> barbecue? :)
>>> 
>>> Or how about an upgrade of your local conference to a global?
>>> 
>>> Cheers,
>>> 
>>> Christine
>>> 
>>> 
>>> 
>>> 
>>> [1]
>>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
>>> 
>>> ___
>>> osmf-talk mailing list
>>> osmf-t...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>> 
>>> 
>>> --
>>> Best,
>>> -Enock
>>> ___
>>> Talk-ZA mailing list
>>> talk...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-za
> 
> ___
> Talk-ZA mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za


___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-africa] [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Bernelle Verster]

Hi Edson

Replying to all for interest:

Team:
I need team members listed on the page to show strength of numbers,
basically. So, for starters, please add your name (thanks Geoffrey!).
Also, please share this bid to your networks!

Insider knowledge:
I don't know the OSM community nor do I know the SotM format. I have
organised the Debian Conference in Cape Town before (DebConf16), which
I think is a similar culture.

Format:
My interest in getting involved, and also my concern that I may
'corrupt' the format, is that I am interested in using OSM in games,
urban metabolism visualisations and information design, and organising
a conference is a great way to learn and connect. I would like the
conference to have tracks addressing these things, which hopefully
would also incentivise creatives and people who otherwise may not be
interested in OSS mapping stuff to attend - bringing new blood and
pretty things. I need help to keep the conference true to the SotM
format.

Remote participation:
For accessibility, but also for the increasing concern about
(long-haul) flights and climate change, I would like a greater
emphasis on remote participation. Ideally, an avatar in a virtual
world :) Like, SimCity for OSM! (not that far fetched, but probably a
lot of work) Ideas needed on how to improve accessibility here.

Location:
My current favourite is the University of Cape Town Rondebosch campus,
as I know how things work there and we have a staff member on the team
(DebConf16 was held there). I still need a letter of support from a
relevant department/faculty to give us a venue discount. Does this
suit people in terms of access, transport, whatever? Other ideas? If
anyone wants to help with catering or venue quotes, also get in touch
please. Feel free to add known costs to the wiki as an indication to
the bid committee, see Heidelberg (this year's SotM) bid as example:
https://wiki.openstreetmap.org/wiki/State_of_the_Map_2019/Call_for_venues/Heidelberg

regards
B

On Wed, Aug 28, 2019 at 2:06 PM Edson Nicolai via Talk-ZA
 wrote:
>
> Hi Bernelle,
>
> I’m based in Luanda, and couldn’t attend previous conferences, but looking at 
> the possible dates on the page, I might attend this one.
>
> Let me know what info you might need from me and how I can help at all.
>
>
> Ed Nicolai
>
> Music Video/TV Ad Director - Motion Graphics
>
> Namibia: +264 81 43 31 374
> Angola: +244 945 75 23 11
> Zambia: +260 967617783
>
> eddynico...@me.com - eddynico...@gmail.com [for emergencies only]
>
> > On 28 Aug 2019, at 12:59 PM, Bernelle Verster  wrote:
> >
> > Hi
> >
> > I submitted a bid to host the 2020 State of the Map conference in Cape
> > Town, South Africa [1].
> >
> > The deadline for this bid is Saturday 31 August 2019. At the moment we
> > have a very small team, and no interest from the OSM community in
> > South Africa. I am willing to lead the bid but will have to withdraw
> > if there is not sufficient interest to help organise it.
> >
> > Please add your names and give indications of suitable
> > venues/locations and catering options if you have opinions on this.
> >
> > regards
> > Bernelle (indiebio)
> >
> > https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
> >
> >> On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  
> >> wrote:
> >>
> >> Hi
> >>
> >> There is now a bid for Cape Town. I don't have a team yet, so this
> >> group posting is to call any interested peoples to add their name and
> >> share ideas for what they'd like to see.
> >>
> >> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
> >>
> >> You can find me through email or IRC (indiebio).
> >>
> >> regards
> >> Bernelle
> >>
> >>> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
> >>> wrote:
> >>>
> >>> FYI
> >>>
> >>> -- Forwarded message -
> >>> De : Christine Karch 
> >>> Date: mar. 18 juin 2019 à 23:59
> >>> Subject: [Osmf-talk] SotM 2020
> >>> To: , Talk Openstreetmap 
> >>> 
> >>>
> >>>
> >>> Hello OSM community,
> >>>
> >>> at the moment we have no venue for SotM 2020. There are no candidates
> >>> even yet. Hello world! Is there any OSM community who would like to host
> >>> SotM spontaneous? We extend the call for bids until end of August. We
> >>> would like to present the SotM 2020 in Heidelberg during SotM 2019.
> >>>
> >>> Please use our wiki form for the formal part of your bid [1]. But don't
> >>> hesitate to ask questions to the SotM working group via email.
> >>>
> >>> Did you ever consider to provide the unconference format? This could be
> >>> an amazing change to what we are used. Or should we just meet for a
> >>> barbecue? :)
> >>>
> >>> Or how about an upgrade of your local conference to a global?
> >>>
> >>> Cheers,
> >>>
> >>> Christine
> >>>
> >>>
> >>>
> >>>
> >>> [1]
> >>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
> >>>
> >>> ___
> >>> osmf-talk mailing list
> >>> 

Re: [Talk-africa] [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Bernelle Verster]

Hi

I submitted a bid to host the 2020 State of the Map conference in Cape
Town, South Africa [1].

The deadline for this bid is Saturday 31 August 2019. At the moment we
have a very small team, and no interest from the OSM community in
South Africa. I am willing to lead the bid but will have to withdraw
if there is not sufficient interest to help organise it.

Please add your names and give indications of suitable
venues/locations and catering options if you have opinions on this.

regards
Bernelle (indiebio)

https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown

On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  wrote:
>
> Hi
>
> There is now a bid for Cape Town. I don't have a team yet, so this
> group posting is to call any interested peoples to add their name and
> share ideas for what they'd like to see.
>
> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
>
> You can find me through email or IRC (indiebio).
>
> regards
> Bernelle
>
> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
> wrote:
> >
> > FYI
> >
> > -- Forwarded message -
> > De : Christine Karch 
> > Date: mar. 18 juin 2019 à 23:59
> > Subject: [Osmf-talk] SotM 2020
> > To: , Talk Openstreetmap 
> > 
> >
> >
> > Hello OSM community,
> >
> > at the moment we have no venue for SotM 2020. There are no candidates
> > even yet. Hello world! Is there any OSM community who would like to host
> > SotM spontaneous? We extend the call for bids until end of August. We
> > would like to present the SotM 2020 in Heidelberg during SotM 2019.
> >
> > Please use our wiki form for the formal part of your bid [1]. But don't
> > hesitate to ask questions to the SotM working group via email.
> >
> > Did you ever consider to provide the unconference format? This could be
> > an amazing change to what we are used. Or should we just meet for a
> > barbecue? :)
> >
> > Or how about an upgrade of your local conference to a global?
> >
> > Cheers,
> >
> > Christine
> >
> >
> >
> >
> > [1]
> > https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
> >
> > ___
> > osmf-talk mailing list
> > osmf-t...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >
> >
> > --
> > Best,
> > -Enock
> > ___
> > Talk-ZA mailing list
> > talk...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-za

___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [Talk-us] Historic 66 as highway=trunk in OK

[stevea]

Hi Paul, Hi Volker, Hi talk-us:

The topic begs the question as to what such (usually very) old, poor-condition 
(where they ARE poor) roads should be tagged (we limit ourselves to US roads 
here because this is talk-us), and at what granularity.  (Volker COULD do 
detailed tagging, but I hear loud and clear he prefers high-granularity 
tagging, as do I, though we all recognize how tedious this can be).  And "old 
66" is a quintessential example, many segments are a century old or older:  it 
is known as "the Mother road" by many.  BTW, many public agencies under the 
umbrella of Southern California Association of Governments are working on 
developing USBR 66 in California for cyclists (the route number choice is no 
coincidence as some alignments follow the old Mother road).  This was actually 
in OSM as an early proposed route, but was removed to conform to USBRS proposed 
route conventions.  If/as USBR 66 turns into a Caltrans (DOT) route proposal to 
AASHTO, OSM will re-enter these data.  It makes sense to pay close attention to 
the underlying infrastructure tagging (tertiary, surface, smoothness...) as we 
do so since these are important to cyclists.

A case can be made for highway=trunk (for connectivity reasons) yet I do 
resonate with "secondary at best" for such old, poor roads.  Tagging 
highway=trunk is about as high a classification as the very best portions of 
this road will ever get, and only on its highest-speed segments which are 
divided.  This implies highway=tertiary (MAYBE secondary) where the road is NOT 
dual carriageway, as highway=trunk in the USA means "with a barrier or median 
separating each direction of traffic" (truly dual carriageway).  Yes, it is 
appropriate to tag highway=secondary on some segments, I believe these to be in 
the minority compared to tertiary (which likely makes up the majority of what 
remains of this route in many states).

I also say including a surface=* tag is important, so is a smoothness=* tag 
(though that has its controversies) where this is known or meets / falls below 
value intermediate (or so).

Let's agree that simply tagging highway=trunk is often incorrect when dual 
carriageways of highway=tertiary with accurate surface=* (and sure, 
smoothness=*) tags would be much more accurate and preferred.

Are there any fresh, eager readers of this list who wish to delve into a fairly 
tedious sub-project in OSM:  tagging "their" portion of 66 (and its many 
remnants, bypasses, used-to-be-segments...) that they know?  The right 
classifications (as they render) and surface=* and smoothness=* tagging 
(though, they do not render) would be very welcome ongoing improvements to our 
fine project.  It could be a state-at-a-time effort to drum up OSM community, 
it could become a "WikiProject" (though that concept seems to have fuzzied as 
of late), it could be a topic at Meetups or Mapping Parties in the appropriate 
geographical venues...it seems like a good fit to build a kernel of effort to 
"get this right."  May we see better 66 tagging going forward!

SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Edson Nicolai via Talk-ZA]

Hi Bernelle,

I’m based in Luanda, and couldn’t attend previous conferences, but looking at 
the possible dates on the page, I might attend this one. 

Let me know what info you might need from me and how I can help at all.


Ed Nicolai

Music Video/TV Ad Director - Motion Graphics

Namibia: +264 81 43 31 374
Angola: +244 945 75 23 11
Zambia: +260 967617783

eddynico...@me.com - eddynico...@gmail.com [for emergencies only]

> On 28 Aug 2019, at 12:59 PM, Bernelle Verster  wrote:
> 
> Hi
> 
> I submitted a bid to host the 2020 State of the Map conference in Cape
> Town, South Africa [1].
> 
> The deadline for this bid is Saturday 31 August 2019. At the moment we
> have a very small team, and no interest from the OSM community in
> South Africa. I am willing to lead the bid but will have to withdraw
> if there is not sufficient interest to help organise it.
> 
> Please add your names and give indications of suitable
> venues/locations and catering options if you have opinions on this.
> 
> regards
> Bernelle (indiebio)
> 
> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
> 
>> On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  
>> wrote:
>> 
>> Hi
>> 
>> There is now a bid for Cape Town. I don't have a team yet, so this
>> group posting is to call any interested peoples to add their name and
>> share ideas for what they'd like to see.
>> 
>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
>> 
>> You can find me through email or IRC (indiebio).
>> 
>> regards
>> Bernelle
>> 
>>> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
>>> wrote:
>>> 
>>> FYI
>>> 
>>> -- Forwarded message -
>>> De : Christine Karch 
>>> Date: mar. 18 juin 2019 à 23:59
>>> Subject: [Osmf-talk] SotM 2020
>>> To: , Talk Openstreetmap 
>>> 
>>> 
>>> 
>>> Hello OSM community,
>>> 
>>> at the moment we have no venue for SotM 2020. There are no candidates
>>> even yet. Hello world! Is there any OSM community who would like to host
>>> SotM spontaneous? We extend the call for bids until end of August. We
>>> would like to present the SotM 2020 in Heidelberg during SotM 2019.
>>> 
>>> Please use our wiki form for the formal part of your bid [1]. But don't
>>> hesitate to ask questions to the SotM working group via email.
>>> 
>>> Did you ever consider to provide the unconference format? This could be
>>> an amazing change to what we are used. Or should we just meet for a
>>> barbecue? :)
>>> 
>>> Or how about an upgrade of your local conference to a global?
>>> 
>>> Cheers,
>>> 
>>> Christine
>>> 
>>> 
>>> 
>>> 
>>> [1]
>>> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
>>> 
>>> ___
>>> osmf-talk mailing list
>>> osmf-t...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osmf-talk
>>> 
>>> 
>>> --
>>> Best,
>>> -Enock
>>> ___
>>> Talk-ZA mailing list
>>> Talk-ZA@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-za
> 
> ___
> Talk-ZA mailing list
> Talk-ZA@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-za


___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

Re: [OSM-Talk-ZA] Fwd: [Osmf-talk] SotM 2020

[Bernelle Verster]

Hi

I submitted a bid to host the 2020 State of the Map conference in Cape
Town, South Africa [1].

The deadline for this bid is Saturday 31 August 2019. At the moment we
have a very small team, and no interest from the OSM community in
South Africa. I am willing to lead the bid but will have to withdraw
if there is not sufficient interest to help organise it.

Please add your names and give indications of suitable
venues/locations and catering options if you have opinions on this.

regards
Bernelle (indiebio)

https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown

On Sun, Aug 11, 2019 at 10:47 AM Bernelle Verster  wrote:
>
> Hi
>
> There is now a bid for Cape Town. I don't have a team yet, so this
> group posting is to call any interested peoples to add their name and
> share ideas for what they'd like to see.
>
> https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues/CapeTown
>
> You can find me through email or IRC (indiebio).
>
> regards
> Bernelle
>
> On Mon, Jul 29, 2019 at 6:56 AM Enock Seth Nyamador  
> wrote:
> >
> > FYI
> >
> > -- Forwarded message -
> > De : Christine Karch 
> > Date: mar. 18 juin 2019 à 23:59
> > Subject: [Osmf-talk] SotM 2020
> > To: , Talk Openstreetmap 
> > 
> >
> >
> > Hello OSM community,
> >
> > at the moment we have no venue for SotM 2020. There are no candidates
> > even yet. Hello world! Is there any OSM community who would like to host
> > SotM spontaneous? We extend the call for bids until end of August. We
> > would like to present the SotM 2020 in Heidelberg during SotM 2019.
> >
> > Please use our wiki form for the formal part of your bid [1]. But don't
> > hesitate to ask questions to the SotM working group via email.
> >
> > Did you ever consider to provide the unconference format? This could be
> > an amazing change to what we are used. Or should we just meet for a
> > barbecue? :)
> >
> > Or how about an upgrade of your local conference to a global?
> >
> > Cheers,
> >
> > Christine
> >
> >
> >
> >
> > [1]
> > https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
> >
> > ___
> > osmf-talk mailing list
> > osmf-t...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >
> >
> > --
> > Best,
> > -Enock
> > ___
> > Talk-ZA mailing list
> > Talk-ZA@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-za

___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

Re: [Talk-it] tag pizza forno a legna

[Martin Koppenhoefer]

ho aggiunto oven=gas_fired, speriamo che vada bene ;-)

Cheers,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Osmose.... tag "postal_code"

[Frédéric Rodrigo]

https://wiki.openstreetmap.org/wiki/Key:postal_code

Le 28/08/2019 à 11:37, Jacques Lavignotte a écrit :

Bonjour,

j'essaye de comprendre Osmose...

Ces erreurs me reviennent, l'une au moins sur un de mes tags mais 
plein d'autres.


Je ne sais pas quoi faire sur :

 admin_level 8 without tag "postal_code"

dans :

relation 140258 analyse1 analyse2 josm iD edit
addr:postcode = 86550
admin_level = 8
boundary = administrative
name = Mignaloux-Beauvoir
ref:INSEE = 86157

source:addr:postcode = source of postcode is from osm nodes

type = boundary
wikidata = Q1436018
wikipedia = fr:Mignaloux-Beauvoir


et plein d'autres...

Merci,

J.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose.... tag "postal_code"

[osm . sanspourriel]

Bonjour,

c'est évident quand tu as compris la subtilité. Le message de Fred est
plus clair maintenant... visiblement pas assez.

Avant tu galères ;-).

Il ne faut pas addr:postcode = 86550 (qui est réservé aux adresses) mais
*postal_code*=86550

Au besoin tu mets aussi source:postal_code en lieu et place de
source:addr:postcode.

Le 28/08/2019 à 11:37, Jacques Lavignotte - jacq...@lavignotte.org a écrit :

Bonjour,

j'essaye de comprendre Osmose...

Ces erreurs me reviennent, l'une au moins sur un de mes tags mais
plein d'autres.

Je ne sais pas quoi faire sur :

 admin_level 8 without tag "postal_code"

dans :

relation 140258 analyse1 analyse2 josm iD edit
addr:postcode = 86550
admin_level = 8
boundary = administrative
name = Mignaloux-Beauvoir
ref:INSEE = 86157

source:addr:postcode = source of postcode is from osm nodes

type = boundary
wikidata = Q1436018
wikipedia = fr:Mignaloux-Beauvoir


et plein d'autres...

Merci,

J.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[marc marc]

Bonjour,

l'équipe d'osmcarto vient de pousser la modif en production.
environ 2850 objets vont disparaître du rendu par défaut en France.

Cordialement,
Marc
 Message transféré 
Sujet : fin à venir du rendu osm.org pour shop=yes
Date : Thu, 22 Aug 2019 15:59:20 +0200
De : Marc M. 
Pour : talk-fr 

Bonjour,

osmcarto (le rendu par défaut sur osm.org) s’apprête à supprimer
le rendu des shop=yes, trouvant cette valeur trop imprécise que
pour être utile (mouhaha). c'est pas encore en prod mais c'est codé.
https://github.com/gravitystorm/openstreetmap-carto/issues/3697

Il y en a 3100 en France, 850 en Belgique, 400 en suisse, 77 au lux.
afin d'éviter leur disparition du rendu (on tag pas pour le rendu
mais c'est quand même mieux quand c'est visible), c'est sans doute
l'occasion et l'excuse pour les passer en revue et trouver une
valeur plus adaptée (existante ou à inventer à la hâte, hélas)

Pour trouver ceux dans votre coin :
https://overpass-turbo.eu/s/LJk
remplacez VotreLieu par le votre à la ligne 2 :)

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Osmose.... tag "postal_code"

[Jacques Lavignotte]

Bonjour,

j'essaye de comprendre Osmose...

Ces erreurs me reviennent, l'une au moins sur un de mes tags mais plein 
d'autres.


Je ne sais pas quoi faire sur :

 admin_level 8 without tag "postal_code"

dans :

relation 140258 analyse1 analyse2 josm iD edit
addr:postcode = 86550
admin_level = 8
boundary = administrative
name = Mignaloux-Beauvoir
ref:INSEE = 86157

source:addr:postcode = source of postcode is from osm nodes

type = boundary
wikidata = Q1436018
wikipedia = fr:Mignaloux-Beauvoir


et plein d'autres...

Merci,

J.

--
GnuPg : C8F5B1E3 Because privacy matters.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Canoeing infrastructure/river features

[Jez Nicholson]

Interesting. There must be some waterways fans around here somewhere. I can
see some pages like
https://wiki.openstreetmap.org/wiki/WikiProject_Whitewater_Maps which focus
on one aspect of canoeing, and some countries appear to have marked routes.

As a UK Mapper you could add to
https://wiki.openstreetmap.org/wiki/United_Kingdom_waterways and collect
some info relevant to UK canoeists.

- Jez

On Wed, Aug 28, 2019 at 5:00 AM Edward Bainton 
wrote:

> Hello all
>
> I've started to map some features useful (I hope) to canoeists such as
> myself.
> Eg, https://www.openstreetmap.org/changeset/73814496 (Irthlingborough
> Lock)
> Eg, https://www.openstreetmap.org/changeset/73815104 (bottom right)
>
> However, there seems to be quite a lack of objects on the wiki that are
> suitable. (Full disclosure: I'm an occasional, rather inexpert mapper.)
>
> Is this the place to discuss?
>
> Edward
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] OpenStreetMap Carto release v4.22.0

[Yves]

Oleksiy,
Those two changes are indeed very technical and are not related to mapping.
https://postgis.net/docs/ST_PointOnSurface.html

https://github.com/gravitystorm/openstreetmap-carto/issues/3756

Yves

Le 28 août 2019 08:13:13 GMT+02:00, Oleksiy Muzalyev 
 a écrit :
>Good morning,
>
>Thank you for the information.
>
>I did not understand these two changes. I would like to see an example 
>on the map or/and read a wiki article about the building label, the
>shop 
>label, and the ST_PointOnSurface.
>
>In the two following articles:
>
>https://wiki.openstreetmap.org/wiki/Key:shop
>https://wiki.openstreetmap.org/wiki/Shops
>https://wiki.openstreetmap.org/wiki/Key:building
>
>there is neither word "label", nor "ST_PointOnSurface". I would like to
>
>learn about it and, probably, use it.
>
>As for layers with attachments, - I guess it does not concern mapping 
>itself, but it's something related to a technical side of rendering. 
>Probably, a layer has got some PNG image files, which are used in icons
>
>or displaying certain areas, and they will be cached in the visitors' 
>browsers.
>
>Best regards,
>Oleksiy (Alex-7 @ OSM)
>
>On 8/28/19 06:57, Paul Norman via talk wrote:
>>
>> Changes include
>>
>> - Shop label fixes and use ST_PointOnSurface for building label
>placement
>>
>>   This fixes some bugs and makes building label placement consistent 
>> with shop
>>   label placement.
>>
>> - Use `cache-feature: true` to improve performance of layers with 
>> attachments
>> ...
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto release v4.22.0

[Oleksiy Muzalyev]

Yves,

Thank you. Everything is clear now.

Best regards,
Oleksiy

On 8/28/19 08:39, Yves wrote:

Oleksiy,
Those two changes are indeed very technical and are not related to 
mapping.

https://postgis.net/docs/ST_PointOnSurface.html

https://github.com/gravitystorm/openstreetmap-carto/issues/3756

Yves

Le 28 août 2019 08:13:13 GMT+02:00, Oleksiy Muzalyev 
 a écrit :


Good morning,

Thank you for the information.

I did not understand these two changes. I would like to see an example
on the map or/and read a wiki article about the building label, the shop
label, and the ST_PointOnSurface.

In the two following articles:

https://wiki.openstreetmap.org/wiki/Key:shop
https://wiki.openstreetmap.org/wiki/Shops
https://wiki.openstreetmap.org/wiki/Key:building

there is neither word "label", nor "ST_PointOnSurface". I would like to
learn about it and, probably, use it.

As for layers with attachments, - I guess it does not concern mapping
itself, but it's something related to a technical side of rendering.
Probably, a layer has got some PNG image files, which are used in icons
or displaying certain areas, and they will be cached in the visitors'
browsers.

Best regards,
Oleksiy (Alex-7 @ OSM)

On 8/28/19 06:57, Paul Norman via talk wrote:
>

Changes include - Shop label fixes and use ST_PointOnSurface
for building label placement   This fixes some bugs and makes
building label placement consistent with shop   label
placement. - Use `cache-feature: true` to improve performance
of layers with attachments ... 



talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



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

[Talk-it] OpenStreetMap e accessibilità a Padova

[Alessandro Sarretta]

Buongiorno a tutte e tutti,

sul tema OpenStreetMap e accessibilità a Padova, vi segnalo l'articolo 
pubblicato su Wikimedia Italia news ieri 
(https://www.wikimedia.it/padova-piu-accessibile-il-percorso-e-tracciato-su-openstreetmap) 
e il seminario che terrò questo pomeriggio, sempre a Padova 
(https://www.facebook.com/MasterGIScience/posts/2290538907875254).


Ale


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] OpenStreetMap Carto release v4.22.0

[Oleksiy Muzalyev]

Good morning,

Thank you for the information.

I did not understand these two changes. I would like to see an example 
on the map or/and read a wiki article about the building label, the shop 
label, and the ST_PointOnSurface.


In the two following articles:

https://wiki.openstreetmap.org/wiki/Key:shop
https://wiki.openstreetmap.org/wiki/Shops
https://wiki.openstreetmap.org/wiki/Key:building

there is neither word "label", nor "ST_PointOnSurface". I would like to 
learn about it and, probably, use it.


As for layers with attachments, - I guess it does not concern mapping 
itself, but it's something related to a technical side of rendering. 
Probably, a layer has got some PNG image files, which are used in icons 
or displaying certain areas, and they will be cached in the visitors' 
browsers.


Best regards,
Oleksiy (Alex-7 @ OSM)

On 8/28/19 06:57, Paul Norman via talk wrote:


Changes include

- Shop label fixes and use ST_PointOnSurface for building label placement

  This fixes some bugs and makes building label placement consistent 
with shop

  label placement.

- Use `cache-feature: true` to improve performance of layers with 
attachments

...



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