Re: [Talk-transit] Revisiting the use of ref in bus stops

[Paul Johnson]

If any.  Seems there's so many unanswered questions about mapping transit
in OSM that nothing solidly uses it yet.

On Fri, Aug 17, 2018 at 2:44 PM, Kevin Dalley  wrote:

> And then we need to look at all of the mapping programs, which need to
> interpret the new info.
>
> I'll do ref for now. It's fairly common in the AC Transit space.
>
> And most stops are single agency, with other agencies stopping nearby.
>
> On 08/17/2018 11:52 AM, Stephen Sprunk wrote:
> > ref:NS, where NS is some sort of namespace code, seems like the right
> > solution.  I see two problems:
> >
> > 1. Consumers only looking at ref will see nothing.  Perhaps it should
> > contain a semicolon-list of all the values in the suffixed tags?  Now
> > we're duplicating data, which introduces the risk of the tags getting
> > out of sync, but that's easy to automate.
> >
> > 2. It creates a new meta-namespace for namespace codes, which could have
> > its own collisions.  This is probably only a problem in practice if
> > collisions are nearby, though, so it may not be worth worrying about.
> >
> > S
> >
> >
> > On 2018-08-17 07:18, Wiklund Johan wrote:
> >
> >> It doesnt really matter if the country is organized if a bus comes
> >> from abroad and uses the stop (such as FlixBus). Organized world would
> >> fix it.
> >>
> >>
> >>
> >> *From:*Jo [mailto:winfi...@gmail.com]
> >> *Sent:* fredag 17. august 2018 10.05
> >> *To:* Public transport/transit/shared taxi related topics
> >> 
> >> *Subject:* Re: [Talk-transit] Revisiting the use of ref in bus stops
> >>
> >>
> >>
> >> We have 3 operators here in Belgium. I started by adding stops for 1
> >> first, so I used ref.
> >>
> >>
> >>
> >> Then I started working on the other operator and some stops are indeed
> >> shared. The other operator has 5 subdivisions and annoyingly they all
> >> assign their own identifiers, those stops also overlap.
> >>
> >>
> >>
> >> For a while I added 2 nodes, sometimes 3, but that really doesn't work
> >> well.
> >>
> >>
> >>
> >> So I merged them and now it's like this:
> >>
> >>
> >>
> >> ref:De_Lijn for stops of De Lijn
> >>
> >> ref:TECB for stops of TEC Brabant-Wallon
> >>
> >> ref:TECC for stops of TEC Charleroi
> >>
> >> ref:TECH for stops of TEC Hainaut
> >>
> >> ref:TECN for stops of TEC Namur
> >>
> >> ref:TECL for stops of TEC Liège
> >>
> >> reft:TECX for stops of TEC Luxembourg
> >>
> >>
> >>
> >> It's a bit messy, so I hope they'll change that at some point in the
> >> future.
> >>
> >>
> >>
> >> and the stops in Brussels could simply use ref, but I don't think we
> >> know their identifiers.
> >>
> >>
> >>
> >> In The Netherlands they are now using
> >>
> >>
> >>
> >> ref:IFOPT=NL:Q:78400680
> >>
> >>
> >>
> >> That would be better, but you need an organised country like The
> >> Netherlands to assign them.
> >>
> >>
> >>
> >> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to
> >> sort together in the list of tags.
> >>
> >>
> >>
> >> I also use route_ref:OPRTR
> >>
> >>
> >>
> >> Polyglot
> >>
> >>
> >>
> >> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson  >> >:
> >>
> >> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  >> > wrote:
> >>
> >> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC
> >> Transit.
> >>
> >> For AC Transit, the gtfs_id, or stop_code, can be used to
> >> identify the
> >> stop. That's the number on the sign, and can be as a phone code.
> >>
> >> For example,
> >>
> >> stop code is 56669
> >>
> >> stop_name is: "MacArthur Blvd:Randolph Av"
> >>
> >> stop name does not appear on the sign, though variations of
> >> this name
> >> appear on the schedule, usually with a "&" rather than ":".
> >>
> >> stop_code does appear on sign.
> >>
> >> I agree with previous users that, at least for AC Transit,
> >> stop_code
> >> should translated to "ref", which a defined meaning for
> bus_stop.
> >> GO-Sync does not do this, though it would be easy to patch my
> >> version,
> >> at least for AC Transit.
> >>
> >> and use stop_name as name, which is what GO-Sync does.
> >>
> >> Are there recent thoughts on this issue?
> >>
> >>
> >>
> >>  I'm thinking ref on the stop needs to be entirely revisited,
> >> given stops may be used by more than one network and therefore
> >> have more than one ref.
> >>
> >>
> >>
> >> Maybe something like, say, trimet:ref=* for TriMet's stops, and
> >> tillamook-wave:ref=* for Tillamook County's The Wave, which share
> >> the same stop bays at Sunset Transit Center and several locations
> >> in downtown Portland, for example.
> >>
> >> ___
> >> Talk-transit mailing list
> >> Talk-transit@openstreetmap.org  openstreetmap.org>
> >> 

Re: [Talk-cz] OsmHiCheck - aktualizace na PhotoDB2

[Zdeněk Pražák]

ještě bych poprosil o opravu chování při kliknutí na odkazy
* seznam všech fote daného autora
* mozaika včech fotek daného autora které odkazují na toma k

* seznam všech fotek dle ref - odkazuje na ref BO160

pá 17. 8. 2018 v 15:12 odesílatel Tom Ka  napsal:

> Ahoj,
>
> provedl jsem prvni krok aktualizace OsmHiCheck kontrol rozcestniku na
> použití PhotoDB2.
> Jako dusledek doslo k uprave chovani, ktera tu byla kdysi davno
> poptavana ale delala se tehdy spatne.
> Nove se veskere kontroly a parovani (a nejen nepouzite fotky jak to
> bylo driv) delaji bez fotek s tagy:
>
> infotabule, mapa, cyklo, necitelne, znaceni, zruseno, prehledova,
> zahranicni, emergency, nohicheck
>
> Tim padem ubylo "spravne" detekovanych rozcestniku a presunuly se do
> kategorie "s ref ale bez img".
> Zaroven ztratila vyznam operace fetch tj. stazeni dat z api.osm.cz.
> Informace o snímcích se nyní berou z PhotoDB2 naprimo.
>
> Odkazy v tabulkach na fotky budou postupne upraveny z api.osm.cz na
> PhotoDB2.
>
> Mejte se tom.k
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] OsmHiCheck - aktualizace na PhotoDB2

[Zdeněk Pražák]

Ještě by bylo vhodné doplnit možnost opravy ref například u fotky s ID
20409 je jako ref uvedeno 355m, zatímco správně by mělo být VS355

pá 17. 8. 2018 v 15:12 odesílatel Tom Ka  napsal:

