date:20180811

sent from a phone

> On 12. Aug 2018, at 01:40, Simon Poole  wrote:
> 
> People seem to be looking more for unique ids for their dwellings than 
> something that is dependent on a relatively fine grained location/coordinate 
> value, of which you may have multiple for one house. We know this works, it 
> is still a very common system in alpine regions in Europe.

It depends a lot on the details and setting, in Venice, to give an example with 
a dense urban setting, building entrances are numbered with 4digits, unique 
within their “sestiere” (literally not quarter but sixth), and it doesn’t work 
well for finding a place (unless you use a map which has all the numbers). For 
a quick impression:
https://www.openstreetmap.org/#map=18/45.44062/12.34087

Cheers,
Martin

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

Unfortunately reality is new mappers cut and paste buildings so you end up
with multiple buildings with the same address.  There are three other
problems, maintenance is the first.  How do you ensure that new buildings
get a code?  Second in many parts of Africa the same building gets mapped
more than once.  Usually the outline that closest fits the building is left
but that may not be the one with the address tag and finally how do you
prevent someone from changing the tags?  Vandalism is not unknown in OSM.

>From a practical point of view an encoded lat and long is a sort of basic
works anywhere solution.  Where there is better organisation for example in
the alpine regions of Europe then more traditional forms of an address are
to be preferred.

Cheerio John


On Sat, 11 Aug 2018, 7:40 pm Simon Poole,  wrote:

>
>
> Am 12.08.2018 um 01:27 schrieb john whelan:
>
> > Note my opposition, notwithstanding my general concerns about fiddling
> with the markets, is founded in that plus codes are just simply not very
> good/fit for purpose.
>
> And discounting using pure lat and long your solution would be?
>
> A pure numeric (because we know the phone numbers work) grid reference
> relative to a suitable administrative entity.
>
> BUT as this discussion shows, in the end you could simply number all
> buildings in a place and add those numbers to OSM (as the authoritative
> repository) and probably make everybody happier. People seem to be looking
> more for unique ids for their dwellings than something that is dependent on
> a relatively fine grained location/coordinate value, of which you may have
> multiple for one house. We know this works, it is still a very common
> system in alpine regions in Europe.
>
> Simon
>
>
> Thanks John
>
> On 11 August 2018 at 19:04, Simon Poole  wrote:
>
>>
>>
>> Am 11.08.2018 um 16:39 schrieb Richard Fairhurst:
>> >  is a good idea,
>> > apart from Simon, and even Homer nods sometimes.
>> >
>> >
>> Note my opposition, notwithstanding my general concerns about fiddling
>> with the markets, is founded in that plus codes are just simply not very
>> good/fit for purpose. But as everybody should know that isn't a
>> hindrance to being successful in the marketplace and so that aspect can
>> safely be ignored.
>>
>>
>> ___
>> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?



Am 12.08.2018 um 01:27 schrieb john whelan:
> > Note my opposition, notwithstanding my general concerns about
> fiddling with the markets, is founded in that plus codes are just
> simply not very good/fit for purpose.
>
> And discounting using pure lat and long your solution would be?
A pure numeric (because we know the phone numbers work) grid reference
relative to a suitable administrative entity.

BUT as this discussion shows, in the end you could simply number all
buildings in a place and add those numbers to OSM (as the authoritative
repository) and probably make everybody happier. People seem to be
looking more for unique ids for their dwellings than something that is
dependent on a relatively fine grained location/coordinate value, of
which you may have multiple for one house. We know this works, it is
still a very common system in alpine regions in Europe.

Simon

>
> Thanks John
>
> On 11 August 2018 at 19:04, Simon Poole  > wrote:
>
>
>
> Am 11.08.2018 um 16:39 schrieb Richard Fairhurst:
> >  is a good idea,
> > apart from Simon, and even Homer nods sometimes.
> >
> >
> Note my opposition, notwithstanding my general concerns about fiddling
> with the markets, is founded in that plus codes are just simply
> not very
> good/fit for purpose. But as everybody should know that isn't a
> hindrance to being successful in the marketplace and so that
> aspect can
> safely be ignored.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
>
>



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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

> Note my opposition, notwithstanding my general concerns about fiddling
with the markets, is founded in that plus codes are just simply not very
good/fit for purpose.

And discounting using pure lat and long your solution would be?

Thanks John

On 11 August 2018 at 19:04, Simon Poole  wrote:

>
>
> Am 11.08.2018 um 16:39 schrieb Richard Fairhurst:
> >  is a good idea,
> > apart from Simon, and even Homer nods sometimes.
> >
> >
> Note my opposition, notwithstanding my general concerns about fiddling
> with the markets, is founded in that plus codes are just simply not very
> good/fit for purpose. But as everybody should know that isn't a
> hindrance to being successful in the marketplace and so that aspect can
> safely be ignored.
>
>
> ___
> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?



Am 11.08.2018 um 16:39 schrieb Richard Fairhurst:
>  is a good idea,
> apart from Simon, and even Homer nods sometimes.
>
>
Note my opposition, notwithstanding my general concerns about fiddling
with the markets, is founded in that plus codes are just simply not very
good/fit for purpose. But as everybody should know that isn't a
hindrance to being successful in the marketplace and so that aspect can
safely be ignored.



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

Re: [OSM-talk] Generic Tasking Manager instances

The instance I ran for many years has been replaced by
http://tasks.osm.ch/ that I suspect will again be available for many
years to come  (note that the main problem in the past has been that
there was typically no way to migrate to newer version which led to
people being stuck on old, unmaintained stuff, that they eventually had
to turn off).

Simon

Am 11.08.2018 um 23:52 schrieb Michał Brzozowski:
> Hi all,
> from all the instances of OSM Tasking Manager, are there ones which
> - won't close in foreseeable future
> - won't mind hosting generic tasks (not related to specific cause/region)?
> So, in essence, kind of like MapCraft, but with all the benefits of TM
> - including, but not limited to, automatic grid generation and grid
> square splitting.
>
> Michał
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Generic Tasking Manager instances

2018-08-11 Thread Blake Girardot

Hi Michal,

The OSM-US has a pretty open and friendly OSM Tasking Manager install
for projects.

There is a form to fill out for project creation permissions:

https://docs.google.com/forms/d/e/1FAIpQLScho9oKNc_8OjAUdYxFtasRF6Qg3eyYoQF_jbka6Xk79nrvOw/viewform

Cheers,
Bake

On Sat, Aug 11, 2018 at 5:52 PM, Michał Brzozowski  wrote:
> Hi all,
> from all the instances of OSM Tasking Manager, are there ones which
> - won't close in foreseeable future
> - won't mind hosting generic tasks (not related to specific cause/region)?
> So, in essence, kind of like MapCraft, but with all the benefits of TM -
> including, but not limited to, automatic grid generation and grid square
> splitting.
>
> Michał
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot

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

[OSM-talk] Generic Tasking Manager instances

2018-08-11 Thread Michał Brzozowski

Hi all,
from all the instances of OSM Tasking Manager, are there ones which
- won't close in foreseeable future
- won't mind hosting generic tasks (not related to specific cause/region)?
So, in essence, kind of like MapCraft, but with all the benefits of TM -
including, but not limited to, automatic grid generation and grid square
splitting.

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

Re: [Talk-de] Datum einer Kontrolle vermerken?

sent from a phone

> On 11. Aug 2018, at 13:08, Andreas Meier  wrote:
> 
> Bei lastcheck:note =* habe ich im Moment Fragezeichen, ob das als
> unstrukturiertes Tag nötig und hilfreich wäre.

der note tag als Freeform tag um weitere Informationen unstrukturiert an 
folgende Mapper weiterzugeben, reicht aus m.E., diesen noch weiter zu 
fragmentieren bringt m.E. keinen Gewinn.

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

Re: [Talk-us] State Open Data

2018-08-11 Thread Clifford Snow

On Sat, Aug 11, 2018 at 12:01 PM Pine W  wrote:

> I'm interested in this subject. An issue is that the copyright might be
> owned by the government entity that created it, even if the records are
> open for the public. If something is public record in California, does that
> also mean that it's not copyrighted by the government entity that created
> it?
>
> Its my understanding that if the state government has an open data law
similar to the US, then when they release the data it's public domain.
There are exceptions. Sometime they license the data from a company without
have the rights to release it as PD. They also have exceptions for not
releasing data that has personal information. I sat through a talk by
WSDOT. One of the big issues they pressed was to be very careful be for
adding data to the state's open data portal. Once it's out in the open,
they can't get it back.


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-dk] Konstruktioner i vand

2018-08-11 Thread osm

Se her: https://en.wikipedia.org/wiki/Dolphin_(structure)

> Korrekt, det er ikke en breakwater og ej heller en estakade:
> http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand1.jpg

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

Re: [Talk-dk] Konstruktioner i vand

2018-08-11 Thread Troels Arvin

Hej,

Niels skrev bl.a.:
> Ja, men det er måske ikke rigtigt en breakwater.

Korrekt, det er ikke en breakwater og ej heller en estakade:
http://troels.arvin.dk/osm/evidence/sluse_vand-ting/vand1.jpg

Nu har jeg forsøgt mig med bl.a. barrier=cable_barrier +
seamark:type=cable_overhead dér hvor der ikke er træ.