> Ahoj,
>
> provedl jsem prvni krok aktualizace OsmHiCheck kontrol rozcestniku na
> použití PhotoDB2.
> Jako dusledek doslo k uprave chovani, ktera tu byla kdysi davno
> poptavana ale delala se tehdy spatne.
> Nove se veskere kontroly a parovani (a nejen nepouzite fotky jak to
> bylo driv) delaji bez fotek s tagy:
>
> infotabule, mapa, cyklo, necitelne, znaceni, zruseno, prehledova,
> zahranicni, emergency, nohicheck
>
> Tim padem ubylo "spravne" detekovanych rozcestniku a presunuly se do
> kategorie "s ref ale bez img".
> Zaroven ztratila vyznam operace fetch tj. stazeni dat z api.osm.cz.
> Informace o snímcích se nyní berou z PhotoDB2 naprimo.
>
> Odkazy v tabulkach na fotky budou postupne upraveny z api.osm.cz na
> PhotoDB2.
>
> Mejte se tom.k
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] OsmHiCheck - aktualizace na PhotoDB2

[Zdeněk Pražák]

ještě by bylo vhodné z kontrol vyjmout fotky s tagy most, panorama

pá 17. 8. 2018 v 15:12 odesílatel Tom Ka  napsal:

> Ahoj,
>
> provedl jsem prvni krok aktualizace OsmHiCheck kontrol rozcestniku na
> použití PhotoDB2.
> Jako dusledek doslo k uprave chovani, ktera tu byla kdysi davno
> poptavana ale delala se tehdy spatne.
> Nove se veskere kontroly a parovani (a nejen nepouzite fotky jak to
> bylo driv) delaji bez fotek s tagy:
>
> infotabule, mapa, cyklo, necitelne, znaceni, zruseno, prehledova,
> zahranicni, emergency, nohicheck
>
> Tim padem ubylo "spravne" detekovanych rozcestniku a presunuly se do
> kategorie "s ref ale bez img".
> Zaroven ztratila vyznam operace fetch tj. stazeni dat z api.osm.cz.
> Informace o snímcích se nyní berou z PhotoDB2 naprimo.
>
> Odkazy v tabulkach na fotky budou postupne upraveny z api.osm.cz na
> PhotoDB2.
>
> Mejte se tom.k
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-au] Using data from traditional owners of the land / Current waiver form

[Ewen Hill]

Hi,
   The people of the Goolarabooloo and Jabirr Jabirr countries around Broome
developed a 90km walking trail to showcase their country. This was done 30
years ago and uses roads, beach, rock escarpments and overgrown trails. You
are welcome to use  the trail yourself but the country organises guided
walks which are infrequent (3 or 4 a year of parts of the walk). 

   I have sent the Goolarabooloo people a basic email offering assistance to
them drawing the route themselves or offering to provide a waiver later
however a few questions piqued my interest

1. Has anyone dealt with Aborignal elders to obtain knowledge before and was
it successful?
2. Is a walk copyright-able or where does OSM sit when it comes to elders
use of knowledge of country to construct a walk relatively recently where
parts of the walk will be arbitrary depending on tide and season.
3. Can someone assist with the location of the current waiver form and
process







--
Sent from: http://gis.19327.n8.nabble.com/Australia-f5416966.html

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

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

[Daniel Koć]

W dniu 17.08.2018 o 19:49, Dave F pisze:
> Thanks for letting us know. Wasted half an hour checking it wasn't
> just me & providing examples.
>
> How about not posting until it's been deployed in future?

Hi Dave,

Multiple times before the release has been deployed eventually,
typically in days or even hours. This was a special moment when there
were some unusual works with hardware and software infrastructure and I
was not even aware that it will take so long, that 3 following releases
(!) won't be deployed at OSMF servers. Moreover release message does not
promise if and when this might occur ("Once changes are deployed on the
openstreetmap.org it will take couple of days before all tiles show the
new rendering.").

As this is very rare problem and would make release even more
complicated process, I rather won't follow this suggestion, sorry. BTW:
v4.14.0 deployment on OSMF servers has already started, so this time
announcement follows it.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

[OSM-talk] OpenStreetMap Carto release v4.14.0

[Daniel Koć]

Dear all,

Yesterday, v4.14.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released and rolled out to the
openstreetmap.org servers. It might take a couple of days before all
tiles show the new rendering.

Changes include
- Added text-repeat-distance for waterways
- Added text-repeat-distance for railways
- Added icon for leisure=bowling_alley
- Added icon for leisure=outdoor_seating
- Added icon for leisure=bird_hide
- Added icon for shop=video
- Added icon for shop=paint
- Added icon for shop=massage
- Increased casing width of tertiary road on z12
- Standard text halo for fitness_centre and fitness_station
- Updated Docker images definitions
- Small documentation updates

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.13.0...v4.14.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [OSM-talk-fr] Créer un node à une lat/long précise

[pepilepi...@ovh.fr]

Le 17/08/2018 à 21:37, willemijns a écrit :
> Hello, 
>
> Un monument dans une foret n'est pas à sa place sur OSM, comment creer déjà
> un node à un emplacement précis de lat/long  sur OSM ?

Bonsoir,

Avec JOSM :  D

Bonne soirée,

JP

>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Kevin Dalley]

And then we need to look at all of the mapping programs, which need to
interpret the new info.

I'll do ref for now. It's fairly common in the AC Transit space.

And most stops are single agency, with other agencies stopping nearby.

On 08/17/2018 11:52 AM, Stephen Sprunk wrote:
> ref:NS, where NS is some sort of namespace code, seems like the right
> solution.  I see two problems:
> 
> 1. Consumers only looking at ref will see nothing.  Perhaps it should
> contain a semicolon-list of all the values in the suffixed tags?  Now
> we're duplicating data, which introduces the risk of the tags getting
> out of sync, but that's easy to automate.
> 
> 2. It creates a new meta-namespace for namespace codes, which could have
> its own collisions.  This is probably only a problem in practice if
> collisions are nearby, though, so it may not be worth worrying about.
> 
> S
> 
> 
> On 2018-08-17 07:18, Wiklund Johan wrote:
> 
>> It doesnt really matter if the country is organized if a bus comes
>> from abroad and uses the stop (such as FlixBus). Organized world would
>> fix it.
>>
>>  
>>
>> *From:*Jo [mailto:winfi...@gmail.com]
>> *Sent:* fredag 17. august 2018 10.05
>> *To:* Public transport/transit/shared taxi related topics
>> 
>> *Subject:* Re: [Talk-transit] Revisiting the use of ref in bus stops
>>
>>  
>>
>> We have 3 operators here in Belgium. I started by adding stops for 1
>> first, so I used ref.
>>
>>  
>>
>> Then I started working on the other operator and some stops are indeed
>> shared. The other operator has 5 subdivisions and annoyingly they all
>> assign their own identifiers, those stops also overlap.
>>
>>  
>>
>> For a while I added 2 nodes, sometimes 3, but that really doesn't work
>> well.
>>
>>  
>>
>> So I merged them and now it's like this:
>>
>>  
>>
>> ref:De_Lijn for stops of De Lijn
>>
>> ref:TECB for stops of TEC Brabant-Wallon
>>
>> ref:TECC for stops of TEC Charleroi
>>
>> ref:TECH for stops of TEC Hainaut
>>
>> ref:TECN for stops of TEC Namur
>>
>> ref:TECL for stops of TEC Liège
>>
>> reft:TECX for stops of TEC Luxembourg
>>
>>  
>>
>> It's a bit messy, so I hope they'll change that at some point in the
>> future.
>>
>>  
>>
>> and the stops in Brussels could simply use ref, but I don't think we
>> know their identifiers.
>>
>>  
>>
>> In The Netherlands they are now using
>>
>>  
>>
>> ref:IFOPT=NL:Q:78400680
>>
>>  
>>
>> That would be better, but you need an organised country like The
>> Netherlands to assign them.
>>
>>  
>>
>> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to
>> sort together in the list of tags.
>>
>>  
>>
>> I also use route_ref:OPRTR
>>
>>  
>>
>> Polyglot
>>
>>  
>>
>> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson > >:
>>
>> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley > > wrote:
>>
>> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC 
>> Transit.
>>
>> For AC Transit, the gtfs_id, or stop_code, can be used to
>> identify the
>> stop. That's the number on the sign, and can be as a phone code.
>>
>> For example,
>>
>> stop code is 56669
>>
>> stop_name is: "MacArthur Blvd:Randolph Av"
>>
>> stop name does not appear on the sign, though variations of
>> this name
>> appear on the schedule, usually with a "&" rather than ":".
>>
>> stop_code does appear on sign.
>>
>> I agree with previous users that, at least for AC Transit,
>> stop_code
>> should translated to "ref", which a defined meaning for bus_stop.
>> GO-Sync does not do this, though it would be easy to patch my
>> version,
>> at least for AC Transit.
>>
>> and use stop_name as name, which is what GO-Sync does.
>>
>> Are there recent thoughts on this issue?
>>
>>  
>>
>>  I'm thinking ref on the stop needs to be entirely revisited,
>> given stops may be used by more than one network and therefore
>> have more than one ref.
>>
>>  
>>
>> Maybe something like, say, trimet:ref=* for TriMet's stops, and
>> tillamook-wave:ref=* for Tillamook County's The Wave, which share
>> the same stop bays at Sunset Transit Center and several locations
>> in downtown Portland, for example.
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> -- 
> Stephen Sprunk  "Those people who think they know everything
> CCIE #3723 are a great annoyance to those of us who do."
> K5SSS --Isaac 

[OSM-talk-fr] Créer un node à une lat/long précise

[willemijns]

Hello, 

Un monument dans une foret n'est pas à sa place sur OSM, comment creer déjà
un node à un emplacement précis de lat/long  sur OSM ?



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Stephen Sprunk]

ref:NS, where NS is some sort of namespace code, seems like the right
solution.  I see two problems: 

1. Consumers only looking at ref will see nothing.  Perhaps it should
contain a semicolon-list of all the values in the suffixed tags?  Now
we're duplicating data, which introduces the risk of the tags getting
out of sync, but that's easy to automate. 

2. It creates a new meta-namespace for namespace codes, which could have
its own collisions.  This is probably only a problem in practice if
collisions are nearby, though, so it may not be worth worrying about. 

S 

On 2018-08-17 07:18, Wiklund Johan wrote:

> It doesnt really matter if the country is organized if a bus comes from 
> abroad and uses the stop (such as FlixBus). Organized world would fix it. 
> 
> FROM: Jo [mailto:winfi...@gmail.com] 
> SENT: fredag 17. august 2018 10.05
> TO: Public transport/transit/shared taxi related topics 
> 
> SUBJECT: Re: [Talk-transit] Revisiting the use of ref in bus stops 
> 
> We have 3 operators here in Belgium. I started by adding stops for 1 first, 
> so I used ref.
> 
> Then I started working on the other operator and some stops are indeed 
> shared. The other operator has 5 subdivisions and annoyingly they all assign 
> their own identifiers, those stops also overlap. 
> 
> For a while I added 2 nodes, sometimes 3, but that really doesn't work well. 
> 
> So I merged them and now it's like this: 
> 
> ref:De_Lijn for stops of De Lijn 
> 
> ref:TECB for stops of TEC Brabant-Wallon 
> 
> ref:TECC for stops of TEC Charleroi 
> 
> ref:TECH for stops of TEC Hainaut 
> 
> ref:TECN for stops of TEC Namur 
> 
> ref:TECL for stops of TEC Liège 
> 
> reft:TECX for stops of TEC Luxembourg 
> 
> It's a bit messy, so I hope they'll change that at some point in the future. 
> 
> and the stops in Brussels could simply use ref, but I don't think we know 
> their identifiers. 
> 
> In The Netherlands they are now using 
> 
> ref:IFOPT=NL:Q:78400680 
> 
> That would be better, but you need an organised country like The Netherlands 
> to assign them. 
> 
> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to sort 
> together in the list of tags. 
> 
> I also use route_ref:OPRTR 
> 
> Polyglot 
> 
> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson : 
> 
> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  wrote: 
> 
> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC  Transit.
> 
> For AC Transit, the gtfs_id, or stop_code, can be used to identify the
> stop. That's the number on the sign, and can be as a phone code.
> 
> For example,
> 
> stop code is 56669
> 
> stop_name is: "MacArthur Blvd:Randolph Av"
> 
> stop name does not appear on the sign, though variations of this name
> appear on the schedule, usually with a "&" rather than ":".
> 
> stop_code does appear on sign.
> 
> I agree with previous users that, at least for AC Transit, stop_code
> should translated to "ref", which a defined meaning for bus_stop.
> GO-Sync does not do this, though it would be easy to patch my version,
> at least for AC Transit.
> 
> and use stop_name as name, which is what GO-Sync does.
> 
> Are there recent thoughts on this issue? 
> 
> I'm thinking ref on the stop needs to be entirely revisited, given stops may 
> be used by more than one network and therefore have more than one ref. 
> 
> Maybe something like, say, trimet:ref=* for TriMet's stops, and 
> tillamook-wave:ref=* for Tillamook County's The Wave, which share the same 
> stop bays at Sunset Transit Center and several locations in downtown 
> Portland, for example. 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

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

-- 
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

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

[Dave F]

I know, which is why I removed you from c/c.

On 17/08/2018 18:49, Dave F wrote:
Thanks for letting us know. Wasted half an hour checking it wasn't 
just me & providing examples.


How about not posting until it's been deployed in future?

DaveF

On 17/08/2018 18:35, Tom Hughes wrote:

That version was never actually deployed because we were busy
doing upgrades to the rendering stack.

The 4.14.0 has just been pushed and should go live over the
weekend.

Tom

On 17/08/18 18:25, Dave F wrote:

Hi

Are any of these icons displaying?

For me, charity & houseware are still dots & casino is only 
rendering the name.