Jeg vil prøve at se, om jeg kan opstøve en mailing liste, der har vand-
tagging som speciale og bede dem tage et kig, også.

-- 
Troels


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

Re: [Talk-us] State Open Data

2018-08-11 Thread Pine W

I'm interested in this subject. An issue is that the copyright might be
owned by the government entity that created it, even if the records are
open for the public. If something is public record in California, does that
also mean that it's not copyrighted by the government entity that created
it?

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Sat, Aug 11, 2018 at 5:55 PM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> In California, we are quite fortunate to have not only a great deal of
> open data, but an explicit (two, actually) state Supreme Court cases which
> unambiguously assert that data created by the state in the name of the
> People belong to, yup, We, the People.  In other words, if the data are
> public, created by a state agency, the data are "ours" to use as we see
> fit, including a hand-in-glove fit with OSM's ODbL.  The web's "initial
> entry point" can be considered https://data.ca.gov although there are
> MANY more online sources of such data which can be freely used.
>
> Please see:
>
> Government Code §11549.30 (the California Open Data Act),
>
> County of Santa Clara v. California First Amendment Coalition, 170 Cal.
> App. 4th 1301
>
> Sierra Club v. County of Orange, 57 Cal.4th 157 (2013) and
>
> California Public Records Act (Statutes of 1968, Chapter 1473; currently
> codified as California Government Code §§ 6250 through 6276.48)
>
> Hooray for open data, hooray for how it continues to improve OSM!
>
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Stijn Rombauts

 Hi,
A year or 2 ago I asked the same question and then no-one objected to ref and 
nat_ref without space and int_ref with a space.
Regards,
StijnRR

On Saturday, August 11, 2018, 2:38:33 PM GMT+2, Ruben 
 wrote:  

 Hi Frank,

On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
> Where can I see and read what is the correct spelling of the E and other road 
> network like A? Is there a space between the letter and number?
> The wiki pages 
> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and 
> https://en.wikipedia.org/wiki/International_E-road_network are not clear 
> about that...
> See the mapillary https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg 
> example: there are no spaces so should we adapt all those tags?

I believe our local refs are without space (so "A17", "R0", "N540"). Our 
signposting for international refs doesn't use a space either (E40), or 
sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
On their site[1], the Flemish Agency for Roads and Traffic (AWV) consistently 
uses no space for both local and E refs. So I'd be inclined to say it's without 
space.

> I see that most of int_ref is with space and ref and nat_ref without? But not 
> always...

A few years ago, a French mapper came along and mechanically edited int_refs in 
Belgium. I asked them to stop but their changes were never fully reverted, so 
there are still int_refs with a space in Belgium.
I think it would be safe to remove the spaces mechanically, as it would 
actually be reverting an earlier unauthorized mechanical edit. What do you 
think?

[1] https://wegenenverkeer.be/

Cheers,
Ruben

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

I think what is needed is an independent way to generate them from OSMand
and I think that is part of the missing puzzle.

Cheerio John

On 11 August 2018 at 11:30, Blake Girardot HOT/OSM <
blake.girar...@hotosm.org> wrote:

> On Sat, Aug 11, 2018 at 10:39 AM, Richard Fairhurst
>  wrote:
> > Blake Girardot wrote:
> >> Also: No one is getting paid for anything related to this at this
> >> point. I personally would like to see Google donate to the OSMF
> >> and let the OSMF grant it out to help OSM core and eco system
> >> tools implement OLC native in code as it should be.
> >
> > That's done. Tom has coded it. Months ago. It's 20 lines of code (plus
> > tests), which is a fraction of the bandwidth spent on this thread.
> >
> > https://github.com/tomhughes/openstreetmap-website/commit/
> 2e0a2c67caf64df732f1e14160d5ead96c73a656
> >
> > Everyone in this thread appears to think that what Tom has done - i.e.
> > implementing it in the osm.org client rather than in tags - is a good
> idea,
> > apart from Simon, and even Homer nods sometimes.
> >
> > Tom, understandably, doesn't want to push it live without consensus that
> > it's a good thing
> > (https://github.com/openstreetmap/openstreetmap-website/pull/1818#
> issuecomment-380695939).
> > I reckon this thread is consensus enough and I'm sure Simon can indulge
> us
> > on this one little thing if we promise to uncockup some editor presets in
> > return. :)
> >
> > Richard
> >
>
> Thank you Richard, I did come in late. Some of the really insulting
> comments on that github thread caught my eye and I didn't read back to
> understand the issue fully.
>
> As I said, we'll look at all of this and put a wiki page together.
>
> Getting that pull request merged would be a great first step in
> helping the folks who this matters to explore the use of plus codes.
>
> I see the goolge manager commented on it. And while he makes some
> suggestions, I would rather see exactly what the PR has now be merged
> and we can go from there.
>
> Cheers,
> blake
>
> ___
> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Blake Girardot HOT/OSM

On Sat, Aug 11, 2018 at 10:39 AM, Richard Fairhurst
 wrote:
> Blake Girardot wrote:
>> Also: No one is getting paid for anything related to this at this
>> point. I personally would like to see Google donate to the OSMF
>> and let the OSMF grant it out to help OSM core and eco system
>> tools implement OLC native in code as it should be.
>
> That's done. Tom has coded it. Months ago. It's 20 lines of code (plus
> tests), which is a fraction of the bandwidth spent on this thread.
>
> https://github.com/tomhughes/openstreetmap-website/commit/2e0a2c67caf64df732f1e14160d5ead96c73a656
>
> Everyone in this thread appears to think that what Tom has done - i.e.
> implementing it in the osm.org client rather than in tags - is a good idea,
> apart from Simon, and even Homer nods sometimes.
>
> Tom, understandably, doesn't want to push it live without consensus that
> it's a good thing
> (https://github.com/openstreetmap/openstreetmap-website/pull/1818#issuecomment-380695939).
> I reckon this thread is consensus enough and I'm sure Simon can indulge us
> on this one little thing if we promise to uncockup some editor presets in
> return. :)
>
> Richard
>

Thank you Richard, I did come in late. Some of the really insulting
comments on that github thread caught my eye and I didn't read back to
understand the issue fully.

As I said, we'll look at all of this and put a wiki page together.

Getting that pull request merged would be a great first step in
helping the folks who this matters to explore the use of plus codes.

I see the goolge manager commented on it. And while he makes some
suggestions, I would rather see exactly what the PR has now be merged
and we can go from there.

Cheers,
blake

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

2018-08-11 Thread David Crochet


Bonjour


Le 11/08/2018 à 16:31, lenny.libre a écrit :
quels attributs mettre entre les deux panneaux de fin pour traverser 
la route ?


réglementairement parlant « highway=footway ».

Il aurait fallu un feu tricolore et un passage peint ou indiqué en vert 
pour indiquer aux usagers qu'il y a une zone prévue pour les cyclistes.


De cette zone pour rejoindre l'autre zone, le cycliste descend de son 
vélo et devient donc piéton le temps de traversé la route.


Cordialement

--
David Crochet


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Richard Fairhurst

Blake Girardot wrote:
> Also: No one is getting paid for anything related to this at this
> point. I personally would like to see Google donate to the OSMF 
> and let the OSMF grant it out to help OSM core and eco system 
> tools implement OLC native in code as it should be.

That's done. Tom has coded it. Months ago. It's 20 lines of code (plus
tests), which is a fraction of the bandwidth spent on this thread.

https://github.com/tomhughes/openstreetmap-website/commit/2e0a2c67caf64df732f1e14160d5ead96c73a656

Everyone in this thread appears to think that what Tom has done - i.e.
implementing it in the osm.org client rather than in tags - is a good idea,
apart from Simon, and even Homer nods sometimes.

Tom, understandably, doesn't want to push it live without consensus that
it's a good thing
(https://github.com/openstreetmap/openstreetmap-website/pull/1818#issuecomment-380695939).
I reckon this thread is consensus enough and I'm sure Simon can indulge us
on this one little thing if we promise to uncockup some editor presets in
return. :)

Richard

--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

2018-08-11 Thread lenny.libre



Le 11/08/2018 à 10:37, osm.sanspourr...@spamgourmet.com a écrit :


Le 11/08/2018 à 10:03, lenny.libre - lenny.li...@orange.fr a écrit :

Je sais mettre les attributs pour un simple trottoir, mais là, il y a 
une relation "REV Muret-Grenade" faut-il la rediriger vers la route 
où y a-t-il des attributs qui disent descendre de vélo ? 

Oui :
highway=footway
footway=sidewalk
:-)

Ou effectivement tu fais descendre sur la route.

Je remarque le marquage au sol de vélos après le panneau de fin.
oui, ils sont dessinés à la limite physique de la piste (le panneau 
aurait dû y être aussi)
Dans le sens opposé il y a aussi un panneau, sans doute aussi de fin, 
donc n'est-ce pas juste pour signaler que la route a priorité ?
Oui, la piste continue de l'autre côte 
(https://www.openstreetmap.org/way/208584996#map=18/43.65404/1.37446) 
quels attributs mettre entre les deux panneaux de fin pour traverser la 
route ?
Je parle du panneau permanent fin de piste cyclable, pas de fin de 
voie verte (il y a un panneau temporaire fin de voie verte sur une 
autre image 
 
téléchargée par tes soins mais ça semble correspondre à une autre voie
il a été installé pendant les travaux du bout, il correspond à la fin de 
piste cyclable et du cheminement piéton - qui sont séparés et ne sont 
pas une voie verte, comme il est temporaire, je n'en avais pas parlé


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

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

2018-08-11 Thread Philippe Verdy

De plus  le graphe munin indique clairemetn qu'Orm n'est pas hors
production mais est en cours de rattrapage de son retard de base de
données, donc qu'il a été réactivé (même si pour l'instant il ne produit
pas encore de tuiles puisque sa base est en cours de rechargement et
resynchronisation (c'est très clair sur le graphe).

Le sam. 11 août 2018 à 16:01, Philippe Verdy  a écrit :

> Apparement les liens munin indiquent toujours que Orm est en prod, et
> aucun lien pour rhaegal. Ces liens ne sont peut-être pas encore à jour, et
> rhaegal est alors un nouveau serveur remplaçant orm (ce dont j'ai
> maintenant un doute vu que le graphe munion le mentionne **maintenant**
> comme 5e serveur en plus d'Orm (il n'y en avait encore que 4 quand je
> l'avais vérifié).
>
> J'avais justement pris la peine de vérifier les liens avant de poster, ce
> n'était pas des "suppositions". Je donne des pistes parce que le détail tu
> as oublié de le donner. Maintenant si tu as des infos plus "directes"...
>
>
> Le sam. 11 août 2018 à 11:31, marc marc  a
> écrit :
>
>> Tu fais des suppositions de suppositions qui au final se transforment
>> en errer, un exemple :
>>
>> Le 11. 08. 18 à 05:27, Philippe Verdy a écrit :
>> > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch",
>> > et "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>>
>> information de Tom Hughes (celui qui a les mains dans le cambouis
>> pour les serveurs osm.org) :
>>
>> orm n'est actuellement pas un serveur de rendu en production,
>> il a été retiré le 7 août suite à un autre soucis en cours
>> de résolution
>>
>> rhaegal est un serveur de rendu en production
>>
>> ces 2 infos sont aussi visible sur les graphes munin si tu avais
>> pris la peine de la peine de cliquer sur le lien donné avant
>> de dire que les infos venant de ceux qui FONT sont erronées
>> https://munin.openstreetmap.org/renderd-day.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: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

2018-08-11 Thread Philippe Verdy

Apparement les liens munin indiquent toujours que Orm est en prod, et aucun
lien pour rhaegal. Ces liens ne sont peut-être pas encore à jour, et
rhaegal est alors un nouveau serveur remplaçant orm (ce dont j'ai
maintenant un doute vu que le graphe munion le mentionne **maintenant**
comme 5e serveur en plus d'Orm (il n'y en avait encore que 4 quand je
l'avais vérifié).

J'avais justement pris la peine de vérifier les liens avant de poster, ce
n'était pas des "suppositions". Je donne des pistes parce que le détail tu
as oublié de le donner. Maintenant si tu as des infos plus "directes"...


Le sam. 11 août 2018 à 11:31, marc marc  a
écrit :

> Tu fais des suppositions de suppositions qui au final se transforment
> en errer, un exemple :
>
> Le 11. 08. 18 à 05:27, Philippe Verdy a écrit :
> > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch",
> > et "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>
> information de Tom Hughes (celui qui a les mains dans le cambouis
> pour les serveurs osm.org) :
>
> orm n'est actuellement pas un serveur de rendu en production,
> il a été retiré le 7 août suite à un autre soucis en cours
> de résolution
>
> rhaegal est un serveur de rendu en production
>
> ces 2 infos sont aussi visible sur les graphes munin si tu avais
> pris la peine de la peine de cliquer sur le lien donné avant
> de dire que les infos venant de ceux qui FONT sont erronées
> https://munin.openstreetmap.org/renderd-day.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: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Karel Adams

Thanks, Jo, you are looking on from a little distance, that is always 
helpful to get consensus...

I agree with your "the key to create such a blank is commonly known as 
the space bar" - which only confirms how subtle the English language 
really is. And that is precisely what makes me contest the "rule" cited 
by @Ruben (he/she is right in the citation, but I defy the rule) "on 
this list the accepted standard is to use English" - I never liked that 
rule, mostly for this reason. There's all too many people who post (to 
some degree) gibberish, in the firm belief they have good English.

And to come back to @Ruben's reply "no-one would have failed to 
understand what we meant": try taking this conversation though some www 
translation tool to an exotic language, say Japanese or Swahili or Latin 
or Basque, than back to English. Without having checked, I dare to bet 
that somewhere in the process the "space" was converted to something 
astronautical. So yes, I am sure many people might get confused. Or in 
other words, what's the added value of posting in a language that is NOT 
native to this Belgian country? Except of course to oblige those few who 
prefer learning foreign languages over learning their own.

Karel (admittedly touchy on matters of language and local culture)

On 11/08/18 13:31, Jo wrote:

Karel, you are probably right, but the key to create such a blank is 
commonly known as the space bar.

I would also remove the 'empty character' (Leerzeichen) here in Belgium.

In France it's consistently with a space, I guess they find it like 
that on their signage.

Jo

Op za 11 aug. 2018 om 15:11 schreef Karel Adams >:

Excuse me for being pecky on language - for this once I feel free
because language is (more or less) the subject matter anyway.

Where @jakka writes "space", and @ruben neatly follows suit, I
think the
actual meaning is "blank".

nl "spatie" => en "blank"

en "space" => nl "ruimte"

Not wanting to "score" any personal hits, just for the common good:
allow me to recommend that English should only be used by those who
master that subtle language really well. There is no reason for not
posting in one's native language, on a list of regional importance
such
as this.

Groeten :)

Karel

On 11/08/18 12:38, Ruben wrote:
> Hi Frank,
>
> On Fri, 10 Aug 2018 21:06:54 +0200, Jakka mailto:vdmfrank...@gmail.com>> wrote:
>> Where can I see and read what is the correct spelling of the E
and other road network like A? Is there a space between the letter
and number?
>> The wiki pages
https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network
and https://en.wikipedia.org/wiki/International_E-road_network are
not clear about that...
>> See the mapillary
https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg example:
there are no spaces so should we adapt all those tags?
> I believe our local refs are without space (so "A17", "R0",
"N540"). Our signposting for international refs doesn't use a
space either (E40), or sometimes a 'thin space' (E 40). I've never
seen a full space (E 40).
> On their site[1], the Flemish Agency for Roads and Traffic (AWV)
consistently uses no space for both local and E refs. So I'd be
inclined to say it's without space.
>
>> I see that most of int_ref is with space and ref and nat_ref
without? But not always...
> A few years ago, a French mapper came along and mechanically
edited int_refs in Belgium. I asked them to stop but their changes
were never fully reverted, so there are still int_refs with a
space in Belgium.
> I think it would be safe to remove the spaces mechanically, as
it would actually be reverting an earlier unauthorized mechanical
edit. What do you think?
>
> [1] https://wegenenverkeer.be/
>
> Cheers,
> Ruben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be

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

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

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

What do the users in Tanzania  require?  Do they have access to an android
smartphone?

If so what is wrong with using OSMand, its free.  Every building in
Tanzania has a visible OLC code and its permanent so no danger it will
disappear after the trial.

Cheerio John



On 11 August 2018 at 09:31, Blake Girardot  wrote:

> On Sat, Aug 11, 2018 at 5:49 AM, Frederik Ramm 
> wrote:
> > Hi,
> >
> > On 11.08.2018 11:21, mmd wrote:
> >> With all due respect, I think we've long crossed that point:
> >
> > All these have been added by accident, as a side effect of undiscussed
> > imports.
> >
> > This is bad, but not as bad as adding them on purpose in the course of
> > an ill-conceived aid project with the promise of lifting poor people out
> > of their not-having-an-address misery.
> >
> > Adding coordinates, or plus codes, as tags to OSM makes no sense.
> > Building an aid project around it and doing it on purpose is at best
> > negligent and at worst cynical. It is a waste of the money of whoever
> > funds the aid project, a waste of resources in OSM, and a waste of time
> > for those who do it. For OSM to allow this to happen would make us
> > complicit in that cynicism.
> >
> > Bye
> > Frederik
>
> Ok, lets us get back to reality please.
>
> All this huffing and puffing, dumbest idea ever in history, etc etc is
> typical and typically not helping.
>
> The situation is:
>
> A ngo on the ground in Tanzania does first responded type work, they
> see how helpful addresses are in other contexts, but the area they
> work does not have any.
>
> This OLC thing seems like it would be interesting to explore, it might
> solve some of their use cases.
>
> All of their tools and workflows can use osm tags, especially like the
> addr: tags.
>
> What if we had something like that, an osm tag that had basically an
> addr: value, just from OLC instead of however one normally gets an
> address. How would that work? Where could we display it? How could we
> look them up? etc etc
>
> So by doing a small test using a regular old osm tag, they can explore
> if it is useful, how it might help, etc etc. and every single OSM tool
> in existence at this moment knows how to deal with osm addr: tags or
> osm tags more generally. What a great starting point to see if this
> solves any of their use cases, some of which we probably could not
> really describe well anyway.
>
> Ya, I am going to try some tagging options so they can get a look at
> what is possible if the tools they used supported this in code as they
> should, of course.
>
> I was not involved with this at all before, but I am now and I am
> going to do what I do, which is do what I can to help people use OSM,
> in full accordance with OSM guidelines, which this totally is.
>
> OSM will not break, everything will be ok, but OSM is a folksonomy and
> this is folksonomy 101 here.
>
> So take some deep breaths.
>
> Some local OSM'ers are going to experiment very locally and carefully
> with how OLCs or an OLC-like thing might fit into their use cases and
> we are going to do it by using tags because that is what every OSM
> tool in existence right now understands and can use to various
> degrees.
>
> We'll make a wiki page, revert the import, we'll detail it in the wiki
> page and re do it on a better defined area, described in the wiki
> project page.
>
> Also: No one is getting paid for anything related to this at this
> point. I personally would like to see Google donate to the OSMF and
> let the OSMF grant it out to help OSM core and eco system tools
> implement OLC native in code as it should be. Let the OSMF decide how
> to best help get the functionality everyone says should "just exist"
> in the vast ecosphere of OSM tools. I also plan on following up on
> that idea regardless of this tag / no tag issue, which is a minor
> issue at best.
>
> Cheers
> blake
>
> ___
> 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-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Wouter Hamelinck

The ASCII standard RFC 20 describes character 32 as "Space (Normally
Non-Printing)". Nothing wrong with shortening that to "space" according to
me.
wouter

On Sat, Aug 11, 2018 at 3:11 PM Karel Adams  wrote:

> Excuse me for being pecky on language - for this once I feel free
> because language is (more or less) the subject matter anyway.
>
> Where @jakka writes "space", and @ruben neatly follows suit, I think the
> actual meaning is "blank".
>
> nl "spatie" => en "blank"
>
> en "space" => nl "ruimte"
>
> Not wanting to "score" any personal hits, just for the common good:
> allow me to recommend that English should only be used by those who
> master that subtle language really well. There is no reason for not
> posting in one's native language, on a list of regional importance such
> as this.
>
> Groeten :)
>
> Karel
>
>
> On 11/08/18 12:38, Ruben wrote:
> > Hi Frank,
> >
> > On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
> >> Where can I see and read what is the correct spelling of the E and
> other road network like A? Is there a space between the letter and number?
> >> The wiki pages
> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and
> https://en.wikipedia.org/wiki/International_E-road_network are not clear
> about that...
> >> See the mapillary
> https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg example: there
> are no spaces so should we adapt all those tags?
> > I believe our local refs are without space (so "A17", "R0", "N540"). Our
> signposting for international refs doesn't use a space either (E40), or
> sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
> > On their site[1], the Flemish Agency for Roads and Traffic (AWV)
> consistently uses no space for both local and E refs. So I'd be inclined to
> say it's without space.
> >
> >> I see that most of int_ref is with space and ref and nat_ref without?
> But not always...
> > A few years ago, a French mapper came along and mechanically edited
> int_refs in Belgium. I asked them to stop but their changes were never
> fully reverted, so there are still int_refs with a space in Belgium.
> > I think it would be safe to remove the spaces mechanically, as it would
> actually be reverting an earlier unauthorized mechanical edit. What do you
> think?
> >
> > [1] https://wegenenverkeer.be/
> >
> > Cheers,
> > Ruben
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
"Den som ikke tror på seg selv kommer ingen vei."
   - Thor Heyerdahl
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Ruben

On Sat, 11 Aug 2018 15:30:26 +0200, Ruben  wrote:
> "Space" in English has well over 20 distinct meanings. One of them is
>  • according to Wiktionary[1]: "(letterpress typography) A piece of metal 
> type used to separate words, cast lower than other type so as not to take 
> ink, especially one that is narrower than one en (compare quad). [from 
> 17thc.]".
>  • according to OED[2]:  "In a text: an interval or blank between words, 
> lines, etc.; (Typography) any of several intervals or blanks of varying 
> widths used to separate words, justify lines, etc. Now also (in an electronic 
> or typewritten text): an interval or blank equivalent to one character, which 
> may be produced by pressing a specific key (cf. space bar n.)."

This is not to say that it was necessarily the best word, but that no-one would 
have failed to understand what we meant.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Blake Girardot

On Sat, Aug 11, 2018 at 5:49 AM, Frederik Ramm  wrote:
> Hi,
>
> On 11.08.2018 11:21, mmd wrote:
>> With all due respect, I think we've long crossed that point:
>
> All these have been added by accident, as a side effect of undiscussed
> imports.
>
> This is bad, but not as bad as adding them on purpose in the course of
> an ill-conceived aid project with the promise of lifting poor people out
> of their not-having-an-address misery.
>
> Adding coordinates, or plus codes, as tags to OSM makes no sense.
> Building an aid project around it and doing it on purpose is at best
> negligent and at worst cynical. It is a waste of the money of whoever
> funds the aid project, a waste of resources in OSM, and a waste of time
> for those who do it. For OSM to allow this to happen would make us
> complicit in that cynicism.
>
> Bye
> Frederik

Ok, lets us get back to reality please.

All this huffing and puffing, dumbest idea ever in history, etc etc is
typical and typically not helping.

The situation is:

A ngo on the ground in Tanzania does first responded type work, they
see how helpful addresses are in other contexts, but the area they
work does not have any.

This OLC thing seems like it would be interesting to explore, it might
solve some of their use cases.

All of their tools and workflows can use osm tags, especially like the
addr: tags.

What if we had something like that, an osm tag that had basically an
addr: value, just from OLC instead of however one normally gets an
address. How would that work? Where could we display it? How could we
look them up? etc etc

So by doing a small test using a regular old osm tag, they can explore
if it is useful, how it might help, etc etc. and every single OSM tool
in existence at this moment knows how to deal with osm addr: tags or
osm tags more generally. What a great starting point to see if this
solves any of their use cases, some of which we probably could not
really describe well anyway.

Ya, I am going to try some tagging options so they can get a look at
what is possible if the tools they used supported this in code as they
should, of course.

I was not involved with this at all before, but I am now and I am
going to do what I do, which is do what I can to help people use OSM,
in full accordance with OSM guidelines, which this totally is.

OSM will not break, everything will be ok, but OSM is a folksonomy and
this is folksonomy 101 here.

So take some deep breaths.

Some local OSM'ers are going to experiment very locally and carefully
with how OLCs or an OLC-like thing might fit into their use cases and
we are going to do it by using tags because that is what every OSM
tool in existence right now understands and can use to various
degrees.

We'll make a wiki page, revert the import, we'll detail it in the wiki
page and re do it on a better defined area, described in the wiki
project page.

Also: No one is getting paid for anything related to this at this
point. I personally would like to see Google donate to the OSMF and
let the OSMF grant it out to help OSM core and eco system tools
implement OLC native in code as it should be. Let the OSMF decide how
to best help get the functionality everyone says should "just exist"
in the vast ecosphere of OSM tools. I also plan on following up on
that idea regardless of this tag / no tag issue, which is a minor
issue at best.

Cheers
blake

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

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Jo

Karel, you are probably right, but the key to create such a blank is
commonly known as the space bar.

I would also remove the 'empty character' (Leerzeichen) here in Belgium.

In France it's consistently with a space, I guess they find it like that on
their signage.

Jo

Op za 11 aug. 2018 om 15:11 schreef Karel Adams :

> Excuse me for being pecky on language - for this once I feel free
> because language is (more or less) the subject matter anyway.
>
> Where @jakka writes "space", and @ruben neatly follows suit, I think the
> actual meaning is "blank".
>
> nl "spatie" => en "blank"
>
> en "space" => nl "ruimte"
>
> Not wanting to "score" any personal hits, just for the common good:
> allow me to recommend that English should only be used by those who
> master that subtle language really well. There is no reason for not
> posting in one's native language, on a list of regional importance such
> as this.
>
> Groeten :)
>
> Karel
>
>
> On 11/08/18 12:38, Ruben wrote:
> > Hi Frank,
> >
> > On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
> >> Where can I see and read what is the correct spelling of the E and
> other road network like A? Is there a space between the letter and number?
> >> The wiki pages
> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and
> https://en.wikipedia.org/wiki/International_E-road_network are not clear
> about that...
> >> See the mapillary
> https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg example: there
> are no spaces so should we adapt all those tags?
> > I believe our local refs are without space (so "A17", "R0", "N540"). Our
> signposting for international refs doesn't use a space either (E40), or
> sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
> > On their site[1], the Flemish Agency for Roads and Traffic (AWV)
> consistently uses no space for both local and E refs. So I'd be inclined to
> say it's without space.
> >
> >> I see that most of int_ref is with space and ref and nat_ref without?
> But not always...
> > A few years ago, a French mapper came along and mechanically edited
> int_refs in Belgium. I asked them to stop but their changes were never
> fully reverted, so there are still int_refs with a space in Belgium.
> > I think it would be safe to remove the spaces mechanically, as it would
> actually be reverting an earlier unauthorized mechanical edit. What do you
> think?
> >
> > [1] https://wegenenverkeer.be/
> >
> > Cheers,
> > Ruben
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Ruben