https://www.openstreetmap.org/way/418385072#map=19/51.49491/-0.13207
https://www.openstreetmap.org/way/349935002#map=19/51.51279/-0.13030

Casino as node doesn't display icon or name:
https://www.openstreetmap.org/node/4868309016

I've zoomed in to z19 & refreshed my browser's cache.

Cheers
DaveF

On 23/07/2018 15:16, Daniel Koć wrote:

Dear all,

Today, v4.13.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0 



As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues




___
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

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

[Tom Hughes]

Nothing to do with me, that's the carto team.

Tom

On 17/08/18 18:49, Dave F wrote:
Thanks for letting us know. Wasted half an hour checking it wasn't just 
me & providing examples.


How about not posting until it's been deployed in future?

DaveF

On 17/08/2018 18:35, Tom Hughes wrote:

That version was never actually deployed because we were busy
doing upgrades to the rendering stack.

The 4.14.0 has just been pushed and should go live over the
weekend.

Tom

On 17/08/18 18:25, Dave F wrote:

Hi

Are any of these icons displaying?

For me, charity & houseware are still dots & casino is only rendering 
the name.

https://www.openstreetmap.org/way/418385072#map=19/51.49491/-0.13207
https://www.openstreetmap.org/way/349935002#map=19/51.51279/-0.13030

Casino as node doesn't display icon or name:
https://www.openstreetmap.org/node/4868309016

I've zoomed in to z19 & refreshed my browser's cache.

Cheers
DaveF

On 23/07/2018 15:16, Daniel Koć wrote:

Dear all,

Today, v4.13.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0 



As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues




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






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



--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

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

[Dave F]

Thanks for letting us know. Wasted half an hour checking it wasn't just 
me & providing examples.


How about not posting until it's been deployed in future?

DaveF

On 17/08/2018 18:35, Tom Hughes wrote:

That version was never actually deployed because we were busy
doing upgrades to the rendering stack.

The 4.14.0 has just been pushed and should go live over the
weekend.

Tom

On 17/08/18 18:25, Dave F wrote:

Hi

Are any of these icons displaying?

For me, charity & houseware are still dots & casino is only rendering 
the name.

https://www.openstreetmap.org/way/418385072#map=19/51.49491/-0.13207
https://www.openstreetmap.org/way/349935002#map=19/51.51279/-0.13030

Casino as node doesn't display icon or name:
https://www.openstreetmap.org/node/4868309016

I've zoomed in to z19 & refreshed my browser's cache.

Cheers
DaveF

On 23/07/2018 15:16, Daniel Koć wrote:

Dear all,

Today, v4.13.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0 



As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues




___
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.13.0

[Tom Hughes]

That version was never actually deployed because we were busy
doing upgrades to the rendering stack.

The 4.14.0 has just been pushed and should go live over the
weekend.

Tom

On 17/08/18 18:25, Dave F wrote:

Hi

Are any of these icons displaying?

For me, charity & houseware are still dots & casino is only rendering 
the name.

https://www.openstreetmap.org/way/418385072#map=19/51.49491/-0.13207
https://www.openstreetmap.org/way/349935002#map=19/51.51279/-0.13030

Casino as node doesn't display icon or name:
https://www.openstreetmap.org/node/4868309016

I've zoomed in to z19 & refreshed my browser's cache.

Cheers
DaveF

On 23/07/2018 15:16, Daniel Koć wrote:

Dear all,

Today, v4.13.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0 



As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues




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



--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

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

[Dave F]

Hi

Are any of these icons displaying?

For me, charity & houseware are still dots & casino is only rendering 
the name.

https://www.openstreetmap.org/way/418385072#map=19/51.49491/-0.13207
https://www.openstreetmap.org/way/349935002#map=19/51.51279/-0.13030

Casino as node doesn't display icon or name:
https://www.openstreetmap.org/node/4868309016

I've zoomed in to z19 & refreshed my browser's cache.

Cheers
DaveF

On 23/07/2018 15:16, Daniel Koć wrote:

Dear all,

Today, v4.13.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues




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

Re: [OSM-talk-fr] date de l'imagerie

[Vincent Privat]

C'est dispo en licence libre la BD Ortho 5 cm de Paris ? Je ne la trouve
pas ici: http://professionnels.ign.fr/orthohr-par-departements#tab-1

Le ven. 17 août 2018 à 12:37, Christian Quest  a
écrit :

> La source de l'umap ce sont les shapefile de mosaique de la BDORtho
> 5m... republiés dans OpenEventDatabase
>
> Par contre, il faut aussi prévoir la mise à jour de cette source, car là
> ça commence à dater. Ce n'est pas parfait non plus car c'est la BD Ortho
> 5m (donc gros pixels) alors qu'on a maintenant des zones avec du 5cm
> (Paris).
>
> Sinon, l'IGN publie les années de prises de vues de la BD Ortho
> département par département, ce qui peut être largement suffisant comme
> info: http://professionnels.ign.fr/mises-a-jour
>
> Pour 2017 on trouve:
>
> 21-24-25-39-47-87-971-972-978 à 20cm
>
> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56 13-25-39-47-87-971 à 50cm
>
> Malheureusement, ces tableaux ne sont pas très simple à lire car on a
> des millésimes différent en fonction des niveaux de zoom.
>
> Si un courageux veut remettre ça au propre dans un beau CSV ça serait
> fort utile.
>
>
> Le 15/08/2018 à 02:26, marc marc a écrit :
> > Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :
> >> la date de la prise de vu comme on peut l'avoir sur Google Earth ou
> > il y a les 2 lorsque les 2 sont disponibles.
> > la date de capture dans josm s'affiche chez moi avec
> > comme mention "métadonnée capture date"
> > et est visible par exemple avec la couche Bing
> > oui je sais c'est triste comme exemple :)
> >
> > Mais si quelqu'un est motivée pour coder l'injection des infos
> > dans les headers du proxy BDOrtho osm-fr, c'est techniquement possible
> > et un coup de main n'est jamais refusé :)
> > sinon c'est sur ma longue liste de chose à faire... et pas la moindre
> > idée de ce que cela va impliquer en boulot (j'ai pas encore regardé
> > la source de l'umap de Christian)
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] date de l'imagerie

[deuzeffe]

Pour l'IGN, 977 et 978 = Polynésie et Nouvelle-Calédonie !?

On 17/08/2018 16:48, deuzeffe wrote:

Je regarde ça.

On 17/08/2018 12:36, Christian Quest wrote:
La source de l'umap ce sont les shapefile de mosaique de la BDORtho 
5m... republiés dans OpenEventDatabase


Par contre, il faut aussi prévoir la mise à jour de cette source, car 
là ça commence à dater. Ce n'est pas parfait non plus car c'est la BD 
Ortho 5m (donc gros pixels) alors qu'on a maintenant des zones avec du 
5cm (Paris).


Sinon, l'IGN publie les années de prises de vues de la BD Ortho 
département par département, ce qui peut être largement suffisant 
comme info: http://professionnels.ign.fr/mises-a-jour