On Sat, 11 Aug 2018 13:11:07 +, Karel Adams  wrote:
> Excuse me for being pecky on language - for this once I feel free 
> because language is (more or less) the subject matter anyway.

It's not – typography of road references is. Typography is distinct from 
language in general.

> Where @jakka writes "space", and @ruben neatly follows suit, I think the 
> actual meaning is "blank".
> 
> nl "spatie" => en "blank"
> 
> en "space" => nl "ruimte"

"Space" in English has well over 20 distinct meanings. One of them is
 • according to Wiktionary[1]: "(letterpress typography) A piece of metal type 
used to separate words, cast lower than other type so as not to take ink, 
especially one that is narrower than one en (compare quad). [from 17thc.]".
 • according to OED[2]:  "In a text: an interval or blank between words, lines, 
etc.; (Typography) any of several intervals or blanks of varying widths used to 
separate words, justify lines, etc. Now also (in an electronic or typewritten 
text): an interval or blank equivalent to one character, which may be produced 
by pressing a specific key (cf. space bar n.)."

> Not wanting to "score" any personal hits, just for the common good: 
> allow me to recommend that English should only be used by those who 
> master that subtle language really well.

What the fuck?

> There is no reason for not 
> posting in one's native language, on a list of regional importance such 
> as this.

There is: on this list the accepted standard is to use English, as a compromise 
between Dutch, French and German.

[1] https://en.wiktionary.org/wiki/space#Noun item 3.4
[2] 
http://www.oed.com/view/Entry/185414?rskey=BIiqG4=1=false#eid21540226

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

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Karel Adams

Excuse me for being pecky on language - for this once I feel free
because language is (more or less) the subject matter anyway.

Where @jakka writes "space", and @ruben neatly follows suit, I think the
actual meaning is "blank".

nl "spatie" => en "blank"

en "space" => nl "ruimte"

Not wanting to "score" any personal hits, just for the common good:
allow me to recommend that English should only be used by those who
master that subtle language really well. There is no reason for not
posting in one's native language, on a list of regional importance such
as this.

Groeten :)

Karel

On 11/08/18 12:38, Ruben wrote:

Hi Frank,

On Fri, 10 Aug 2018 21:06:54 +0200, Jakka wrote:

Where can I see and read what is the correct spelling of the E and other road
network like A? Is there a space between the letter and number?
The wiki pages
https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and
https://en.wikipedia.org/wiki/International_E-road_network are not clear about
that...
See the mapillary https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg
example: there are no spaces so should we adapt all those tags?

I believe our local refs are without space (so "A17", "R0", "N540"). Our
signposting for international refs doesn't use a space either (E40), or sometimes a 'thin space' (E 40). I've
never seen a full space (E 40).
On their site[1], the Flemish Agency for Roads and Traffic (AWV) consistently
uses no space for both local and E refs. So I'd be inclined to say it's without
space.

I see that most of int_ref is with space and ref and nat_ref without? But not
always...

A few years ago, a French mapper came along and mechanically edited int_refs in
Belgium. I asked them to stop but their changes were never fully reverted, so
there are still int_refs with a space in Belgium.
I think it would be safe to remove the spaces mechanically, as it would
actually be reverting an earlier unauthorized mechanical edit. What do you
think?

[1] https://wegenenverkeer.be/

Cheers,
Ruben

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

Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

2018-08-11 Thread Ruben

Hi Frank,

On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
> Where can I see and read what is the correct spelling of the E and other road 
> network like A? Is there a space between the letter and number?
> The wiki pages 
> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and 
> https://en.wikipedia.org/wiki/International_E-road_network are not clear 
> about that...
> See the mapillary https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg 
> example: there are no spaces so should we adapt all those tags?

I believe our local refs are without space (so "A17", "R0", "N540"). Our 
signposting for international refs doesn't use a space either (E40), or 
sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
On their site[1], the Flemish Agency for Roads and Traffic (AWV) consistently 
uses no space for both local and E refs. So I'd be inclined to say it's without 
space.

> I see that most of int_ref is with space and ref and nat_ref without? But not 
> always...

A few years ago, a French mapper came along and mechanically edited int_refs in 
Belgium. I asked them to stop but their changes were never fully reverted, so 
there are still int_refs with a space in Belgium.
I think it would be safe to remove the spaces mechanically, as it would 
actually be reverting an earlier unauthorized mechanical edit. What do you 
think?

[1] https://wegenenverkeer.be/

Cheers,
Ruben

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

Re: [Talk-it] OpenData Puglia

2018-08-11 Thread Francesco Piero Paolicelli

ciao ma in particolare ti interessa tutta la puglia o alcuni luoghi o
argomenti in particolare?
Ci sono molti cataloghi opendata comunali che potrebbero avere quello che
cerchi a partire da Lecce, Francavilla Fontana, Galatone, Terlizzi.
cià

Il giorno 11 agosto 2018 12:52, Mzzntn  ha scritto:

> Ciao ho appena ritrovato ed riletto la conversazione, ne deduco che
> essendoci
> degli errori nei dataset, è meglio importarli a mano avendo Umap come
> supporto, quindi come non detto ;)
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> 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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

2018-08-11 Thread Lester Caine


On 11/08/18 07:02, Andrew Harvey wrote:
 > No, all highways are areas :) Mapping them as a line is a manual 
generalization ;)


Yes, but you're mapping the road centerline, which isn't a 
generalization but a real world feature.


Mapping the path of a highway as a 'way' is a generalization. This can 
be extended by adding additional tags to describe all the fine detail 
such as width, number of lanes, associated cycle and footpaths, and so 
on, but this is a simplification to the actual fine detail. I'll repeat 
what I said, 'highway' SHOULD only be attached to a way and not to areas 
so that we have the simplification for lower resolutions of the data. 
ADDING areas to map the fine detail that is associated with the 
information also contained in the additional tags should be tagged by 
association and not by adding additional 'highway' tags to the areas. IN 
THAT CASE area=yes could be used to identify that there are associated 
area objects that can be used on higher resolution mapping. I don't 
think 'area:highway=' has place especially where the 'centerline' way is 
used to combine several highway=xxx types such as road,cycleway and 
footpath ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-de] Datum einer Kontrolle vermerken?

2018-08-11 Thread Andreas Meier

Der Stammtisch Bochum würde mir offenbar gefallen :-)

Einen entsprechenden Kommentar im Changeset für dann ein Objekt fände ich
aus Modellierungsaspekten nicht logisch: die Information eines
Verifikationsdatums ist m.E. eine Information, die an das Objekt gehört,
weil sie als Metadaten die Qualität der Objektdaten beschreibt. Einen
Changeset-Kommentar dafür zu benutzen wäre m.E. ein klassischer
Modellierungsfehler, weil ein Changeset ein ganz anderer Objekttyp ist als
jegliche Geodaten. Das würde dauerhaft die Schönheit des Datenbankdesigns
beeinträchtigen.

 

Die Ebene, auf der das Verifikationsdatum angebracht werden sollte, finde
ich uneindeutiger. Ich verstehe den Nutzen, ein Verifikationsdatums pro Tag
zu haben. Gleichzeitig halte ich das Modell für zu-komplex-für-diese-Welt
und den Aufwand der Pflege für wahrscheinlich unverhältnismäßig für den
Nutzen der Differenzierbarkeit. Ein Datum pro Objekt (statt pro Tag) sollte
viele Fälle abdecken und das würden wohl viel mehr Mapper viel besser
konsistent durchhalten, als wenn jeder auf Tag-Ebene noch viel mehr tippen
müsste. Ich verstehe das als eine Abwägung, die für Briefkästen und
Defibrillatoren funktioniert, aber vielleicht nicht so gut für Geschäfte
(Öffnungszeiten oder vielleicht Telefonnummer überprüft?).

 

Wäre dafür nicht das Prinzip der Namensräume ein Ausweg? Z.B.

lastcheck = *   -> gilt für das ganze Objekt

lastcheck:opening_hours = *  -> spezifisch

Man könnte einfach arbeiten wo immer das reicht und nur auf eigenen Wunsch
komplexer werden. Trotzdem wäre eine generelle Auswertbarkeit möglich und
ein Editor könnte theoretisch zeigen

Grün = kürzlicher Check

Gelb = kürzlicher Check auf ein beliebiges Einzel-Tag

Rot = kein kürzlicher Check

 

Bei lastcheck:note =* habe ich im Moment Fragezeichen, ob das als
unstrukturiertes Tag nötig und hilfreich wäre. Das Beispiel soll keine
persönliche Präferenz für lastcheck bedeuten, aber es ist zumindest
sprechend und etwas kürzer als last_checked :-).

 

Den Vorschlag, durch den Stammtisch einen Wiki-Eintrag auf Basis z.B. des
bisher am häufigsten verwendeten Tags zu entwickeln fände ich
vielversprechend.

 

Gruß

Andreas

 

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Mike N


On 8/11/2018 1:35 AM, Oleksiy Muzalyev wrote:
And they will not start putting up signs of the Plus-Codes outside their 
house unless the OpenStreetMap community accept this technology.


   What would actually happen in these locations?  Do they bring up the 
web site https://www.openstreetmap.org and use that?


This 
was a minor experimental import for a small remote town Zeze in the 
United Republic of Tanzania. Nothing happened.


   I see that it has been reverted, but what happened in the 3 months 
since the data was placed there.   Was there a plan to use and evaluate 
the system?


  The community generally seems open to the idea of adding them to 
tools and apps that end users use, although not yet for certain on the 
main OSM web site which has the purpose of mapping assistance.


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