Pour 2017 on trouve:

21-24-25-39-47-87-971-972-978 à 20cm

21-24-25-39-75-92-93-971-972-978 06-07-21-47 56 13-25-39-47-87-971 à 50cm

Malheureusement, ces tableaux ne sont pas très simple à lire car on a 
des millésimes différent en fonction des niveaux de zoom.


Si un courageux veut remettre ça au propre dans un beau CSV ça serait 
fort utile.



Le 15/08/2018 à 02:26, marc marc a écrit :

Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :

la date de la prise de vu comme on peut l'avoir sur Google Earth ou

il y a les 2 lorsque les 2 sont disponibles.
la date de capture dans josm s'affiche chez moi avec
comme mention "métadonnée capture date"
et est visible par exemple avec la couche Bing
oui je sais c'est triste comme exemple :)

Mais si quelqu'un est motivée pour coder l'injection des infos
dans les headers du proxy BDOrtho osm-fr, c'est techniquement possible
et un coup de main n'est jamais refusé :)
sinon c'est sur ma longue liste de chose à faire... et pas la moindre
idée de ce que cela va impliquer en boulot (j'ai pas encore regardé
la source de l'umap de Christian)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




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


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

Re: [OSM-talk-fr] Bilan du Projet du mois de juillet 2018 : les postes électriques

[deuzeffe]

On 13/08/2018 13:13, deuzeffe wrote:

Bref, cet affichage des noms est perturbant, non ? 


C'est rigolo (ou pas) : à l'inverse, quand une station d'épuration est 
dans la base avec son nom, le nom n'est même pas affiché (je ne parle 
pas du rendu de l'emprise de la station...)


--
deuzeffe, perturbée.

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

Re: [OSM-talk-fr] date de l'imagerie

[deuzeffe]

Je regarde ça.

On 17/08/2018 12:36, Christian Quest wrote:
La source de l'umap ce sont les shapefile de mosaique de la BDORtho 
5m... republiés dans OpenEventDatabase


Par contre, il faut aussi prévoir la mise à jour de cette source, car là 
ça commence à dater. Ce n'est pas parfait non plus car c'est la BD Ortho 
5m (donc gros pixels) alors qu'on a maintenant des zones avec du 5cm 
(Paris).


Sinon, l'IGN publie les années de prises de vues de la BD Ortho 
département par département, ce qui peut être largement suffisant comme 
info: http://professionnels.ign.fr/mises-a-jour


Pour 2017 on trouve:

21-24-25-39-47-87-971-972-978 à 20cm

21-24-25-39-75-92-93-971-972-978 06-07-21-47 56 13-25-39-47-87-971 à 50cm

Malheureusement, ces tableaux ne sont pas très simple à lire car on a 
des millésimes différent en fonction des niveaux de zoom.


Si un courageux veut remettre ça au propre dans un beau CSV ça serait 
fort utile.



Le 15/08/2018 à 02:26, marc marc a écrit :

Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :

la date de la prise de vu comme on peut l'avoir sur Google Earth ou

il y a les 2 lorsque les 2 sont disponibles.
la date de capture dans josm s'affiche chez moi avec
comme mention "métadonnée capture date"
et est visible par exemple avec la couche Bing
oui je sais c'est triste comme exemple :)

Mais si quelqu'un est motivée pour coder l'injection des infos
dans les headers du proxy BDOrtho osm-fr, c'est techniquement possible
et un coup de main n'est jamais refusé :)
sinon c'est sur ma longue liste de chose à faire... et pas la moindre
idée de ce que cela va impliquer en boulot (j'ai pas encore regardé
la source de l'umap de Christian)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




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

[Talk-cz] OsmHiCheck - aktualizace na PhotoDB2

[Tom Ka]

Ahoj,

provedl jsem prvni krok aktualizace OsmHiCheck kontrol rozcestniku na
použití PhotoDB2.
Jako dusledek doslo k uprave chovani, ktera tu byla kdysi davno
poptavana ale delala se tehdy spatne.
Nove se veskere kontroly a parovani (a nejen nepouzite fotky jak to
bylo driv) delaji bez fotek s tagy:

infotabule, mapa, cyklo, necitelne, znaceni, zruseno, prehledova,
zahranicni, emergency, nohicheck

Tim padem ubylo "spravne" detekovanych rozcestniku a presunuly se do
kategorie "s ref ale bez img".
Zaroven ztratila vyznam operace fetch tj. stazeni dat z api.osm.cz.
Informace o snímcích se nyní berou z PhotoDB2 naprimo.

Odkazy v tabulkach na fotky budou postupne upraveny z api.osm.cz na PhotoDB2.

Mejte se tom.k

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

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Wiklund Johan]

It doesnt really matter if the country is organized if a bus comes from abroad 
and uses the stop (such as FlixBus). Organized world would fix it.

From: Jo [mailto:winfi...@gmail.com]
Sent: fredag 17. august 2018 10.05
To: Public transport/transit/shared taxi related topics 

Subject: Re: [Talk-transit] Revisiting the use of ref in bus stops

We have 3 operators here in Belgium. I started by adding stops for 1 first, so 
I used ref.

Then I started working on the other operator and some stops are indeed shared. 
The other operator has 5 subdivisions and annoyingly they all assign their own 
identifiers, those stops also overlap.

For a while I added 2 nodes, sometimes 3, but that really doesn't work well.

So I merged them and now it's like this:

ref:De_Lijn for stops of De Lijn
ref:TECB for stops of TEC Brabant-Wallon
ref:TECC for stops of TEC Charleroi
ref:TECH for stops of TEC Hainaut
ref:TECN for stops of TEC Namur
ref:TECL for stops of TEC Liège
reft:TECX for stops of TEC Luxembourg

It's a bit messy, so I hope they'll change that at some point in the future.

and the stops in Brussels could simply use ref, but I don't think we know their 
identifiers.

In The Netherlands they are now using

ref:IFOPT=NL:Q:78400680

That would be better, but you need an organised country like The Netherlands to 
assign them.

So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to sort 
together in the list of tags.

I also use route_ref:OPRTR

Polyglot

Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson 
mailto:ba...@ursamundi.org>>:
On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley 
mailto:ke...@kelphead.org>> wrote:
I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC  Transit.

For AC Transit, the gtfs_id, or stop_code, can be used to identify the
stop. That's the number on the sign, and can be as a phone code.

For example,

stop code is 56669

stop_name is: "MacArthur Blvd:Randolph Av"

stop name does not appear on the sign, though variations of this name
appear on the schedule, usually with a "&" rather than ":".

stop_code does appear on sign.

I agree with previous users that, at least for AC Transit, stop_code
should translated to "ref", which a defined meaning for bus_stop.
GO-Sync does not do this, though it would be easy to patch my version,
at least for AC Transit.

and use stop_name as name, which is what GO-Sync does.

Are there recent thoughts on this issue?

 I'm thinking ref on the stop needs to be entirely revisited, given stops may 
be used by more than one network and therefore have more than one ref.

Maybe something like, say, trimet:ref=* for TriMet's stops, and 
tillamook-wave:ref=* for Tillamook County's The Wave, which share the same stop 
bays at Sunset Transit Center and several locations in downtown Portland, for 
example.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-cz] geograficke regiony v CR