Re: [Talk-it] OpenData Puglia

2018-08-11 Thread Mzzntn

Ciao ho appena ritrovato ed riletto la conversazione, ne deduco che essendoci
degli errori nei dataset, è meglio importarli a mano avendo Umap come
supporto, quindi come non detto ;)



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] OpenData Puglia

2018-08-11 Thread Federico Cortese

Ora non ho modo di trovare le precedenti discussioni perchè sono proprio su
una spiaggia salentina, ma si è già parlato in lista degli opendata Puglia.
In particolare ho fatto una dettagliata analisi del dataset degli
stabilimenti riscontrando discordanze chilometriche rispetto alla realtà.
Ad ogni modo se cerchi nello storico della mailing list troverai la
discussione cui accenno, altrimenti te la linkerò più tardi.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread mmd

Am 11.08.2018 um 12:18 schrieb Christoph Hormann:
> I hope you are aware that you are defending a bad tagging idea with the 
> existence of other bad tagging ideas.

The intention was actually quite the opposite. It was more a question of
taking a step back and revisiting those tags where coordinate values
already slipped in in the past where they shouldn't have.

A bit more consistency would also help arguing why we usually don't do
coordinates in tag values.

-- 



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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Andrew Errington

Yes indeed, otherwise I wouldn't have recorded them.

I'd be happy to hear a better solution for survey points. The naive
approach is to assume that the latitude and longitude of the point in OSM
is the surveyed value, which it should be, but without external
corroboration you can't be sure.

Anyway, my point was it is sometimes appropriate to record explicitly the
latitude and longitude of a point, even though it's redundant. In fact in
that case redundancy is good.

In this general discussion concerning Open Location Code, tagging the
database objects with the OLC is dumb. As soon as someone moves the object
the OLC is wrong. To fix that we could re-tag the object with a new OLC, or
move it back to the place dictated by the OLC. Obviously, we don't want to
move it back (it was moved for a reason), so we could generate a new OLC
tag (from the object's lat/lon), but it's pointless storing that as it can
be easily and trivially calculated on the fly.

Andrew

On Sat, Aug 11, 2018, 22:23 Andrew Hain  wrote:

> Do you know whether the latitude and longitude on the plaque are in the
> WGS84 that we use?
> --
> *From:* Andrew Errington 
> *Sent:* 11 August 2018 10:56
> *To:* mmd
> *Cc:* Talk Openstreetmap
> *Subject:* Re: [OSM-talk] Is it technically and legally possible to add
> the Open Location Code to the OSM search?
>
> I tag survey points with latitude and longitude (taken from the plaque on
> the survey marker). Then it is possible to see if they have been moved
> accidentally, and for users to check that they are actually in the surveyed
> location.
>
> Andrew
>
> On Sat, Aug 11, 2018, 21:24 mmd  wrote:
>
> Am 10.08.2018 um 19:46 schrieb Christoph Hormann:
> > The idea of tagging encoded coordinates is so ridiculous to anyone with
> > a bit of understanding of computer programming, data processing and
> > data maintainance that even after ignoring all the arguments in
> > substance that have been voiced this should be universally rejected if
> > for no other reason then because it would make OSM the laughing stock
> > of the whole geodata world.
>
> With all due respect, I think we've long crossed that point:
>
> https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
> https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
> https://taginfo.openstreetmap.org/keys/gns%3ALAT
> https://taginfo.openstreetmap.org/keys/latitude
>
> --
>
>
>
> ___
> 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: [Talk-it] OpenData Puglia

2018-08-11 Thread Andrea Musuruane

Ciao,


2018-08-11 12:27 GMT+02:00 Mzzntn :

> Buongiorno a tutti, dopo aver scoperto (http://www.dataset.puglia.it/)
> avevo
> intenzione di cominciare ad inserire alcuni dei dataset su OSM, pensavo di
> cominciare dagli stabilimenti balneari
> (http://www.dataset.puglia.it/dataset/elenco-stabilimenti-
> balneari/resource/b341fc4c-37a2-428b-88a4-ca39d5e5a270)
> non avendo mai fatto un operazione del genere, chiedo a voi se c'è qualche
> accortezza in particolare da seguire o basta attenersi alla wiki.
>

Devi seguire le import guidelines:
https://wiki.openstreetmap.org/wiki/Import/Guidelines

Ciao,

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

[Talk-it] OpenData Puglia

2018-08-11 Thread Mzzntn

Buongiorno a tutti, dopo aver scoperto (http://www.dataset.puglia.it/) avevo
intenzione di cominciare ad inserire alcuni dei dataset su OSM, pensavo di
cominciare dagli stabilimenti balneari
(http://www.dataset.puglia.it/dataset/elenco-stabilimenti-balneari/resource/b341fc4c-37a2-428b-88a4-ca39d5e5a270)
non avendo mai fatto un operazione del genere, chiedo a voi se c'è qualche
accortezza in particolare da seguire o basta attenersi alla wiki.
Per cominciare qui c'è la mappa di tutti gli stabilimenti
(https://umap.openstreetmap.fr/en/map/stabilimenti-balneari-puglia-2017_239792#9/41.4571/16.4397).

Prima di addentrarmi nel progetto e fare qualsiasi modifica attenderò
massaggi di conferma/supporto da mappatori piu esperti nell'import dati.
 
Antonio



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Andrew Hain

Do you know whether the latitude and longitude on the plaque are in the WGS84 
that we use?

From: Andrew Errington 
Sent: 11 August 2018 10:56
To: mmd
Cc: Talk Openstreetmap
Subject: Re: [OSM-talk] Is it technically and legally possible to add the Open 
Location Code to the OSM search?

I tag survey points with latitude and longitude (taken from the plaque on the 
survey marker). Then it is possible to see if they have been moved 
accidentally, and for users to check that they are actually in the surveyed 
location.

Andrew

On Sat, Aug 11, 2018, 21:24 mmd mailto:mmd@gmail.com>> 
wrote:
Am 10.08.2018 um 19:46 schrieb Christoph Hormann:
> The idea of tagging encoded coordinates is so ridiculous to anyone with
> a bit of understanding of computer programming, data processing and
> data maintainance that even after ignoring all the arguments in
> substance that have been voiced this should be universally rejected if
> for no other reason then because it would make OSM the laughing stock
> of the whole geodata world.

With all due respect, I think we've long crossed that point:

https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
https://taginfo.openstreetmap.org/keys/gns%3ALAT
https://taginfo.openstreetmap.org/keys/latitude

--

___
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] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Christoph Hormann

On Saturday 11 August 2018, mmd wrote:
>
> With all due respect, I think we've long crossed that point:
>
> https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
> https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
> https://taginfo.openstreetmap.org/keys/gns%3ALAT
> https://taginfo.openstreetmap.org/keys/latitude

I hope you are aware that you are defending a bad tagging idea with the 
existence of other bad tagging ideas.

While pointless tags added by imports are an unnecessary burden to data 
maintainance and bad for the reputation of OSM since they demonstrate a 
lack of quality control for imports in OSM they are not even remotely 
as damaging as would be the deliberate large scale addition of encoded 
coordinates as tags to millions of features.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

2018-08-11 Thread Jérôme Seigneuret

En fait chaque passage piéton sans matérialisation pour les vélos et déjà
une rupture de fait.

Le sam. 11 août 2018 10:38,  a écrit :

> Le 11/08/2018 à 10:03, lenny.libre - lenny.li...@orange.fr a écrit :
>
> Je sais mettre les attributs pour un simple trottoir, mais là, il y a une
> relation "REV Muret-Grenade" faut-il la rediriger vers la route où y a-t-il
> des attributs qui disent descendre de vélo ?
>
> Oui :
> highway=footway
> footway=sidewalk
> :-)
>
> Ou effectivement tu fais descendre sur la route.
>
> Je remarque le marquage au sol de vélos après le panneau de fin.
> Dans le sens opposé il y a aussi un panneau, sans doute aussi de fin, donc
> n'est-ce pas juste pour signaler que la route a priorité ?
> Je parle du panneau permanent fin de piste cyclable, pas de fin de voie
> verte (il y a un panneau temporaire fin de voie verte sur une autre image
> 
> téléchargée par tes soins mais ça semble correspondre à une autre voie).
>
> Jean-Yvon
> ___
> 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] résumés des problèmes majeurs du rendu osm-fr et osm.org

2018-08-11 Thread Jérôme Seigneuret

Ok merci pour toutes ces clarifications. C'est un super compte rendu. Au
moins je comprends mieux ces histoires de délais de mise à jour de
tuiles... De mon côté c'est Scorch qui déconne. Bon week-end

Le sam. 11 août 2018 11:30, marc marc  a écrit :

> Tu fais des suppositions de suppositions qui au final se transforment
> en errer, un exemple :
>
> Le 11. 08. 18 à 05:27, Philippe Verdy a écrit :
> > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch",
> > et "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>
> information de Tom Hughes (celui qui a les mains dans le cambouis
> pour les serveurs osm.org) :
>
> orm n'est actuellement pas un serveur de rendu en production,
> il a été retiré le 7 août suite à un autre soucis en cours
> de résolution
>
> rhaegal est un serveur de rendu en production
>
> ces 2 infos sont aussi visible sur les graphes munin si tu avais
> pris la peine de la peine de cliquer sur le lien donné avant
> de dire que les infos venant de ceux qui FONT sont erronées
> https://munin.openstreetmap.org/renderd-day.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: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Andrew Errington

I tag survey points with latitude and longitude (taken from the plaque on
the survey marker). Then it is possible to see if they have been moved
accidentally, and for users to check that they are actually in the surveyed
location.

Andrew

On Sat, Aug 11, 2018, 21:24 mmd  wrote:

> Am 10.08.2018 um 19:46 schrieb Christoph Hormann:
> > The idea of tagging encoded coordinates is so ridiculous to anyone with
> > a bit of understanding of computer programming, data processing and
> > data maintainance that even after ignoring all the arguments in
> > substance that have been voiced this should be universally rejected if
> > for no other reason then because it would make OSM the laughing stock
> > of the whole geodata world.
>
> With all due respect, I think we've long crossed that point:
>
> https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
> https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
> https://taginfo.openstreetmap.org/keys/gns%3ALAT
> https://taginfo.openstreetmap.org/keys/latitude
>
> --
>
>
>
> ___
> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Frederik Ramm

Hi,

On 11.08.2018 11:21, mmd wrote:
> With all due respect, I think we've long crossed that point:

All these have been added by accident, as a side effect of undiscussed
imports.

This is bad, but not as bad as adding them on purpose in the course of
an ill-conceived aid project with the promise of lifting poor people out
of their not-having-an-address misery.

Adding coordinates, or plus codes, as tags to OSM makes no sense.
Building an aid project around it and doing it on purpose is at best
negligent and at worst cynical. It is a waste of the money of whoever
funds the aid project, a waste of resources in OSM, and a waste of time
for those who do it. For OSM to allow this to happen would make us
complicit in that cynicism.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Jo

Op za 11 aug. 2018 om 11:24 schreef mmd :

>
> With all due respect, I think we've long crossed that point:
>
> https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
> https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
> https://taginfo.openstreetmap.org/keys/gns%3ALAT
> https://taginfo.openstreetmap.org/keys/latitude
>
> If you look at the distribution on the map for the first 3, they are all
in 'clusters'. It shouldn't be too hard to remove them, but given that it
would require going through the hassle of requesting permission, I don't
see who would care enough to do that.

It would be easier to simply add them to JOSM's  list of keys it will
discard upon upload.

Polyglot.

PS: Roland, would it make sense to add a possibility to the Overpass API to
'generate' these "addresses"'on-the-fly?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

2018-08-11 Thread marc marc

Tu fais des suppositions de suppositions qui au final se transforment
en errer, un exemple :

Le 11. 08. 18 à 05:27, Philippe Verdy a écrit :
> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", 
> et "orm" (et non pas "rhaegal" ou c'est un ancien alias).

information de Tom Hughes (celui qui a les mains dans le cambouis
pour les serveurs osm.org) :

orm n'est actuellement pas un serveur de rendu en production,
il a été retiré le 7 août suite à un autre soucis en cours
de résolution

rhaegal est un serveur de rendu en production

ces 2 infos sont aussi visible sur les graphes munin si tu avais
pris la peine de la peine de cliquer sur le lien donné avant
de dire que les infos venant de ceux qui FONT sont erronées
https://munin.openstreetmap.org/renderd-day.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread mmd

Am 10.08.2018 um 19:46 schrieb Christoph Hormann:
> The idea of tagging encoded coordinates is so ridiculous to anyone with 
> a bit of understanding of computer programming, data processing and 
> data maintainance that even after ignoring all the arguments in 
> substance that have been voiced this should be universally rejected if 
> for no other reason then because it would make OSM the laughing stock 
> of the whole geodata world.

With all due respect, I think we've long crossed that point:

https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
https://taginfo.openstreetmap.org/keys/gns%3ALAT
https://taginfo.openstreetmap.org/keys/latitude

-- 



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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

The argument against the goog is that they have a monopolies in certain
markets and are using those to extend in to others, I doubt that you
could make a case against third parties supporting what then becomes the
monopoly system, but who knows.


I've actually legally been in that situation during the first browser
wars and there was never an indication that organisations that signed
contracts that were later ruled illegal would be considered liable for
that, in the end they didn't really have a choice.


SImon


Am 11.08.2018 um 10:48 schrieb Andrew Hain:
> If they did sue, could Nomination, Osmand or OSM be liable if we
> implement it?
>
> --
> Andrew
> 
> *From:* Simon Poole 
> *Sent:* 11 August 2018 09:43
> *To:* Blake Girardot
> *Cc:* OpenStreetMap
> *Subject:* Re: [OSM-talk] Is it technically and legally possible to
> add the Open Location Code to the OSM search?
>  
>
>
> Am 10.08.2018 um 23:25 schrieb Blake Girardot:
> > Is that not the reason OSM was started in the first place?   :)
>
> It is slightly different in more than one way for a monopoly owner to
> pre-emptively create and promote a free system  to stop a competitor
> from gaining a foothold in a potential new market (and the goog is
> obviously spending a fair bit of small change on the whole thing). I
> suspect suing the goog is plan b for the w3w investors if they are not
> successful with the company as such. 
>
>



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

Re: [Talk-de] Datum einer Kontrolle vermerken?

2018-08-11 Thread Markus

Hallo Gisbert,

prima Ergänzung vom:
> Stamtisch in Bochum 
:-)

> zur Zeit gibt es viele verschiedene Tags.

Am Besten wäre es, diese Q-Tags im Wiki genau zu beschreiben/definieren:
Nur genau definierte tags sind hilfreich.
(sonst bekommt am die gleichen Konflikte und Endlosdiskussionen, wie wir
sie auch bei anderen nicht-definierten tags oft haben)

> Variationen für den Typ der Überprüfung 

Ja, das gehört in die Definition.
Damit man weiss, welcher tag überprüft wurde und mit welcher Quelle,
und welcher tag /nicht/ überprüft wurde.

Und natürlich wäre es sinnlos, nicht definierte Meta- bzw. Q-tags mit
mit allen Objekt-tags zu kombinieren. Damit bekäme man nur eine riesige
Menge nichtssagender Pseudo-Daten

Entwerft doch auf dem Stammtisch einfach mal ein pfiffiges und
konsistentes neues System.

Vermutlich macht es dann Sinn, für die Umsetzung des neuen Systems die
derzeit am häufigsten verwendeten und noch unspezifischen Q-tags zu
verwenden, diese im Wiki entsprechend dem neuen System genau zu
definieren und in die wichtigsten Sprachen zu übersetzen(!), und sie
dann natürlich auch in die Editoren aufzunehmen.

Dann wird sich das Schema automatisch verbreiten :-)

> ein Tag, welches dann in den Editoren angeboten wird

:-)

Gruss, Markus

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Andrew Hain

If they did sue, could Nomination, Osmand or OSM be liable if we implement it?

--
Andrew

From: Simon Poole 
Sent: 11 August 2018 09:43
To: Blake Girardot
Cc: OpenStreetMap
Subject: Re: [OSM-talk] Is it technically and legally possible to add the Open 
Location Code to the OSM search?

Am 10.08.2018 um 23:25 schrieb Blake Girardot:
> Is that not the reason OSM was started in the first place?   :)

It is slightly different in more than one way for a monopoly owner to
pre-emptively create and promote a free system  to stop a competitor
from gaining a foothold in a potential new market (and the goog is
obviously spending a fair bit of small change on the whole thing). I
suspect suing the goog is plan b for the w3w investors if they are not
successful with the company as such.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?



Am 10.08.2018 um 23:25 schrieb Blake Girardot:
> Is that not the reason OSM was started in the first place?   :)

It is slightly different in more than one way for a monopoly owner to
pre-emptively create and promote a free system  to stop a competitor
from gaining a foothold in a potential new market (and the goog is
obviously spending a fair bit of small change on the whole thing). I
suspect suing the goog is plan b for the w3w investors if they are not
successful with the company as such. 




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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Steve Doerr


On 10/08/2018 21:41, Blake Girardot wrote:


But while I do not like the w3w solution, if they wanted to support
OSMF to improve w3w support in osm core and the ecosystem of tools I
would be all for giving it the exact same trial if the community
agreed.

But generally, I think plus codes are coming out looking quite good
from a technical perspective, both dynamically generated and static
uses like address signs and printed maps.




There's also Mapcode: http://www.mapcode.com/

--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Christoph Hormann

On Saturday 11 August 2018, Blake Girardot wrote:
> >>
> >> Ok, enough of your overly polite, gentle feedback stuff, tell us
> >> how you really feel :)
> >
> > I am afraid that even after reading it several times i have no idea
> > what you want to say with that.
>
> My apologies Christoph, it was sarcasm. You were anything but polite
> or gentle with your feedback. I thought it was a friendly, funny way
> to de-escalate the discussion and hopefully spark some personal
> reflection.

Well - i wasn't really trying to be polite, i was trying to be direct 
because polite arguments by others why tagging encoded coordinates is 
not a good idea were ignored.

Anyway i think we have now made the arguments agains tagging this very 
clear with Frederik also explaining the practical scenarios in detail.  
Nothing has been brought up against these arguments except the 
continued expression of the political desire to push this into the OSM 
database despite all the arguments against it.  Everyone is entitled to 
their political views but i don't think the OSM database is a place 
where these can be articulated.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