[xkomc...@centrum.cz]

Dobrý zdroj je k dispozici zde: 
https://geoportal.gov.cz/web/guest/map?permalink=f5e4a0b5294570e0c663d667facb9e2f 
(lze připojit jako WMS), ale netuším, jak je to u něj s licencí.



Problém bude u nejnižších regionů - okrsků: ty definují různí autoři 
různě. Na tento problém jsem narazil před časem, kdy jsem o nich chtěl 
psát na Wikipedii: 
https://cs.wikipedia.org/wiki/Diskuse_s_wikipedistou:Tomastr#Geomorfologick%C3%A9_%C4%8Dlen%C4%9Bn%C3%AD_Brn%C4%9Bnsk%C3%A9_vrchoviny 




On 15.8.2018 10:41, Martin Ždila wrote:

Este pre inspiraciu, ako to mame zatial zmapovane na Slovensku:

https://overpass-turbo.eu/s/B46

Nejaky zdroj (nevravim, ze bol pouzity na mapovanie: 
https://en.wikipedia.org/wiki/Geomorphological_division_of_Slovakia#Lu%C4%8Densko-ko%C5%A1ick%C3%A1_zn%C3%AD%C5%BEenina_(Lu%C4%8Denec-Ko%C5%A1ice_Depression)_(area) 
 
)


Z tej stranky na wikipedii vidno, ze by to mohla byt hierarchia relacii.

--
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk 
http://www.freemap.sk/ 




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


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

Re: [OSM-talk] [test] Customized Taginfo : 620 areas - every country and some new experimental features ( ~ 1 week test )

[Imre Samu]

Hi Frédéric,

Thank you for the feedback.
I will recheck the big countries config files  ( France,  Russia, Canada,
Germany, U.S, Japan ) in the next version.

background:  I have started the development with 8GB RAM - and this is too
low for processing some countries.

Thanks,
  Imre


Frédéric Rodrigo  ezt írta (időpont: 2018. aug.
16., Cs, 15:24):