2018-08-11 Thread osm . sanspourriel


Le 11/08/2018 à 10:03, lenny.libre - lenny.li...@orange.fr a écrit :

Je sais mettre les attributs pour un simple trottoir, mais là, il y a 
une relation "REV Muret-Grenade" faut-il la rediriger vers la route où 
y a-t-il des attributs qui disent descendre de vélo ? 

Oui :
highway=footway
footway=sidewalk
:-)

Ou effectivement tu fais descendre sur la route.

Je remarque le marquage au sol de vélos après le panneau de fin.
Dans le sens opposé il y a aussi un panneau, sans doute aussi de fin, 
donc n'est-ce pas juste pour signaler que la route a priorité ?
Je parle du panneau permanent fin de piste cyclable, pas de fin de voie 
verte (il y a un panneau temporaire fin de voie verte sur une autre 
image 
 
téléchargée par tes soins mais ça semble correspondre à une autre voie).


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

2018-08-11 Thread Andrew Harvey

> If the OSM community accepts the OpenLocationCode, then it would become
de facto universal addressing system. Only then people may start believing
and investing in it.

As others have pointed out the proper place for OSM to support the
OpenLocationCode in OSM is in https://nominatim.openstreetmap.org/ both
forward and reverse geocoding so if you search for an OLC it finds the
coordinates, and vice versa right clicking, Show address here returns the
OLC.

Nothing stopping you taking an extract of OSM, adding your own OLC codes to
that data and then doing what you like with that. No need to upload it to
the OSM database
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?



Am 11.08.2018 um 01:19 schrieb Martin Koppenhoefer:
> While it is true that both parties have economic interest in this, plus codes 
> are both, free to use and open source, unlike their 3 words competitor. Even 
> if w3w „wins“ we would likely not be interested in promoting them on OSMF 
> servers.
>
Well we support tagging proprietary postcode systems in countries that
have them (say the UK, Ireland and so on), but there it is clear that
they are what is -actually in use-. These post codes tend to legally not
really be different than say w3w codes.



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

Re: [OSM-talk-fr] Linky est un appareil multitaches !

2018-08-11 Thread osm . sanspourriel


Mauvaise pioche, les compteurs récents ont cette mesure anti-fraude.

Donc si on soupçonne de la fraude, on change le compteur pour un 
compteur électronique.


C'est ce qui serait le plus rentable (pas de changement massif).

Jean-Yvon


Le 11/08/2018 à 09:34, Jean-Pierre CANTAIS a écrit :
Et si le compteur Linky révélait surtout l’importance de la fraude à 
la fourniture d’électricité ? 



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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

2018-08-11 Thread Christoph Hormann

On Saturday 11 August 2018, Martin Koppenhoefer wrote:
> >
> > The wiki has definitely had problems recently and we should have a
> > good discussion about what we want from it.
>
> I don’t know since when you are following the wiki development, but
> from my point of view, there is nothing that would be worse
> “recently” that couldn’t have happened 10 years ago. On the contrary,
> I think it is now more stable and there are more eyes on it than
> before. It seems, questionable edits are often discovered and
> reverted within some hours or few days, while it took months and
> years when there were only few users.

This is part of the problem.  There is a certain trend towards a 
wikipediarization of our wiki in the sense that there are many active 
editors who essentially try to maintain the status quo in tag 
documentation, even if it does not represent how a tag is used or who 
try to document a subjective view what a tag should mean instead of 
documenting how it is actually used.

In other words:  If tag documentation pages on the wiki are out of touch 
with the reality of tag use this is often not the result of 
undiscovered questionable edits but because active wiki editors want 
them to be this way or don't care they are this way.  We don't really 
have a mechanism that forces or even incentivizes editors to ensure 
documentation is accurate.

This is not a new phenomenon - like in wikipedia this is a fairly 
natural result of the transit from expansion (where edits were 
predominantly writing new documentation) to maintainance (with 
predominantly changes of existing documentation).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

2018-08-11 Thread lenny.libre




Le 10/08/2018 à 23:37, David Crochet a écrit :

Bonjour


Le 10/08/2018 à 23:30, lenny.libre a écrit :

faut-il descendre de vélo pour suivre ce chemin, prendre la route ? 


légalement oui


quels attributs mettre ? 


cela redevient un traditionnel trottoir donc

highway=footway
footway=sidewalk

Cordalement

Je sais mettre les attributs pour un simple trottoir, mais là, il y a 
une relation "REV Muret-Grenade" faut-il la rediriger vers la route où y 
a-t-il des attributs qui disent descendre de vélo ?



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

Re: [Talk-de] Datum einer Kontrolle vermerken?

2018-08-11 Thread gmbo


genau das war am letzten Stamtisch in Bochum Thema.
Da wurde das ganze deshalb angefragt weil wir uns vermehrt um 
Öffnungszeiten kümmern wollen. Die Möglichkeiten von QA sind derzeit ja 
nur vorhanden oder nicht abzufragen.


Unsere Zusammenfassung erbrachte dann ein paar wenige Fakten.
Sinnvoll finden einn Tag für die überprüfung fast alle.

Aber
zur Zeit gibt es eine viele verschiedene Tags.
survey:date=*
lastcheck=*
survey=*
survey_date=*
updated=*
last_checked=*
operational_status=*
operational_status:date=*
operational_status:note=*
last_check:date=*
last_check:note=*
last_checked:date=*
last_checked:note=*
stateofrepair:note=*
stateofrepair=*
check_exists:date=*


Wenn dann noch die Variationen für den Typ der Überprüfung also
opening_hour:*
collection_times:*
dazukommen, weil dann ja verschiedene bessere Auswertungen möglich sein 
sollen wird es nur noch komplexer und unübesichtlicher.


deshalb waren wir uns einig lieber eine Möglichkeit zu haben, die bewußt 
das Datum der letzten Änderung als neu setzen könnte, oder sich halt auf 
ein Tag zu einigen welches dann bei den relevanten Taggings in den 
Editoren mit angeboten würde um auch überall gleiche Taggings zu haben 
und die Öffnungs , Leerungszeiten und genauso Namen der Geschäfte usw. 
besser im Blick zu haben.


Gruß
Gisbert

Am 11.08.2018 um 00:05 schrieb Andreas Meier:

Hallo zusammen,

  


seit einiger Zeit tagge ich auch collection_times bei Briefkästen. Durchaus
häufig sind vorhandene Tags veraltet und falsch. Leider kann ich den
Briefkästen nicht ansehen, ob die collection_times letzte Woche oder vor 4
Jahren zuletzt überprüft wurden. Bestenfalls gibt es ein Datum, wenn es
korrigiert=geändert wurde. Aber wenn jemand kontrolliert hat und es war
richtig, dann bleibt ja nur das ggf. uralte Datum der letzten Änderung
abgreifbar. Daher frage ich mich, ob es sinnvoll wäre, eine Art Zeitstempel
einer Überprüfung als zusätzliches Tag an den Briefkasten zu speichern, z.B.


  


time_stamp_last_check =- oder 

collection_times:last_check =  o.ä.

  


Damit könnte ich mir alle Briefkästen des Dorfes herausfiltern, die z.B.
länger als ein Jahr nicht überprüft wurden und gezielt hinfahren.

  


Das gleiche Prinzip könnte man natürlich auch für Öffnungszeiten von
Geschäften diskutieren oder ähnliches. Gibt es dazu Meinungen? (Wenn das
schon 100 Mal diskutiert wurde, dann wäre ich für einen Hinweis auf das
Ergebnis dankbar)

  


Gruß

Andreas

  


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




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

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

sent from a phone

> On 11. Aug 2018, at 07:56, Andrew Hain  wrote:
> 
> The wiki has definitely had problems recently and we should have a good 
> discussion about what we want from it.

I don’t know since when you are following the wiki development, but from my 
point of view, there is nothing that would be worse “recently” that couldn’t 
have happened 10 years ago. On the contrary, I think it is now more stable and 
there are more eyes on it than before. It seems, questionable edits are often 
discovered and reverted within some hours or few days, while it took months and 
years when there were only few users.

It definitely helps that pages you edit are automatically added to your watch 
list “now” (for some time, but not since ever).

The scope of the wiki is documenting current mapping practice and osm related 
software, organizing the community, coordinating tag development.

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

Re: [OSM-ja] placeのcityとtownの使い分け

2018-08-11 Thread batosm

私の確認不足ですね。エディターのタグからのジャンプ先を読んでいただけなのでJapan_taggingのページは知りませんでした。
市がTownになっているのは地道に修正入れていきます。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] bug de rendu sur les lignes de terrain de sport sur le rendu osmfr

2018-08-11 Thread Christian Quest

J'ai corrigé la requête... étonnant que les mises à jour du serveur aient
provoqué cet effet de bord.

Les nouvelles tuiles générées sont OK, par contre, pour les existantes, je
vais lancer un recalcul général mais il va prendre du temps.

Le ven. 10 août 2018 à 10:32, David Crochet  a
écrit :

> Bonjour
>
> Les rendus des terrains de sport semblent incohérent (rotation de 90° ):
>
>
> http://tile.openstreetmap.fr/?zoom=18=49.17863=-0.37182=B00FF
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Is it technically and legally possible to add the Open Location Code to the OSM search?