> Hello,
>
> It's an impressive job. It can really help.
> Just a note about France, you split France on admin_level=6, this result
> on around 100 pieces, it does not make sens. For France admin_level=4 is
> the only right level of sub area.
>
> Like for France or other countries, sub levels is interesting but the
> country as a whole also..
>
> Frédéric.
>
>
> Le 14/08/2018 à 20:26, Imre Samu a écrit :
> > This is a Proof of Concept of my vision [ customizing taginfo for
> > countries, regions ]
> > in my experience - It can be useful for finding local tagging errors.
> >
> >
> > dev site: http://taginfo-dev.opengeodata.hu
> >  find your area/country
> > 1 week test:   shutdown time: *~ 2018-aug-20 ( GMT 23:00h )*
> >
> >
> > Main changes:
> >
> > *-  620 areas  - not refreshing *
> >   = 620 docker services running in a simple cloud machine.
> > 32Gb RAM,   slow CPU :  Intel(R) Atom(TM) CPU
> > C2750  @ 2.40GHz,   8 core ,  ~ 600Gb Disk )
> >
> > *-  2 new experimental reports*:
> >
> >   "QA-Normalized name differences (Experimental)"
> > example:
> > http://eu-at.taginfo-dev.opengeodata.hu/reports/normalized_names
> > The result can be download as an xlsx file:
> > http://eu-at.taginfo-dev.opengeodata.hu/download/normalized_names.xlsx
> >
> > ( I hope - this will be useful for the localized
> > https://github.com/osmlab/name-suggestion-index
> >  ( see
> > https://github.com/osmlab/name-suggestion-index/issues/11 )
> >
> >
> >   "QA-Problematic tags (Experimental)" [ still a lot of bugs,
> >  for example:  checking access type of tags  is not perfect yet, sorry ]
> >  example:
> > http://eu-at.taginfo-dev.opengeodata.hu/reports/problematic_tags
> >  .xlsx result:
> > http://eu-at.taginfo-dev.opengeodata.hu/download/problematic_tags.xlsx
> >
> > *- `name` support for tags  ( Experimental ) *
> >
> >  examples:
> >  Spain   amenity=place_of_worship ( names in Spanish  + Català
> > (ca), Galego (ga) and Euskera (eu) )
> >  name   =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang1
> >  name:es  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang2
> >  name:eu  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang3
> >  name:ca  =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang4
> >  name:gl   =
> >
> http://eu-es.taginfo-dev.opengeodata.hu/tags/amenity=place_of_worship#tagnames_lang5
> >
> >
> >or Switzerland   amenity=bank
> >  name   =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang1
> >  name:en  =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang2
> >  name:de  =
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang3
> >  name:fr=
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang4
> >  name:it=
> > http://eu-ch.taginfo-dev.opengeodata.hu/tags/amenity=bank#tagnames_lang5
> >   the "name:*" tags configured on the
> > https://wiki.openstreetmap.org/wiki/Multilingual_names info but not
> > perfect yet.
> >
> >   so "Belgium has three official languages (Dutch, French and
> > German) "so the *amenity=pub * names is:
> >name =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang1
> >name:fr  =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang2
> >name:nl =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang3
> >name:en =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang4
> >name:de =
> > http://eu-be.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang5
> >  or in Ireland (Republic )  -  amenity=pub  names  in a Gaeltacht
> > (name:ga)  :
> > http://eu-ie.taginfo-dev.opengeodata.hu/tags/amenity=pub#tagnames_lang3
> >
> >   It is interesting for checking in your area the tag"names" of
> > *=yes  tags -  some of them easy to fix.
> >* shop=yes  ;  amenity=yes   ;man_made=yes ; natural=yes
> > ; sport=yes  ; leisure=yes
> >
> >   amenity=yes  in the UK (
> > http://eu-gb.taginfo-dev.opengeodata.hu/tags/amenity=yes#tagnames_lang1
> )
> >   shop=yes   in the UK (
> > http://eu-gb.taginfo-dev.opengeodata.hu/tags/shop=yes#tagnames_lang1 )
> >
> > *

Re: [Talk-us] place=locality on rail junction

[OSM Volunteer stevea]

On Aug 17, 2018, at 2:59 AM, talk-us-requ...@openstreetmap.org wrote:
When I come upon these, what's The Right Thing?  'railway=junction ref="CPF 
499"' instead?

Hi Kevin:  "Railroad place names" in the USA have a lore all their own.  
Sometimes and even often in remote/rural areas, simple junctions, switches or 
sidings which were named by the railroads "turned into" what we (in OSM and 
other contexts) might call a "locality" or even serve as the de facto location 
of a hamlet or village, especially as a station serving freight or passengers 
also "grew up" there.  A surprising number of these (thousands, at least) 
survive presently.  Railroads heavily influenced how the USA became what we are 
today (landuse patterns, industrial zones...).

Though you didn't specify exact nodes so their "true railway function" can be 
determined, I did an Overpass Turbo query in your area and found some.  Many 
are switches, some are junctions.  While 
https://wiki.osm.org/wiki/OpenRailwayMap/Tagging can be daunting documentation 
and could prove helpful, https://wiki.osm.org/wiki/Tag:railway=switch is much 
more succinct.  Simply assure these are at a point where two rail lines diverge 
and modify tags to be railway=switch and ref=CPF 499 (or whatever).  However, 
they may also be junctions instead of switches:  see 
https://wiki.osm.org/wiki/Tag:railway=junction (quite brief) and note that a 
switch diverges two lines whereas a junction might not.

So, if it's a switch, name becomes ref and place=locality becomes 
railway=switch, but only if you are fairly certain it is where two rail lines 
diverge.  If you are not sure it is a railway=switch, it might be a junction 
(e.g. Cherry Valley Junction).  Tags there should be railway=junction + 
name=Cherry Valley Junction (not ref=*).

More difficult still is when the node is NOT part of the rail infrastructure (a 
node actually on the railway=rail, maybe it's simply a node nearby a rail line) 
as then place=locality truly might be an accurate tag.

BTW, I've been cleaning up NE2 messes (as I find them) since about 2011 (even 
after he would rudely swear at me in my polite emails to him); good riddance to 
NE2.  His horrific sense of bicycle routing turned into me and others first 
tearing out our hair in frustration, then we began our USBRS WikiProject.  So:  
lemons?  Lemonade!

Thank you for asking the list.

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

Re: [OSM-talk-fr] date de l'imagerie

[Christian Quest]

La source de l'umap ce sont les shapefile de mosaique de la BDORtho 
5m... republiés dans OpenEventDatabase


Par contre, il faut aussi prévoir la mise à jour de cette source, car là 
ça commence à dater. Ce n'est pas parfait non plus car c'est la BD Ortho 
5m (donc gros pixels) alors qu'on a maintenant des zones avec du 5cm 
(Paris).


Sinon, l'IGN publie les années de prises de vues de la BD Ortho 
département par département, ce qui peut être largement suffisant comme 
info: http://professionnels.ign.fr/mises-a-jour


Pour 2017 on trouve:

21-24-25-39-47-87-971-972-978 à 20cm

21-24-25-39-75-92-93-971-972-978 06-07-21-47 56 13-25-39-47-87-971 à 50cm

Malheureusement, ces tableaux ne sont pas très simple à lire car on a 
des millésimes différent en fonction des niveaux de zoom.


Si un courageux veut remettre ça au propre dans un beau CSV ça serait 
fort utile.



Le 15/08/2018 à 02:26, marc marc a écrit :

Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :

la date de la prise de vu comme on peut l'avoir sur Google Earth ou

il y a les 2 lorsque les 2 sont disponibles.
la date de capture dans josm s'affiche chez moi avec
comme mention "métadonnée capture date"
et est visible par exemple avec la couche Bing
oui je sais c'est triste comme exemple :)

Mais si quelqu'un est motivée pour coder l'injection des infos
dans les headers du proxy BDOrtho osm-fr, c'est techniquement possible
et un coup de main n'est jamais refusé :)
sinon c'est sur ma longue liste de chose à faire... et pas la moindre
idée de ce que cela va impliquer en boulot (j'ai pas encore regardé
la source de l'umap de Christian)
___
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

[Talk-us] New MapRoulette challenges

[Horea Meleg]

Hi everyone!
First, a big thank you for all contributors who worked on existing MapRoulette 
Challenges.
Second, we prepared 5 more challenges like the others, but in different areas. 
You can find them here:

  *   Greenville, SC - http://maproulette.org/mr3/challenge/3085
  *   New Orleans, LA - http://maproulette.org/mr3/challenge/3086
  *   Albany, NY - http://maproulette.org/mr3/challenge/3088
  *   Dayton, OH - http://maproulette.org/mr3/challenge/3090
  *   Phoenix, AZ - http://maproulette.org/mr3/challenge/3093
There are also some old challenges that you can work on:

  *   Tulsa, OK - http://maproulette.org/mr3/challenge/3067
  *   Albuquerque, NM - http://maproulette.org/mr3/challenge/3066

All necessary information can be found in challenges description. Also, 
description contains GitHub tickets for all challenges.
We'd love any input and advice!
If you have any questions or comments, please let me/us know.
Thanks!


From: Horea Meleg
Sent: Thursday, June 21, 2018 2:29 PM
To: 'talk-US@openstreetmap.org' 
Subject: New MapRoulette challenges

Hi everyone!
First, a big thank you for all contributors who finished our first MapRoulette 
Challenges.
Second, as we promised, we prepared 4 more challenges like the others, but in 
different areas. You can find them here:

  *   Tulsa, Oklahoma http://maproulette.org/mr3/challenge/3067
  *   Tucson, Arizona http://maproulette.org/mr3/challenge/3068
  *   Albuquerque, New Mexico http://maproulette.org/mr3/challenge/3066
  *   El Paso, New Mexico http://maproulette.org/mr3/challenge/3065

All necessary information can be found in challenges description. Also, 
description contains GitHub tickets for both challenges.
We'd love any input and advice!
If you have any questions or comments, please let me/us know.
Thanks!



From: Horea Meleg
Sent: Friday, June 8, 2018 10:02 AM
To: talk-US@openstreetmap.org
Subject: New MapRoulette challenges


Hi everyone!

To make OpenStreetMap more navigable and accurate in guidance, Telenav mapping 
team is planning to process available open data and share it with the community 
using MapRoulette Challenges.

As a starting point we processed Tiger 2017 data, and we extracted ways which 
don't have name in OSM but there is an available name in Tiger. We made two 
challenges, for two different areas:

  *   Jacksonville, Florida 
http://maproulette.org/mr3/admin/project/271/challenge/3041
  *   San Antonio, Texas 
http://maproulette.org/mr3/admin/project/271/challenge/3042



All necessary information can be found in challenges description. Also, 
description contains GitHub tickets for both challenges.

We'd love any input and advice!

If you have any questions or comments, please let me/us know.

Thanks!

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

Re: [osm-ve] Solicitud de Apoyo para Formación aplicación OpenStreetMap

[Andrea R. Simancas Y.]

Estimado Hernán,

estoy poniendo en copia al José Alberto López quien es la persona que había
iniciado el contacto con Open Street Maps y que entiendo que por esa vía es
que Ud. nos escribe. Si nos pudiera dar un contacto telefónico para
llamarlo y conversar sobre el tema se lo agradecería.

Saludos cordiales,

Andrea


Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

El 24 de julio de 2018, 7:02, J. Hernán Ramírez R.  escribió:

>
> Saludos Alberto...
>
> En que plataforma lo deseas implementar.. He desarrollado algo en Python /
> GeoDjango / OpenLayer.  De hecho en GitHub Tengo un demo con Todos los
> estados, municipios y parroquias basados en lo que hemos hecho con OSM en
> Venezuela.
>
> Es cuestión de buscar los datos meteorológicos. Se de una tesis de una
> compañera de trabajo que hizo un tesis en la ULA (Ing. Forestal) y midió
> una temperaturas con diferencias de 5 grados en cada lado del aeropuerto y
> tengo una tesista que implementa el análisis estadístico de linea de tiempo
> en el Observatorio Nacional  de Llano del Hato.
>
> Para esto se requiere al menos un servidor con Nginx, una base de datos
> con PostGis y Python 3.6
>
> El trabajo es largo.. quizás se requiera al menos de 2 o tres
> programadores.
>
> Yo Estoy en Mérida.
>
>
>
> --
> Salva un árbol. No imprimas este correo a menos que sea realmente
> necesario.
>
> 
> -
> J. Hernán Ramírez R
> http://about.me/hernanramirez - Linux User #97.898
> 
> Mapas Libres OpenStreetmap Venezuela 
> 
> -
>
>
> On Mon, Jul 23, 2018 at 4:14 AM JOSE ALBERTO Lopez 
> wrote:
>
>> Estimado Sres. OpenStreetMap:
>>
>> Reciba un coordial de saludo del Comitato Internazionale per lo Sviluppo
>> dei Popoli CISP.
>>
>> Me permito escribirle ya que en  la actualidad el CISP está implementando
>> conjuntamente con la Universidad Nacional Experimental del Táchira UNET y 
>> Centro
>> Interamericano de Desarrollo para la Investigación Ambiental y Territorial 
>> CIDIAT,
>> el proyecto
>>
>> ANDES EN ACCIÓN CLIMÁTICA
>> *Gestión Ambiental con Enfoque en Mitigación y Adaptación al Cambio
>> Climático, para el Desarrollo Sostenible e Inclusivo en los Estados
>> Táchira, Mérida y Trujillo. con el financiamiento de la UE en Venezuela.*
>>
>> El proyecto en busca activar mecanismos de articulación
>> interinstitucional para la implementación de estrategias de mitigación y
>> adaptación al cambio climático en zonas urbanas y periurbanas de Táchira,
>> Mérida y Trujillo; y así contribuir a la generación y promoción de acciones
>> eficaces de gestión ambiental para el desarrollo sostenible e inclusivo en
>> dichos estados. A través de las actividades planteadas en el proyecto, se
>> espera lograr que universidades, OSC e instituciones locales cuenten con
>> herramientas para la generación de conocimiento, y con capacidades para la
>> medición de los efectos y potencialidades de la región andina frente al
>> cambio climático; y también que comunidades organizadas, OSC, autoridades
>> locales y empresas de la región, de forma participativa y articulada,pongan
>> en marcha acciones piloto de mitigación y adaptación al cambio climático.
>>
>> De esta manera, como parte del proyecto se generará una línea de base
>> sobre la situación y la afectación de la región andina a causa del cambio
>> climático, y sobre sus potencialidades para mitigar y adaptarse ante sus
>> efectos.Para ello se tiene previsto realizar diferentes estudios de línea
>> base, los cuales permitirán obtener resultados que podrán ser socializados
>> de manera didáctica con autoridades y comunidades, y que a su vez
>> impulsarán la implementación de estrategias efectivas y eficientes para la
>> adaptación y mitigación al cambio climático en la región.
>>
>> Estos estudios son
>>
>> 1. Análisis de Vulnerabilidades, Riesgo y Huella Urbana
>>
>> 2. Inventario de GEI
>>
>> 3. Potencialidades de Energía Alternativa.
>>
>> 4. Caracterización de los Residuos Sólidos
>>
>> Para ello tenemos previsto utilizar kobotoolbox para la gestión de la
>> información y de opeenstreetmap para georeferenciar las diferentes
>> variables generen y también poder usar drones para actualización
>> cartográfica.
>>
>> En este sentido, quisiéramos ver sí posible a través de la ONG
>> openstreetmap tener capacitaciones y asesorías sobre el tema de uso de la
>> aplicación y uso de drones para levantamiento de información cartográfica.
>>
>> De ante mano muchas gracias por la información que nos puedan dar al
>> respecto.
>>
>> Atentos saludos
>>
>> --
>>
>>
>>
>>
>> --

Re: [OSM-talk-fr] Instabilité des connexions à OSM.orgvec

[Rpnpif]

Le 16 août 2018, Philippe Verdy a écrit :
> Voyez-vous les mêmes difficultés ? (Note mon accès internet est la fibre de
> Free, je n'ai pas de problème de performance ou de perte de trame sur mes
> tests, sauf avec le services d'OSM.org)

Bonjour,

Oui j'ai eu aussi de fortes lenteurs du rendu hier soir avec des
timeout comme toi.

Avec Id, je n'ai pas vu de gros problèmes, par contre avec JOSM, j'ai
eu des sueurs froides avec une lenteur faisant partir JOSM en vrille
(avec grosse activité CPU) par contre je n'ai pas remarqué de dégâts
sur les données envoyées. Elles sont bien en place. J'avais
relativement peu de nœuds.
Mais il est probable qu'avec beaucoup de nœuds, cela aurait galéré.

-- 
Alain Rpnpif

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

Re: [OSM-talk] Arkhivna Street

[Oleksiy Muzalyev]

On 16.08.18 22:34, Andy Mabbett wrote:

"This street has over a half-dozen names, all at once."

https://www.atlasobscura.com/places/arkhivna-street

Mapped here, but without all those names:

https://www.openstreetmap.org/way/234767127


Hi Andy,

It may seem surprising to someone who lives in a place which has been 
politically and economically stable for quite a while. In lands where 
there are ongoing social and political changes streets are named, 
renamed, and renamed again. It is hard say to a taxi or ambulance driver 
to memorize street names per se in a large city.


But when they change two-three times during lifetime it is becoming 
quite a formidable task. To make things worse some people keep using in 
conversations the historic street-names, some just old names, and some 
the new ones. The case which you write about is an extreme one, 
probably, just an irony, since usually there is only one, the latest 
street-name plaque.


Nevertheless the system where an address is assigned by the unalterable 
law of nature, like the open source OLC [1], looks promising not only 
for regions where there are either no street-names, or no streets, but 
also for regions with unstable or substandard addresses. And not only 
because street-names change, but also because street names and house 
numbers signs are not lighted during dark hours, the signs are faded 
under the sun light, etc.


I listened recently to a talk "Who belongs in a city?" [2] by OluTimehin 
Adegbeye, which provides interesting insights of modern urbanism and 
makes more understandable the issues with street-names and addresses (or 
they absence) in general.


[1] https://en.wikipedia.org/wiki/Open_Location_Code

[2] https://www.ted.com/talks/olutimehin_adegbeye_who_belongs_in_a_city

Best regards,

Oleksiy


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