[OSM-talk-fr] Couche admin9 de layers.opesntreetmap.fr

[David Crochet]

Bonjour

sur layers.openstreetmap.fr, la couche admin9 renvoie beaucoup de tuiles 
inopérantes.


vous avez une idée ?

Cordialement

--
David Crochet


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

Re: [Talk-gb-london] TfL Cycle Infrastructure Database (CID) conflation

[David via Talk-gb-london]

Interesting.
I would have thought that the overall quality of cycle route mapping on OSM
for London is actually rather high,
inspite of TfL - it's certainly orders of magnitude better than TfL's own
maps, which seem relentless riddled with strange errors.

On Tue, Oct 17, 2023 at 4:11 PM Robert Skedgell  wrote:

> TfL have recently posted this on Facebook:
>
> "Google has improved its cycle routes in Google Maps 
> New updates now consider traffic conditions and the availability of
> Cycleways to prioritise cycling on safer, quieter roads.
> These changes are being rolled out to all users by the end of the year."
>
>
> https://www.facebook.com/transportforlondon/posts/pfbid02Po1PXVgVgE4Fbm7zkPUPp4fnq9kkgJfnsNAKbRzMYtTqVviZAevFn34JYAXrXJzVl
>
> I think that's an indirect admission by TfL that the work done on
> OpenStreetMap by TfL's paid "mappers" was an embarrassing failure. Some
> of the conflation done by the contractors was quite poor, but most of it
> was of much lower quality and should have been reverted.
>
> On 10/08/2023 16:57, Robert Skedgell wrote:
> > As the project was quietly abandoned in January 2023, is it time for a
> > post mortem of this incomplete project?
> >
> > On 15/11/2022 12:01, Whittaker, Ed via Talk-gb-london wrote:
> >> Hello
> >>
> >> Following very helpful feedback earlier in the year, we are now
> >> looking to recommence efforts to complete the migration of the TfL CID
> >> to OSM
> >>
> >> We will keep an eye on this board, but suggest (and welcome!) feedback
> >> to the main post on the talk-gb board
> >> (
> https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html
> )
> >>
> >> Thanks,
> >>
> >> Ed (Sweco), Aidan (GHD) and Lu (GHD
> >>
> >>
> >> Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England and Wales)
> >> Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate
> >> Drive, Leeds, LS7 4DN
> >
> >
> > ___
> > Talk-gb-london mailing list
> > Talk-gb-london@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb-london
>
>
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [talk-au] Classifying settlements (Was Re: Filling in blank space (Was Re: Tagging towns by relative importance, not just population size))

[David Bannon]

On 5/10/23 14:41, Warin wrote:


Community hall, Police, Fire say 10 each

Store, fuel, mechanic say 20 each

Nurse medical facility, RFDS clinic say 30

Doctors say 40

Hospital say 100

I'd wonder if we are building an impossible to manage rule set. For 
example, many small town doctor's clinic only have a doctor there one or 
two days a week. So, a full time doctor is worth 40 points, so, a one 
day a week one is 8 points ? Many, many "towns" have a community hall 
(or even a Mechanic's Institute) but very many of them have fallen into 
such disrepair its unsafe to go in. And a Hospital, thats one with an 
Emergency Department or just a couple of beds and and a pair of 
overworked nurses ?  How long since that Store was open ? A mechanic ?  
Well, the guy at the servo can help you change a tyre (but only if you 
have a real spare tyre, what are you doing out here with a temporary one 
anyway ?).


My point is there are varying degrees of all these things, I am unsure 
too many mappers are willing or able to obtain the necessary detail.


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

Re: [Talk-gb-london] TfL Cycle Infrastructure Database (CID) conflation

[David via Talk-gb-london]

I would be interested to hear such a post mortem,
although I do not think it is unfair to say that TfL have never finished
any project in their lives :)
be it cycling infrastructure (London Cycle Network, London Greenways, Cycle
Superhighways, Greenways, ... currently they're on Cycleways) -
each project is quietly forgotten about in in some press-released rebrand
of the Next Big Initiative,
with yet another set of Pantone shades carefully worked out by their
graphic designers :)
The old infrastructure is slowly cannibalised as part of the new roll out
(but never entirely gotten rid of).

The same is probably true for everything else TfL does, from tree planting
programmes to bus stop upgrades to roads and etc etc.



On Thu, Aug 10, 2023 at 5:01 PM Robert Skedgell  wrote:

> As the project was quietly abandoned in January 2023, is it time for a
> post mortem of this incomplete project?
>
> On 15/11/2022 12:01, Whittaker, Ed via Talk-gb-london wrote:
> > Hello
> >
> > Following very helpful feedback earlier in the year, we are now looking
> to recommence efforts to complete the migration of the TfL CID to OSM
> >
> > We will keep an eye on this board, but suggest (and welcome!) feedback
> to the main post on the talk-gb board (
> https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html
> )
> >
> > Thanks,
> >
> > Ed (Sweco), Aidan (GHD) and Lu (GHD
> >
> >
> > Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England and Wales)
> > Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate Drive,
> Leeds, LS7 4DN
>
>
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [OSM-talk] mapilio? (street-level imagery)

[David Haberthür]

Ciao a tutti

> On 24 May 2023, at 14:31, Greg Troxel  wrote:
> 
> I am curious if anyone
>  - thinks my assessment of the fundamentals is off

In my opinion not far off at all.
I’ve tried out their app and immediately noticed some issues:
- The (Mapbox) map they’re using in the (iOS app) didn’t attribute 
OpenStreetMap ([1], since fixed)
- Processing a short sequence of 100 images [2] took nearly two weeks and 
several question/messages on their Discord server
- Two emails sent to their main email were never answered; I’ve notified them 
that in their "Open data with Mapilio” linking to 
https://mapilio.com/openstreetmap they speak of OpenstreetMap (without capital 
S).
- Their blog post about how to contribute is pure marketing speak and no 
essence.
- They have a big GDPR page at https://mapilio.com/gdpr, but don’t seem to see 
the ‘export' part of the data very seriously [3]

Greetings from Switzerland,
Habi

[1]: 
http://forum.mapilio.com/t/how-does-mapilio-contribute-to-openstreetmap/113/2
[2]: At the moment, the only one in Switzerland at https://mapilio.com/app
[3]: https://forum.mapilio.com/t/request-data-export/116/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[David Haberthür]

Ciao Andy

> On 16 May 2023, at 19:15, Andy Townsend  wrote:
> 
> You changed it to "shop=yes", of which there are 180,000 of in OSM.  No-one 
> is going to spot that as an "unusual" shop at all.

Especially since these `shop=yes` are not rendered on OpenStreetMap Carto 
anymore, this made me generate https://maproulette.org/browse/challenges/9400 a 
while ago.
Half of the so-tagged shops in Switzerland have been fixed since then.
So there *is* potential to spot those.

Greetings from Switzerland,
habi
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-gb-london] Tube exits

[David Davis via Talk-gb-london]

Re those misbehaving map renderers -
Probably worth contacting them and pointing out that they're not following
the tagging scheme set out on OSM wiki. They're probably then raise bugs
and correct it in due course.

On Sat, 8 Apr 2023, 00:41 Bjoern Hassler,  wrote:

> Hi Rob,
>
> thanks!
>
> I appreciate that the tagging scheme excludes 'Exit 1', and suggests to
> not include the station. I've extracted exits via overpass and most exits
> don't follow the scheme. :) Most exits are simply the station name, and/or
> have the exit number written into the name. Some have what it says on the
> sign ("Exit 1. ..."), and a few do follow the scheme and just have what's
> on the sign minus the "Exit 1".
>
> While I appreciate the nature of OSM relations that give more info, ...
> and am aware that we're not tagging for the renderer but Organic Maps
> (and Maps.Me) renders the station name, and I can search for "Bank Exit 1"
> and find it (because that's in the name). I can search for Argyll Street,
> and will find "Exit 8" (but cannot see which station it is.) In principle,
> that seems very usable for people who would need to rely on using certain
> exits (e.g., for access).
>
> So... I do appreciate the scheme and that the scheme hasn't been changed
> in a while... but, given the observations above: *Do you/others think
> there's scope for bringing the labeling scheme in line with what apps can
> find while at the same time bringing the osm name in line with signage?*
>
> I appreciate the view that it's the fault of the app not rendering
> adequately - but tagging is far from perfect, e.g. 'ref' is a bit random -
> so why would apps go out of their way to use imperfect tagging? Quite
> possibly apps are just doing to use free text searches. I'd be quite happy
> to put some time into regularising the exit names. However, I'd want the
> end result to work reasonably well in apps, so it's actually of practical
> use to somebody. At the same time, I could also do this outside OSM, i.e.,
> make a set of bookmarks for OrganiseMaps that people can overlay. However,
> it would be nicer to store the data in OSM, so others can find it. *What
> do you think?*
>
> I realise that it doesn't help much that the four entrances which are
>> members of that relation were incorrectly tagged 5 years ago with
>> name="Aldgate East" (understandable) and ref=* values of A,B,C and F
>> (which seem very odd).
>
>
> I can maybe offer some observations/heuristics here. I don't know what the
> 'ref' values are, but the values for 'ref' are labels that can be found on
> the axiometric projections, see
> https://www.ianvisits.co.uk/articles/3d-maps-of-every-underground-station-ab-14630/.
> They are also referenced in some of the open data TfL makes available,
> e.g., in the unique exit id.
>
> (1) An agency did some mapping about 4-5 years ago on behalf of TfL.
> https://mentz.net/ E.g.,
> https://www.openstreetmap.org/node/475381373/history, #9. I raised some
> issues with the tagging at the time, but it wasn't really possible to get
> hold of the people doing the mapping. The ref=A,B,C were introduced at the
> time.
>
> (2) As far as I can see, those labels are purely of internal use for TfL
> (if of any use at all). I agree that they could be replaced... but see (1).
> So maybe there needs to be a different tag that can hold the ref=A,B,C and
> ref can then be used for the entrance number. (TfL does have the unique ids
> for station exits, which can be looked up in their open data on the basis
> of the ref=A,B,C. They could be added and make the ref=A,B,C redundant.)
>
> Maybe it's all a bit too random too fix, but I'd be happy to put some
> energy into fixing this on OSM, because I have experienced accurate exit
> information being useful (and I value open data). But, at the same time, it
> could be done outside OSM as well. Opinions welcome.
>
> This is clearly useless for routing, but luckily
>> for me CityMapper gets its station information from somewhere else.
>>
>
> I had a look at CityMapper, but I couldn't see station exits used.
>
> Björn
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[David Haberthür]

Ciao

> I added
> # translating German
> 'holz': 'wood',
> 'schotter': 'gravel',
> 'Gras_Laub': 'grass',
> to candidate list for the next one

I’m my (Swiss German) opinion "Schotter" is much bigger than gravel, which is 
translated to "Kies".
Gravel might be passable by bike, Schotter is the foundation under railways 
tracks.
I wouldn’t want to ride my bike over Schotter!

Greetings,
habi


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

Re: [OSM-talk] "Stadium" map roulette challenge causing issues

[David Haberthür]

Ciao Andy

Am 14.02.2023 19:47, schrieb Andy Mabbett:

I have found several instances, on different continents, such as hris
example (since fixed):

   https://www.openstreetmap.org/way/521815946/history

where the tag "wikidata=Staduum" has been added to an object by
someone apparently using this Map Roulette challenge:

   https://maproulette.org/browse/challenges/36396


Looking at 'taginfo', the values `wikidata=Stadium` and 
`wikidata=stadium` are present for a total of 6 values worldwide:  
https://taginfo.openstreetmap.org/search?q=wikidata%3DStadium
This seems something still possible to figure out on a case-by-case 
basis and not something for a bulk revert.


Greetings from Switzerland,
habi

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

Re: [Talk-gb-london] [Talk-GB] Separate sidewalks added by #waymap-project-SB in West London

[David Davis via Talk-gb-london]

I think that problem is more with routing engines than with mapping
sidewalks.
I have known since about 1975 that I can cross a road pretty much anywhere
so long as I find a safe place to cross and use the Green Cross Code ;)
Routing engines seem ignorant of this basic pedestrian ability.
It should not be beyond the wit of man to give them some sort of 'cross
with care' suggestion on minor roads, rather than to require an explicitly
crossing point to be mapped.

On Tue, Jan 17, 2023 at 10:06 AM Steven Hirschorn <
steven.hirsch...@gmail.com> wrote:

> I raised this once before on this list and didn't feel the response was
> very positive so left all the sidewalk mapping - in my case it came onto my
> radar in Acton.
> It seems pointless mapping pavements on little residential streets because
> the default expectation is a pavement on either side.
> Like you say, it can negatively impact routing if the sidewalks aren't
> joined to the roads at regular intervals, so it's easy to get wrong.
> There's a justification for mapping sidewalks in some circumstances. The
> thread is here:
> https://lists.openstreetmap.org/pipermail/talk-gb/2021-October/027947.html
>
> On Tue, 17 Jan 2023, 08:56 Robert Skedgell,  wrote:
>
>> We have had a large number of separate sidewalks added around Shepherds
>> Bush, mostly by user alisonlung (possibly based in the USA) with some
>> contributions by ABullock with the hashtag #waymap-project-SB
>>
>> I have several problems with this:
>> - there seems to be no documentation or explanation of this organised
>> editing project (or I'm looking in the wrong place)
>> - alisonlung has consistently ignored changeset comments from other users
>> - the sidewalks were frequently decorative: they may look pretty on OSM
>> Carto, but often provide no or negative benefit for pedestrian routing
>> - some sidewalks were added with layer=-1, strongly suggesting that the
>> mapper(s) had no idea what the tag means
>> - some cycleways around Shepherds Bush Green were changed to footways
>> without adding bicycle=yes, which I consider to be vandalism
>>
>> I have tried to fix some of these, but the volume and the amount of
>> fiddly realignment required seems disproportionate.
>>
>> I propose to do the following:
>> - retain and repair sidewalks on main roads
>> (trunk/primary/secondary/tertiary) where there are defined crossing
>> points, or where there is a clear benefit to pedestrian routing
>> - delete most sidewalks added by these users on residential streets,
>> leaving crossings as nodes on the highway
>>
>> --
>> Robert Skedgell (rskedgell)
>>
>> ___
>> Talk-GB mailing list
>> talk...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [Talk-gb-london] Separate sidewalks added by #waymap-project-SB in West London

[David Davis via Talk-gb-london]

I am generally in favour of explicit drawing of pavements and pedestrian
crossing points where possible,
but it does sound from your description that this user's enthusiasm has
somewhat over-reached their skillz ;)

If possible though, an effort should be made to explain and educate them as
to what technicalities they are getting wrong,
so they can direct their considerable energies more productively :)

On Tue, Jan 17, 2023 at 8:57 AM Robert Skedgell  wrote:

> We have had a large number of separate sidewalks added around Shepherds
> Bush, mostly by user alisonlung (possibly based in the USA) with some
> contributions by ABullock with the hashtag #waymap-project-SB
>
> I have several problems with this:
> - there seems to be no documentation or explanation of this organised
> editing project (or I'm looking in the wrong place)
> - alisonlung has consistently ignored changeset comments from other users
> - the sidewalks were frequently decorative: they may look pretty on OSM
> Carto, but often provide no or negative benefit for pedestrian routing
> - some sidewalks were added with layer=-1, strongly suggesting that the
> mapper(s) had no idea what the tag means
> - some cycleways around Shepherds Bush Green were changed to footways
> without adding bicycle=yes, which I consider to be vandalism
>
> I have tried to fix some of these, but the volume and the amount of
> fiddly realignment required seems disproportionate.
>
> I propose to do the following:
> - retain and repair sidewalks on main roads
> (trunk/primary/secondary/tertiary) where there are defined crossing
> points, or where there is a clear benefit to pedestrian routing
> - delete most sidewalks added by these users on residential streets,
> leaving crossings as nodes on the highway
>
> --
> Robert Skedgell (rskedgell)
>
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

[David Haberthür]

>> I'll be curious to hear feedback from this, too.  Thanks for your efforts, 
>> Lukas:  I genuinely hope they help our map!
> 
> I can see a use when you have three consecutive segments of a road, where the 
> first and the last are named (the same) and the middle is not. This might 
> indicate an omission.
> [...]
> Every unnamed way that branches or has a junction is difficult to name in an 
> armchair way.

This is exactly what is specified in Lukas’ repository (see 
https://gitlab.com/ltog/ohni#what-is-this-software-about): "most corner cases 
are rejected”.

I think the tool caters to a mapper which is rather proficient with the tools, 
as one has to download a .pbf extract and massage the data with Lukas’ tool.
This is not something for armchair mappers which blindly click on a green 
checkmark in Osmose.

Bravo Lukas, e cooli Sach!

Greetings from Switzerland,
Habi


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

Re: [OSM-talk] I need your help please

[David Haberthür]

Dear all

> On 20 Sep 2022, at 10:27, Warin <61sundow...@gmail.com> wrote:
> 
> I am not a wordpress user .. I don't think that allows you to add stuff to 
> OSM .. just to down load stuff from OSM
> 
I am using https://wordpress.org/plugins/osm/ on my WordPress blog.
By default it loads the carto tiles, a bit like leaflet.
So it might be a simple ‘wait until it’s rendered’ problem.

Azzouni Fakhreddine, can you link us to a location of the places that you’ve 
added some days ago and don’t show up for you?

Greetings from Switzerland,
habi


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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Ça risque de faire foirer le rendu, je pense : le motif « arbresque » des 
forêts va s’afficher deux fois, bonjour le rendu crade…

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
pepilepi...@ovh.fr  schrieb am Donnerstag, 8. September 
2022 um 18:17:


> Le 08/09/2022 à 17:49, Jérôme Amagat a écrit :
> > 
> > J'allais faire la même remarque, la relation type=site est une mauvaise
> > idée. C'est à utiliser seulement si ce n'est pas possible de le représenter
> > sous forme surfacique. Ici c'est surfacique donc pas de raison de
> > l'utiliser. Pour moi la moins mauvaise des solutions c'est
> > un (multi)polygon landuse=forest pour toutes la forêt et d'autres
> > plus petit avec aussi landuse=forest et leaftype= *
> 
> 
> 
> C'est pas interdit, ça, mettre le même tag sur le multipolygone et un de
> ses éléments ?

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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Salutations, Marc.

Je me doutais bien que je m’attirerais tes foudres en parlant de ce tag ;-) Je 
crains toutefois qu’il n’y ait confusion : si je comprends bien ta réponse, 
pour toi, boundary=forest sous-entend que la zone est exploitée, or ce n’est 
pas le cas. C’était bien le cas pour la deuxième itération de ma proposition, 
mais pas pour la troisième, celle qui a été approuvée, précisément parce que 
mélanger des limites de forêt et un landuse était inacceptable pour nombre de 
contributeurs, dont toi, et avec raison.

boundary=forest, tel qu’approuvé, ne fait que désigner une emprise de forêt, 
qu’elle soit exploitée ou non, boisée ou non, et accepte tout à fait que des 
zones soient exploitées et d’autres non. Elle correspond, en fait, à ce que la 
plupart des gens désignent par "Forêt de Fontainebleau", par exemple : une zone 
essentiellement boisée avec des limites définies. Comme une telle forêt n’est 
pas nécessairement intégralement boisée ou même intégralement exploitée, je 
n’ai pas trouvé mieux que découplér sa représentation des 
landuse=forest/natural=wood. De plus, boundary=forest tel qu’approuvé me semble 
correspondre aux besoins de Marc Mongenet.

Imparfait et plus complexe ? Sans doute. Ça rajoute de la confusion ? Tout à 
fait, car ça ajoute aux pratiques existantes sans rien en supprimer. Toutefois, 
pour représenter une forêt au sens décrit ci-dessus, je n’ai pas trouvé mieux, 
et je ne sache pas qu’une autre proposition ait emporté assez de suffrages pour 
être approuvée, donc, même si c’est imparfait, ça fait le boulot, et ça a 
rencontré assez d’approbation pour un vote fructueux. Je pense donc, mais je 
peux me tromper, que ce n’est pas si mauvais que ça.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Marc_marc  schrieb am Montag, 5. September 2022 um 08:53:


> Bonjour David,
> 
> Le 05.09.22 à 07:19, David Marchal via Talk-fr a écrit :
> 
> > C’est précisément pour ce genre de cas que j’avais conçu le tag 
> > boundary=forest
> 
> 
> tu sais bien que pour moi ce tag est un abération qui ne fait
> que rajouter de la confusion
> si on veux tager un landuse, la bonne clef est... landuse
> et non boundary
> 
> > un (multi)polygone type=boundary + boundary=forest + name=… pour 
> > représenter le fait que l’ensemble est une seule et unique forêt,
> 
> 
> ton utilisation est encore pire que ce qui a été voté !
> 
> la surface de "foret de ABC" n'est pas la même que la surface
> de l'exploitation forestière
> il suffit d'un étang, une place Pique-nique au milieu de cet endroit :
> il est compris dans la foret de ABC, mais personne n'utilise l'endroit
> pour la sylviculture
> 
> donc ce tag mal connu ne résout pas le soucis ici,
> puis le soucis c'est : quel tag principal pour un endroit
> composé de différente espace d'arbre, de zone ou pas
> exploité en sylviculture, etc
> 
> Cordialement,
> Marc
> 
> 
> 
> ___
> 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] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Bonjour, Marc.

Le tag boundary=forest proposé correspond à "un ensemble de zones, généralement 
boisées, où l’ensemble est considéré comme une forêt". Par exemple, une forêt 
domaniale peut contenir zones marécageuses, zones boisées résineuses, 
clairières… mais ces zones sont considérées comme partie intégrante de la 
forêt, quand bien même elles ne sont pas boisées.

Sinon, pour un cas plus général, il existe place=region : bien que controversé 
car se pose la question des limites exactes de la zone, ce tag permet de créer 
un polygone, généralement assez étendu, qui désigne une région naturelle : 
plaine, marais, cuesta… Par exemple : 
https://www.openstreetmap.org/way/1054478447

Quant au fait que boundary=forest ne soit pas rendu sur le rendu standard 
OSM.org, c’est tout simplement parce que l’usage en est encore trop faible pour 
demander son rendu : une fois qu’il y aura quelques miliers d’entités, le rendu 
pourra être demandé, mais dans l’intervalle, la demande sera sans doute 
rejetée. C’est le problème de tous les nouveaux tags : le fait qu’ils ne soient 
pas rendus n’encourage pas l’adoption, mais ils ne sont pas rendus tant qu’il 
n’y a pas une adoption minimale…

Cordialement.

Gesendet mittels einer sicheren E-Mail von [Proton Mail](https://proton.me/).

--- Original Message ---
Marc Mongenet  schrieb am Dienstag, 6. September 2022 
um 00:37:

> Bonjour,
>
> Le lun. 5 sept. 2022 à 07:21, David Marchal via Talk-fr 
>  a écrit :
>
>> Bonjour, Marc.
>>
>> C’est précisément pour ce genre de cas que j’avais conçu le tag 
>> boundary=forest (cf 
>> https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour plus 
>> d’info) : tu cartographies le terrain avec landuse=forest, natural=wetland, 
>> natural=grassland… avec autant de polygones différents qu’il le faut pour 
>> représenter le terrain (par exemple les variations de leaf_type), puis tu 
>> ajoutes par dessus un (multi)polygone type=boundary + boundary=forest + 
>> name=… pour représenter le fait que l’ensemble est une seule et unique 
>> forêt, en dépit des variations de terrain, et quand bien même le terrain 
>> n’est pas landuse=forest ou natural=wood (clairières, zones marécageuses, 
>> étangs…).
>
> Oui, cela semble correspondre exactement à ce que je cherche, au petit détail 
> près que j'en ai d'abord besoin pour un marais (boundary=wetland ?).
>
>> Un exemple ici : 
>> [https://www.openstreetmap.org/j'attendrelation/13897472](https://www.openstreetmap.org/relation/13897472)
>>
>> Soit dit en passant, on peut constater la mauvaise circulation des infos 
>> dans l’écosystème OSM : ce tag a été approuvé il y a des mois, à la 
>> troisième proposition avec la première datant de près de deux ans 
>> maintenant, et pourtant sa simple existence n’est généralement pas connue. 
>> Certes, l’écosystème OSM est complexe, mais il n’empêche…
>
> Je remarque que le nom de la forêt n'apparaît pas sur la carte. S'il n'y a 
> aucun rendu, question circulation de l'information, c'est presque comme si le 
> tag n'existait pas.
>
> Marc Mongenet
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[David Marchal via Talk-fr]

Bonjour, Marc.

C’est précisément pour ce genre de cas que j’avais conçu le tag boundary=forest 
(cf https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour 
plus d’info) : tu cartographies le terrain avec landuse=forest, 
natural=wetland, natural=grassland… avec autant de polygones différents qu’il 
le faut pour représenter le terrain (par exemple les variations de leaf_type), 
puis tu ajoutes par dessus un (multi)polygone type=boundary + boundary=forest + 
name=… pour représenter le fait que l’ensemble est une seule et unique forêt, 
en dépit des variations de terrain, et quand bien même le terrain n’est pas 
landuse=forest ou natural=wood (clairières, zones marécageuses, étangs…).

Un exemple ici : https://www.openstreetmap.org/relation/13897472

Soit dit en passant, on peut constater la mauvaise circulation des infos dans 
l’écosystème OSM : ce tag a été approuvé il y a des mois, à la troisième 
proposition avec la première datant de près de deux ans maintenant, et pourtant 
sa simple existence n’est généralement pas connue. Certes, l’écosystème OSM est 
complexe, mais il n’empêche…

Cordialement.


Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Marc Mongenet  schrieb am Sonntag, 4. September 2022 
um 23:24:


> Le dim. 4 sept. 2022 à 21:42, osm.sanspourr...@spamgourmet.com a écrit :
> 
> > Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des
> > sous-parties sans nom et de même clé principale avec les deux types de
> > plantations ?
> > 
> > Jean-Yvon
> 
> Et bien le mixed ne fonctionne pas dans le cas de la zone humide.
> Et puis si la forêt n'a aucune zone mixed, mais des zones bien délimitées
> de needleleaved (plantation d'épicéas par exemple) et de broadleaved, ça ne
> fonctionne pas non plus.
> Et surtout, je veux qu'à la fin, quand on recherche le nom de la forêt, ça
> entoure toute la forêt. Et je veux aussi que le nom de la forêt apparaisse
> dessus, bien centré, et d'une taille proportionnelle à la forêt. Bref, je
> cherche une solution propre, pas une bidouille.
> Je pensais au multipolygone qui entoure tout, comme suggéré par
> pepilepi...@ovh.fr, mais alors je suppose que le nom de la forêt (du
> marais) sera rattaché à un multipolygone sans attribut et ne représentera
> rien, n'est-ce pas ?
> 
> Marc Mongenet
> 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [talk-au] Usage of Openstreetmap at EMSINA

[David Wales via Talk-au]

On 26 August 2022 12:15:54 pm AEST, Graeme Fitzpatrick  
wrote:
>One thing that I'd love feedback on if possible is street numbers,
>particularly for rural areas?
>
>Does anybody use them & are they of any use?

I use them in Organic Maps for my personal navigation!

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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[David Marchal via Talk-fr]

Salutations !

Le problème vient de ce qu’on met dans la route : la banquette, le bord 
herbeux… tout cela est maintenu pour la route, et n’existe que par elle, sinon 
tout cela n’existerait pas, n’aurait pas été construit. Pour ma part, je 
considère que cela est partie intégrante de la route, donc je procède comme 
toi, exception faite du cas où il y a un fossé ou un autre élément du genre.

Par ailleurs, si on fait comme ton second cas, cela veut dire qu’on modélise 
une bande vide de part et d’autre de la route, or ce n’est pas vide : c’est la 
route et son infrastructure, sa bande de roulement, son bas-côté, sa bande 
d’arrêt d’urgence… Aussi peu élégant que ce soit, là encore, la première 
méthode me semble plus proche de la réalité.

En fait, le problème vient, je pense, de ce qu’on fait une ligne pour 
représenter un élément qui a une largeur non nulle, tant s’en faut ; or, en 
géométrie, une ligne a une épaisseur nulle. Logiquement, pour bien faire les 
choses, on devrait mettre l’emprise de la route dans un polygone du genre 
landuse=highway, mais, de mémoire, cette proposition avait été rejetée. On a 
donc une ligne qui représente une surface ; puisque cette surface fait limite 
entre les parcelles adjacentes, il est logique, je trouve, d’utiliser le chemin 
highway=* comme limite des parcelles adjacentes, faute de mieux.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
pepilepi...@ovh.fr  schrieb am Montag, 11. Juli 2022 um 
15:31:


> Bonjour,
>
> Quand, comme ça arrive très souvent (ici
> https://www.openstreetmap.org/#map=17/44.78529/4.95740, par exemple),
>
> on a une route avec d'un côté un champ cultivé et de l'autre une forêt,
> il est tentant de réutiliser les segments de la route dans la définition
> des landuse. C'est ce que je fais d'habitude, un peu par flemme et
> beaucoup pour ne pas surcharger inutilement la base de données (oui, je
> sais, quand on a dix milliards de noeuds on n'en est pas à dix ou cent
> mille près, mais j'aime pas ça).
>
> Dans certaines zones (ici
> https://www.openstreetmap.org/#map=19/44.85846/4.95959, par exemple)
>
> on voit aussi la route, une limite séparée pour le bois, et une autre
> limite de l'autre côté pour la zone résidentielle.
>
> Certes c'est vrai (en France du moins) qu'en toute rigueur il y a
> toujours une petite bande, un talus ou un fossé, entre la route et le
> champ cultivé. Mais est-ce vraiment la peine de la mentionner ?
>
> Laquelle de ces deux pratiques doit-elle être préférée ?
>
> Bonne journée,
>
> Jean-Pierre
>
>
> --
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

[talk-au] definition of PSV (Public Service Vehicles) in Australia

[David Vidovic via Talk-au]

Hi all,
In regards to PSV (Public Service Vehicles), I understand this encompasses 
buses/coaches.
For a "bus only" way such as a bus bay, I see common tagging [access=no] + 
[psv=yes] used.
Does anyone know if a Taxi is considered a "public service vehicle" and 
therefore able use the busy bay way? Or does [access=no] inherently prevent 
this and it would need a separate [taxi=yes] tag?
cheers,David
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Nicolas,

Note également que cela ne dispense pas de faire des recherches plus 
approfondies. Pour ma part, je fais des recherches sur la région, regarde si 
les différentes sources existantes sont d’accord sur ce qui est dans la région 
naturelle et ce qui ne l’est pas, et tranche en fonction de l’altimétrie et de 
la géologie pour les cas litigieux. Bref, je fais au mieux avec les 
informations que je trouve, et advienne que pourra.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
David Marchal  schrieb am Samstag, 25. Juni 2022 um 
17:58:


> Salut, Nicolas !
>
> Pour la note, j’utilise le tag note=*, qui sert à donner des précisions aux 
> autres contributeurs, par exemple ici: 
> https://www.openstreetmap.org/relation/14265856
>
> Le BRGM publie la carte géologique harmonisée de la France , par département, 
> à l’adresse suivante : 
> https://www.geocatalogue.fr/Detail.do?fileIdentifier=94636790-8615-11dc-9e02-0050568151b7
>  Je dis harmonisée car, auparavant, chaque carte de la série avait sa propre 
> légende et son propre code couleur. Si, si… Imagine les cartes IGN dont les 
> couleurs changent si tu changes de région…
>
> Il y a aussi un service WMS/WFS (URL pour JOSM: 
> wms:http://geoservices.brgm.fr/geologie?language=fre=image/png=TRUE=1.3.0=WMS=GetMap=SCAN_H_GEOL50_SCAN=={proj}={width}={height}={bbox})
>  utilisable sous les mêmes conditions que le cadastre, c’est-à-dire préciser 
> la source et l’année d’utilisation. Ce service couvre toute la France 
> métropolitaine en un bloc, ce qui est bien plus pratique.
>
> Pour l’altimétrie, tu as différents services WMS ouverts à l’adresse suivante 
> : https://www.terrestris.de/en/hoehenmodell-srtm30-wms/ Ce service reprend 
> les données ouvertes du SRTM que la Nasa a publiées, et les rend disponible 
> en WMS. Pour ma part, j’utilise le calque Hillshade (ombrage), que je mets 
> par dessus la carte géologique avec de la transparence pour distinguer la 
> géologie sous l’ombrage… Et voilà le travail !
>
> Cordialement.
>
>
> Gesendet mittels einer sicheren E-Mail von Proton Mail.
>
>
> --- Original Message ---
> Nicolas Bétheuil nb+...@heloworld.me schrieb am Samstag, 25. Juni 2022 um 
> 12:55:
>
>
>
> > Bonjour
> >
> > Merci David pour toutes ces précisions et formalisation sur des usages
> > qui se rapprochent de l'idée.
> > Quelques questions pratique :
> > Quand tu parles d'une note, tu parles d'une mention dans le tag source
> > ?
> > Comment trouver la couche géologique pour décalquer les contours ?
> > C'est un truc libre ?
> > Le rendu IGN des altitudes (couleur par altitude et pas juste courbe)
> > pourraient être intéressant mais j'imagine pas libre, même si le modèle
> > des courbes de niveau est lui libre (de la NASA j'avais lu ?)
> >
> > On Fri, 2022-06-24 at 17:53 +, David Marchal via Talk-fr wrote:
> >
> > > Bonjour à tous !
> > >
> > > Si c’est pour des régions naturelles, il y a un schéma "non-officiel"
> > > (non approuvé par le processus de discussion/vote Wiki) de
> > > (multi)polygones pour cartographier ça: place=region +
> > > region:type=natural_area ; pour le pays d’Othe, par exemple :
> > > https://www.openstreetmap.org/relation/1241697 (pour info,
> > > OpenTopoMap rend ces informations par un label qui se courbe pour
> > > suivre au mieux les limites de la région :
> > > https://opentopomap.org/#map=8/47.9145/3.9880). Certains
> > > contributeurs utilisent natural=* ou region:type=mountain_range pour
> > > préciser davantage de quel type de région il s’agit.
> > >
> > > Je me sers de ce genre de polygones/relations dans ma région, tout en
> > > mettant une note indiquant que, s’agissant de régions naturelles, les
> > > limites sont par définition contestables, et je constate que je ne
> > > suis pas le seul (https://www.openstreetmap.org/relation/3078437).
> > > Pour ma part, si j’estime pouvoir donner une limite, même imprécise,
> > > je cartographie la région en plaçant cette note ; charge à qui veut
> > > améliorer la limite de le faire, c’est tout le principe d’OSM. Si,
> > > par contre, c’est vraiment trop flou (genre, je n’ai que quelques
> > > noms de localités considérées comme incluses dans la région), je ne
> > > cartographie pas.
> > >
> > > Toutefois, je me suis aperçu que, pour beaucoup de régions
> > > naturelles, utiliser une carte géologique et un modèle numérique de
> > > terrain, qui va indiquer côtes, lignes de crêtes, vallées… permet de
> > > placer assez précisément les l

Re: [OSM-talk-fr] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Salut, Nicolas !

Pour la note, j’utilise le tag note=*, qui sert à donner des précisions aux 
autres contributeurs, par exemple ici: 
https://www.openstreetmap.org/relation/14265856

Le BRGM publie la carte géologique harmonisée de la France , par département, à 
l’adresse suivante : 
https://www.geocatalogue.fr/Detail.do?fileIdentifier=94636790-8615-11dc-9e02-0050568151b7
 Je dis harmonisée car, auparavant, chaque carte de la série avait sa propre 
légende et son propre code couleur. Si, si… Imagine les cartes IGN dont les 
couleurs changent si tu changes de région…

Il y a aussi un service WMS/WFS (URL pour JOSM: 
wms:http://geoservices.brgm.fr/geologie?language=fre=image/png=TRUE=1.3.0=WMS=GetMap=SCAN_H_GEOL50_SCAN=={proj}={width}={height}={bbox})
 utilisable sous les mêmes conditions que le cadastre, c’est-à-dire préciser la 
source et l’année d’utilisation. Ce service couvre toute la France 
métropolitaine en un bloc, ce qui est bien plus pratique.

Pour l’altimétrie, tu as différents services WMS ouverts à l’adresse suivante : 
https://www.terrestris.de/en/hoehenmodell-srtm30-wms/ Ce service reprend les 
données ouvertes du SRTM que la Nasa a publiées, et les rend disponible en WMS. 
Pour ma part, j’utilise le calque Hillshade (ombrage), que je mets par dessus 
la carte géologique avec de la transparence pour distinguer la géologie sous 
l’ombrage… Et voilà le travail !

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Nicolas Bétheuil  schrieb am Samstag, 25. Juni 2022 um 
12:55:


> Bonjour
>
> Merci David pour toutes ces précisions et formalisation sur des usages
> qui se rapprochent de l'idée.
> Quelques questions pratique :
> Quand tu parles d'une note, tu parles d'une mention dans le tag source
> ?
> Comment trouver la couche géologique pour décalquer les contours ?
> C'est un truc libre ?
> Le rendu IGN des altitudes (couleur par altitude et pas juste courbe)
> pourraient être intéressant mais j'imagine pas libre, même si le modèle
> des courbes de niveau est lui libre (de la NASA j'avais lu ?)
>
>
> On Fri, 2022-06-24 at 17:53 +, David Marchal via Talk-fr wrote:
>
> > Bonjour à tous !
> >
> > Si c’est pour des régions naturelles, il y a un schéma "non-officiel"
> > (non approuvé par le processus de discussion/vote Wiki) de
> > (multi)polygones pour cartographier ça: place=region +
> > region:type=natural_area ; pour le pays d’Othe, par exemple :
> > https://www.openstreetmap.org/relation/1241697 (pour info,
> > OpenTopoMap rend ces informations par un label qui se courbe pour
> > suivre au mieux les limites de la région :
> > https://opentopomap.org/#map=8/47.9145/3.9880). Certains
> > contributeurs utilisent natural=* ou region:type=mountain_range pour
> > préciser davantage de quel type de région il s’agit.
> >
> > Je me sers de ce genre de polygones/relations dans ma région, tout en
> > mettant une note indiquant que, s’agissant de régions naturelles, les
> > limites sont par définition contestables, et je constate que je ne
> > suis pas le seul (https://www.openstreetmap.org/relation/3078437).
> > Pour ma part, si j’estime pouvoir donner une limite, même imprécise,
> > je cartographie la région en plaçant cette note ; charge à qui veut
> > améliorer la limite de le faire, c’est tout le principe d’OSM. Si,
> > par contre, c’est vraiment trop flou (genre, je n’ai que quelques
> > noms de localités considérées comme incluses dans la région), je ne
> > cartographie pas.
> >
> > Toutefois, je me suis aperçu que, pour beaucoup de régions
> > naturelles, utiliser une carte géologique et un modèle numérique de
> > terrain, qui va indiquer côtes, lignes de crêtes, vallées… permet de
> > placer assez précisément les limites des régions naturelles, qui
> > correspondent assez souvent, par exemple, à un changement de roche
> > mère ou à la brusque apparition d’un pays vallonné. Exemple avec les
> > collines sous-vosgiennes
> > (https://www.openstreetmap.org/relation/14220370) qui correspondent à
> > l’apparition, depuis le plateau lorrain argilo-calcaire, d’un pays de
> > collines gréseuses : avec carte géologique et ombrage des reliefs, ça
> > va tout seul ! Bon, on a une précision à l’hectomètre ou au
> > kilomètre, mais c’est plus précis qu’un nœud au milieu de nulle part,
> > qui ne donne aucune idée, même approximative, de l’emprise.
> >
> > On pourrait ergoter sur les limites précises, car qui peut dire où
> > s’arrête un plateau et où commence la plaine qu’il domine ? À quel
> > niveau de l’escarpement donner la limite ? Toutefois, le fait est que
> > de telles régions existent, même si elles ont des limites floues ; la
>

Re: [OSM-talk-fr] Nom de zone géographique / touristique

[David Marchal via Talk-fr]

Bonjour à tous !

Si c’est pour des régions naturelles, il y a un schéma "non-officiel" (non 
approuvé par le processus de discussion/vote Wiki) de (multi)polygones pour 
cartographier ça: place=region + region:type=natural_area ; pour le pays 
d’Othe, par exemple : https://www.openstreetmap.org/relation/1241697 (pour 
info, OpenTopoMap rend ces informations par un label qui se courbe pour suivre 
au mieux les limites de la région : 
https://opentopomap.org/#map=8/47.9145/3.9880). Certains contributeurs 
utilisent natural=* ou region:type=mountain_range pour préciser davantage de 
quel type de région il s’agit.

Je me sers de ce genre de polygones/relations dans ma région, tout en mettant 
une note indiquant que, s’agissant de régions naturelles, les limites sont par 
définition contestables, et je constate que je ne suis pas le seul 
(https://www.openstreetmap.org/relation/3078437). Pour ma part, si j’estime 
pouvoir donner une limite, même imprécise, je cartographie la région en plaçant 
cette note ; charge à qui veut améliorer la limite de le faire, c’est tout le 
principe d’OSM. Si, par contre, c’est vraiment trop flou (genre, je n’ai que 
quelques noms de localités considérées comme incluses dans la région), je ne 
cartographie pas.

Toutefois, je me suis aperçu que, pour beaucoup de régions naturelles, utiliser 
une carte géologique et un modèle numérique de terrain, qui va indiquer côtes, 
lignes de crêtes, vallées… permet de placer assez précisément les limites des 
régions naturelles, qui correspondent assez souvent, par exemple, à un 
changement de roche mère ou à la brusque apparition d’un pays vallonné. Exemple 
avec les collines sous-vosgiennes 
(https://www.openstreetmap.org/relation/14220370) qui correspondent à 
l’apparition, depuis le plateau lorrain argilo-calcaire, d’un pays de collines 
gréseuses : avec carte géologique et ombrage des reliefs, ça va tout seul ! 
Bon, on a une précision à l’hectomètre ou au kilomètre, mais c’est plus précis 
qu’un nœud au milieu de nulle part, qui ne donne aucune idée, même 
approximative, de l’emprise.

On pourrait ergoter sur les limites précises, car qui peut dire où s’arrête un 
plateau et où commence la plaine qu’il domine ? À quel niveau de l’escarpement 
donner la limite ? Toutefois, le fait est que de telles régions existent, même 
si elles ont des limites floues ; la question est alors de savoir ce qu’on veut 
cartographier. La réalité dans toute son imprécision, ou une version expurgée 
de tout ce qui n’est pas considéré comme suffisamment précis ?

Concernant le Gévaudan, attention : un PETR est une entité administrative, et, 
par expérience, ces entités, même si elles reprennent le nom d’anciennes 
provinces ou de régions naturelles, ne les recouvrent qu’imparfaitement et en 
sont différentes. Selon le principe OSM « Un élément, une entité », le PETR et 
la région naturelle, s’ils sont tous deux cartographiés, devraient l’être, à 
mon sens, avec deux entités.

Enfin, je rappelle tout de même que tout cela n’est que mon avis, mais si ça 
peut servir…

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.

--- Original Message ---
Christian Quest  schrieb am Freitag, 24. Juni 2022 um 
17:14:


> Le 24/06/2022 à 15:59, Marc_marc a écrit :
>
> > Bonjour Yannick,
> >
> > Le 24.06.22 à 12:13, Yannick a écrit :
> >
> > > Le 24/06/2022 à 10:48, Marc_marc a écrit :
> > >
> > > > à n'ajouter que si cela a du sens encore aujourd'hui vu que c'est
> > > > vraiement vieux
> > >
> > > Tu ne peux préjuger de ce qui est utile ou non à d'autres.
> >
> > Merci pour ton avis.
> > Juger si c'est utile ou pas n'est pas mon propos.
> > mon propos c'est qu'osm c'est la réalité d'aujourd'hui.
> > osm n'est pas une base de donnée de l'histoire du monde.
> >
> > exemple 1 :
> > le tracé de l'empire romain sans aucune trace sur le terrain
> > est utile à plein de personne mais il n'a pas sa place dans osm,
> > des prrojets style OpenHistoricalMap sont fait pour ce genre
> > de données historiques.
> >
> > exemple 2:
> > Certaines communes fusionnées sont encore utilisée aujourd'hui,
> > des personnes disent encore parfois "j'habite dans l'ancienne
> > commune ABC", des noms de rues changent encore parfois de nom
> > à l'ancienne limite communale. je trouve pertinent de conserver
> > ce genre de donnée dans osm "pour un certain temps"
> >
> > Pour une tracé d'une entité administrative qui n'existe plus
> > depuis la révolution française, j'ai un gros doute, ne sachant pas
> > si Nicolas parlait de l'entité administrative ou "géologique"
> > Si qlq trouve que cela a encore une réalité aujourd'hui,
> > alors cela a sa place dans osm, sinon (et c'est mon impression),
> > c'est une information pour OpenHistoricalMap
> >
> > https://wiki.openstreetmap.org/wiki/FR:Open_Historical_Map
> >
> > Cordialement,
> > Marc
>
>
>
> Je ne sais pas si on parle de la même chose, mais j'ai une maison en
> Bourgogne, dans l'Auxerrois, à côté du Pays d'Othe et de la 

[talk-au] How to create an exception for buses where way tag is [parking:lane:left = no_stopping] ?

[David Vidovic via Talk-au]

Hi, 
In Sydney, we have a situation where buses service bus stops along the M2 
Motorway.
Cars and Ride Share vehicles are not permitted to stop at these bus stops.
To prevent vehicles stopping, I believe I can use the common tagging method 
[parking:lane:left = no_stopping] on a way segment
BUT, I don't want this tag to prevent buses from being able to service the bus 
stop.
Is there an exception tag or some other kind of tag that could allow buses to 
stop?
Cheers, David___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] JOSM - Désignation des shop=farm

[David Marchal via Talk-fr]

Salut, TopographeFou !

Une modification de traduction bienvenue ; feu vert pour moi.

Cordialement.

Gesendet mittels einer sicheren E-Mail von Proton Mail.
--- Original Message ---
LeTopographeFou  schrieb am Sonntag, 5. Juni 2022 um 
19:14:


> Bonjour à tous,
>
> Soit la clé suivante : shop=farm
>
> JOSM en français la nomme "Primeur" là où le wiki (et je suis d'accord
> avec lui) parle de produits de la ferme. "Primeur", c'est en théorie
> shop=greengrocer (nommée "Fruits et légumes" dans JOSM). A mon avis cela
> a dû créer des erreurs.
>
> Aucun soucis pour que je fasse changer la traduction JOSM de shop=farm
> en "Produits de la ferme" ?
>
> Cordialement,
>
> --
> LeTopographeFou
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [Talk-gb-london] Conflating TfL CID cycle data to OSM

[David Davis via Talk-gb-london]

I'm a bit surprised to read that it proposes to discard signage.
Obviously, yes, *every* traffic sign would be way over the top, but are
route signs not useful?
If these have a 'guidepost' and a 'destination' tag, it's possible to make
destination relations that can be use by route planning apps. (Not that I
have a clue how to actually do the latter, but.. ;)
I've tagged quite a few of these in recent months.

On Fri, May 13, 2022 at 4:29 PM Robert Skedgell  wrote:

> On 13/05/2022 16:10, Whittaker, Ed via Talk-gb-london wrote:
> > Hello everyone,
> >
> > Pleased to let you know that we have been commissioned by TfL to
> continue the good work of cyclestreets in completing the migration of the
> CID to OSM. In the first instance, we've updated the associated wiki to
> give more detail about this renewed effort:
> > https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database
> >
> > This is just a small introduction - we'll be in touch with updates on
> the conflation approach. We're very grateful to receive your questions and
> comments!
> >
> > Lu (GHD), Ed (Sweco) and Aidan (GHD)
> >
> >
> > Ed Whittaker
>
> Hi,
>
> It's great to see something finally being done with the TfLCID data on a
> larger scale.
>
> I've been manually matching and adding some TfLCID assets within Newham
> as I edit other highway features. So far I've been using the key
> ref:GB:tflcid for TfL's asset ref., but I'm happy to change those if you
> were planning to use another key.
>
> --
> Robert Skedgell (rskedgell)
>
>
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [Talk-gb-london] Pavement (Sidewalks)

[David Davis via Talk-gb-london]

I'm not very familiar with Reading, but generally if I am adding detail to
any area of mapping, I will draw in pavements and pedestrian crossings as
seperate 'ways'.
Quite often that's because there's a particular signposted walking/hiking
route that I'm tagging, and it's a bit daft to tag these as going down the
middle of a road (particularly busy main road junctions, where there's
usualy a particular set of crossing walkers need to use).
It's also comes up when mapping cycle routes, which can often involve
'shared pavements'.
But more generally, I don't think maps should just be for car drivers :)

On Mon, 2 May 2022, 21:01 Matthew Norton,  wrote:

> Hi all,
>
>
>
> I’m reasonably new to editing OSM so please forgive any massive
> misunderstandings/blunders I am making.
>
>
>
> That being said my question is: what pavement (sidewalk) mapping style
> should be used around the Berkshire (Reading) area? I understand there are
> some conflicting ideas between how it should be done (a tag on the main
> road vs a completely separate mapped way) and the wiki states that one
> should ask their local community as to the way to go about aiding the map
> (which seems acceptable to me).
>
>
>
> So this is me asking. The current style in use around me is the tags on
> the main road, but I feel like a separate way would map the actual
> locations of the pavements better, which would aid a small project I’m
> hoping to do.
>
>
>
> Any advice on whether I could start this remodelling would be fab.
>
>
>
> Cheers!
>
> Clive.
> ___
> Talk-gb-london mailing list
> Talk-gb-london@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-london
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [talk-au] OSM Notes

[David Wales via Talk-au]

I'm guilty of leaving some abandoned notes! I got the notifications when they 
were cleaned up recently.

I mostly left the notes because I was using StreetComplete, and wanted to 
capture data that StreetComplete couldn't capture. I intended to come back and 
resolve the notes, but clearly forgot!

However, I did double check some of the recently closed notes, and at least one 
had been closed without incorporating the information (postbox collection time) 
into the map. I took the opportunity to belatedly add this.

Regards,
David Wales

On 7 March 2022 10:31:08 am AEDT, stevea  wrote:
>On Mar 2, 2022, at 1:18 AM, Graeme Fitzpatrick  wrote:
>> Have they simply forgotten that they posted them, so a reminder would og 
>> their memory; or as suggested, do they want somebody else to do the actual 
>> mapping work for them?
>
>Let's not forget that a Note is often added by a "lesser experienced" mapper 
>(or maybe not even a mapper at all, I think there might be methods for 
>non-Contributors to add a Note, like through certain apps...please correct me 
>if I'm wrong).  They add a Note because it is "better than leaving a noticed 
>error," but they can't (or won't) fix it themselves.  So, YES, they DO want 
>somebody else to do the actual mapping work for them.  There is nothing wrong 
>with this, it is part of why Notes exist, so let's incorporate that knowledge 
>into why somebody posted a Note in the first place:  it isn't so we can 
>grumble at their "laziness," it is to "request an assist" by a mapper who 
>comes along later and says "yup, there's a problem here, I know how to fix it, 
>and they whack away the error into mapping data bliss."  (Right there, for 
>that issue).  And, "another one (Note) bites the dust."
>
>As we Resolve a Note, it's a full round-trip on what is supposed to happen 
>with them.  Even one at a time this is true, but especially when you get 
>national-scope efforts to fix these (thousands at a time), the quality of our 
>map data just goes up, up, up.  I smile at the thought of it:  such feedback 
>loops are wonderful.
>
>Congrats on the Weekly Newsletter horn-toot!
>___
>Talk-au mailing list
>Talk-au@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[David Davis via Talk-gb-london]

OK, I did a little more reading but it turns out that the actual order (
https://www.legislation.gov.uk/uksi/2022/37/note/made ) simply says 'the
new ward boundaries are those shown on the map in the Commission's office
... and here's a link to an electronic version of the same map' which
is the one I already used as my reference to make the OSM edits.
(It's just as OS StreetView map not especially detailed)

And it says 'Where a boundary is shown on the map as running along a road,
railway line, footway, watercourse or similar geographical feature, it is
to be treated as running along the centre line of the feature.'

... which is how I tagged it.
The railway line in question was dual track, so I drew a boundary line in
the middle between the two tracks.
Where the road in question was drawn as a dual carriageway on OSM, I drew a
boundary line in between the two ways.



On Mon, 21 Feb 2022, 21:49 Colin Smale,  wrote:

> If the position of the boundary is imported from a source that ultimately
> has a very high precision, for example Ordnance Survey or a Council's GIS
> system through a shapefile or similar, then the location as recorded in OSM
> will likely be more accurate than what would be obtained from tracing from
> aerial photos. In other words, if a boundary and a road/railway/etc
> *almost* coincide, more consideration should be given to moving the road to
> match the imported boundary than the other way around.
>
> Having said that, the exact line of a boundary tends to get frozen at the
> moment the Order is made, even if the road/railway/etc is subsequently
> realigned. I strongly recommend that boundaries and other features do *not*
> get combined or even share nodes, unless it can be demonstrated that the
> link between them is dynamic, i.e. a change to one necessarily means a
> change to the other.
>
> On 02/17/2022 3:41 PM David Davis via Talk-gb-london <
> talk-gb-london@openstreetmap.org> wrote:
>
>
>
> Yeah Tom,
> this is conclusion I reached too:
> if a ward boundary is legally defined as being a particular geographical
> feature (e.g. centre line of a road) then it is better to have that way on
> OSM tagged with a relation (even if its position is a metre or two off
> perfect) rather than have another line imported and tagged as the boundary.
> And probably even worse: if the road *is* in precisely the right position,
> neither is it helpful to have another imported line superimposed right on
> top of it, as it makes it very fiddly to try and edit them subsequently.
> So, slightly timeconsuming as it is, I think it's probably best to set
> them up manually.
>
> On Thu, Feb 17, 2022 at 1:55 PM Tom Chance  wrote:
>
> I've previously found it valuable to have the ward boundaries in OSM, and
> am responsible for all the Southwark (not Lambeth) ward boundaries, plus a
> few Lambeth, Croydon and Bromley. Sometimes the misalignment of open data
> and OSM data can lead to mistakes. It's not a big deal if they aren't in,
> but I don't see any reason to say they *shouldn't* be.
>
> If you're going to update them (great!) I think they work better as
> relations using - where relevant - existing objects like roads where they
> go down the middle of a road. Otherwise, again, things can get misaligned
> and otherwise go wrong. So a straight import isn't as good an option as the
> rather more painstaking manual approach.
>
> Tom
>
> m: 07866 447 075
> w: http://tomchance.org
>
>
> On Wed, 16 Feb 2022 at 11:46, Russ Garrett  wrote:
>
> My controversial opinion is that these shouldn't be in OSM.
>
> The definitive boundaries are freely available as open data in OS
> Boundary Line (although they won't usually appear there until after
> the boundaries take effect). The current UK-wide coverage of ward
> boundaries in OSM is pretty minimal, although it looks like most of
> the old Lambeth wards are in OSM:
>
>
> http://overpass-turbo.eu/?q=W291dDpqc29uXVt0aW1lxIHEgzI1XTsKKAogIG53clsiYsSBbmRhcnkiPSJwb2xpxItjYWwixInEqMSqxKxpxK5sX2RpdmlzacSHxKYid8SjZMSxKHt7YsSfeH19KcSUxY8KxI8gxJ9kecSUPsSUxZNza2VsIHF0Ow=BJp6-ioHTL
>
> As someone who uses this boundary data relatively frequently, there's
> no reason why I should use OSM when the data is incomplete, and
> boundaries in OSM may have been altered (accidentally or otherwise).
> They're not surveyable, the data is freely available elsewhere - I
> don't see why it's worth spending our time making sure it's replicated
> in OSM.
>
> Cheers,
>
> Russ
>
> On Wed, 16 Feb 2022 at 11:27, David Davis via Talk-gb-london
>  wrote:
> >
> > Hello,
> > a complete revamp of the electoral wards in Lambeth borough comes into
> effect in May 2022, with 25 new wards.
> > (See
> https://love.lambeth.gov.

Re: [Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[David Davis via Talk-gb-london]

Just to be clear though Colin, in that particular instance when I said the
position of the railway line looked rather dodgy, that was when comparing a
high degree of congruence between Cadastral Parcels and the satellite
imagery (roads and buildings) and the adjacent railway lines cutting
through them being out by so much that the railway line as currently shown
in OSM would have been going through people's houses! (The houses weren't
currently drawn in on OSM, just marked as a 'residential area'.
I didn't import OS open data of the ward boundary, as it was sufficient to
refer to the Boundary Commission and Lambeth's Council's published maps
(the latter of which uses OSM!).
About 90% of the ward boundary in questoon is just defined as 'down the
middle of the road' or 'along the railway line'  a few bits were 'along
the fence between two back gardens' (which the Casastral Parcels helps a
lot to sanity check)

On Mon, 21 Feb 2022, 21:49 Colin Smale,  wrote:

> If the position of the boundary is imported from a source that ultimately
> has a very high precision, for example Ordnance Survey or a Council's GIS
> system through a shapefile or similar, then the location as recorded in OSM
> will likely be more accurate than what would be obtained from tracing from
> aerial photos. In other words, if a boundary and a road/railway/etc
> *almost* coincide, more consideration should be given to moving the road to
> match the imported boundary than the other way around.
>
> Having said that, the exact line of a boundary tends to get frozen at the
> moment the Order is made, even if the road/railway/etc is subsequently
> realigned. I strongly recommend that boundaries and other features do *not*
> get combined or even share nodes, unless it can be demonstrated that the
> link between them is dynamic, i.e. a change to one necessarily means a
> change to the other.
>
> On 02/17/2022 3:41 PM David Davis via Talk-gb-london <
> talk-gb-london@openstreetmap.org> wrote:
>
>
>
> Yeah Tom,
> this is conclusion I reached too:
> if a ward boundary is legally defined as being a particular geographical
> feature (e.g. centre line of a road) then it is better to have that way on
> OSM tagged with a relation (even if its position is a metre or two off
> perfect) rather than have another line imported and tagged as the boundary.
> And probably even worse: if the road *is* in precisely the right position,
> neither is it helpful to have another imported line superimposed right on
> top of it, as it makes it very fiddly to try and edit them subsequently.
> So, slightly timeconsuming as it is, I think it's probably best to set
> them up manually.
>
> On Thu, Feb 17, 2022 at 1:55 PM Tom Chance  wrote:
>
> I've previously found it valuable to have the ward boundaries in OSM, and
> am responsible for all the Southwark (not Lambeth) ward boundaries, plus a
> few Lambeth, Croydon and Bromley. Sometimes the misalignment of open data
> and OSM data can lead to mistakes. It's not a big deal if they aren't in,
> but I don't see any reason to say they *shouldn't* be.
>
> If you're going to update them (great!) I think they work better as
> relations using - where relevant - existing objects like roads where they
> go down the middle of a road. Otherwise, again, things can get misaligned
> and otherwise go wrong. So a straight import isn't as good an option as the
> rather more painstaking manual approach.
>
> Tom
>
> m: 07866 447 075
> w: http://tomchance.org
>
>
> On Wed, 16 Feb 2022 at 11:46, Russ Garrett  wrote:
>
> My controversial opinion is that these shouldn't be in OSM.
>
> The definitive boundaries are freely available as open data in OS
> Boundary Line (although they won't usually appear there until after
> the boundaries take effect). The current UK-wide coverage of ward
> boundaries in OSM is pretty minimal, although it looks like most of
> the old Lambeth wards are in OSM:
>
>
> http://overpass-turbo.eu/?q=W291dDpqc29uXVt0aW1lxIHEgzI1XTsKKAogIG53clsiYsSBbmRhcnkiPSJwb2xpxItjYWwixInEqMSqxKxpxK5sX2RpdmlzacSHxKYid8SjZMSxKHt7YsSfeH19KcSUxY8KxI8gxJ9kecSUPsSUxZNza2VsIHF0Ow=BJp6-ioHTL
>
> As someone who uses this boundary data relatively frequently, there's
> no reason why I should use OSM when the data is incomplete, and
> boundaries in OSM may have been altered (accidentally or otherwise).
> They're not surveyable, the data is freely available elsewhere - I
> don't see why it's worth spending our time making sure it's replicated
> in OSM.
>
> Cheers,
>
> Russ
>
> On Wed, 16 Feb 2022 at 11:27, David Davis via Talk-gb-london
>  wrote:
> >
> > Hello,
> > a complete revamp of the electoral wards in Lambeth borough comes into
> effect in May 2022, with 25 new wards.
> > (See
&

Re: [Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[David Davis via Talk-gb-london]

well, I did the first one! (Brixton Acre Lane)
https://www.openstreetmap.org/relation/13817756#map=15/51.4573/-0.1225
(Did I do it right...?)

It didn't actually take very long.
For the most part, I was able to simply tag roads with the relation.
For a few more outré bits where the ward boundary follows property
boundaries, that "Cadastral Parcels" layer was invaluable at working out
where the boundary line should go
(I didn't know about Cadastral Parcels before, it's so helpful!)
The trickiest bit was where the boundary appears to have been defined as
along a railway line -
the existing positions of the tracks themselves was not very accurate, and
I wasn't sure which track was meant to be the boundary, so I just drew in a
new boundary line rather than apply the relation to the tracks
(also, it would have been tricky to get the relation continuous if tagging
the actual track, because the train track crosses the road on a bridge
rather than intersecting at a level crossing, so the two ways don't
actually join)

On Thu, Feb 17, 2022 at 2:41 PM David Davis 
wrote:

>
> Yeah Tom,
> this is conclusion I reached too:
> if a ward boundary is legally defined as being a particular geographical
> feature (e.g. centre line of a road) then it is better to have that way on
> OSM tagged with a relation (even if its position is a metre or two off
> perfect) rather than have another line imported and tagged as the boundary.
> And probably even worse: if the road *is* in precisely the right position,
> neither is it helpful to have another imported line superimposed right on
> top of it, as it makes it very fiddly to try and edit them subsequently.
> So, slightly timeconsuming as it is, I think it's probably best to set
> them up manually.
>
> On Thu, Feb 17, 2022 at 1:55 PM Tom Chance  wrote:
>
>> I've previously found it valuable to have the ward boundaries in OSM, and
>> am responsible for all the Southwark (not Lambeth) ward boundaries, plus a
>> few Lambeth, Croydon and Bromley. Sometimes the misalignment of open data
>> and OSM data can lead to mistakes. It's not a big deal if they aren't in,
>> but I don't see any reason to say they *shouldn't* be.
>>
>> If you're going to update them (great!) I think they work better as
>> relations using - where relevant - existing objects like roads where they
>> go down the middle of a road. Otherwise, again, things can get misaligned
>> and otherwise go wrong. So a straight import isn't as good an option as the
>> rather more painstaking manual approach.
>>
>> Tom
>>
>> m: 07866 447 075
>> w: http://tomchance.org
>>
>>
>> On Wed, 16 Feb 2022 at 11:46, Russ Garrett  wrote:
>>
>>> My controversial opinion is that these shouldn't be in OSM.
>>>
>>> The definitive boundaries are freely available as open data in OS
>>> Boundary Line (although they won't usually appear there until after
>>> the boundaries take effect). The current UK-wide coverage of ward
>>> boundaries in OSM is pretty minimal, although it looks like most of
>>> the old Lambeth wards are in OSM:
>>>
>>>
>>> http://overpass-turbo.eu/?q=W291dDpqc29uXVt0aW1lxIHEgzI1XTsKKAogIG53clsiYsSBbmRhcnkiPSJwb2xpxItjYWwixInEqMSqxKxpxK5sX2RpdmlzacSHxKYid8SjZMSxKHt7YsSfeH19KcSUxY8KxI8gxJ9kecSUPsSUxZNza2VsIHF0Ow=BJp6-ioHTL
>>>
>>> As someone who uses this boundary data relatively frequently, there's
>>> no reason why I should use OSM when the data is incomplete, and
>>> boundaries in OSM may have been altered (accidentally or otherwise).
>>> They're not surveyable, the data is freely available elsewhere - I
>>> don't see why it's worth spending our time making sure it's replicated
>>> in OSM.
>>>
>>> Cheers,
>>>
>>> Russ
>>>
>>> On Wed, 16 Feb 2022 at 11:27, David Davis via Talk-gb-london
>>>  wrote:
>>> >
>>> > Hello,
>>> > a complete revamp of the electoral wards in Lambeth borough comes into
>>> effect in May 2022, with 25 new wards.
>>> > (See
>>> https://love.lambeth.gov.uk/a-new-political-map-for-the-2022-lambeth-borough-council-elections/
>>> for info).
>>> >
>>> > I'm guessing the boundaries are available as open data,
>>> > and some bright spark on this list will know how to import it into OSM
>>> in a hugely more efficient way that me trying to manually draw and tag the
>>> new boundaries...?
>>> > (Amusingly, on the map on Lambeth Council's page about it, someone
>>> literally has just drawn the boundaries by hand on top of a screengrab from
>>> OSM!)
>>> >
>>

Re: [OSM-talk-fr] Multipolygone brayé, mais je ne trouve pas où

[David Marchal via Talk-fr]

Bonjour, Christian.

Oui, bon, fatalement, le rendu était tout caca… C’est corrigé, merci beaucoup !

Cordialement.

Sent with ProtonMail Secure Email.

--- Original Message ---

Christian Quest  schrieb am Sonntag, 20. Februar 2022 
um 20:07:

> Le 20/02/2022 à 19:15, David Marchal via Talk-fr a écrit :
>
> > Salut, la liste !
> >
> > Hier, j’ai ajouté un membre inner à un multipolygone 
> > (https://www.openstreetmap.org/relation/297388) mais, maintenant, il 
> > apparaît tout cassé au rendu, alors que le validateur JOSM ne signale rien 
> > d’anormal. Quelqu’un pourrait y jeter un œil et me dire ce qui cloche ? Je 
> > comprends pas…
> >
> > Dans l’attente de vos lumières,
> >
> > Cordialement.
>
> JOSM me détecte ça:
>
> https://www.openstreetmap.org/relation/297388#map=19/48.05379/7.06031
>
>
> --
>
> Christian Quest - OpenStreetMap France
>
> Talk-fr mailing list
>
> Talk-fr@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Multipolygone brayé, mais je ne trouve pas où

[David Marchal via Talk-fr]

Salut, la liste !

Hier, j’ai ajouté un membre inner à un multipolygone 
(https://www.openstreetmap.org/relation/297388) mais, maintenant, il apparaît 
tout cassé au rendu, alors que le validateur JOSM ne signale rien d’anormal. 
Quelqu’un pourrait y jeter un œil et me dire ce qui cloche ? Je comprends pas…

Dans l’attente de vos lumières,

Cordialement.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[David Davis via Talk-gb-london]

Yeah Tom,
this is conclusion I reached too:
if a ward boundary is legally defined as being a particular geographical
feature (e.g. centre line of a road) then it is better to have that way on
OSM tagged with a relation (even if its position is a metre or two off
perfect) rather than have another line imported and tagged as the boundary.
And probably even worse: if the road *is* in precisely the right position,
neither is it helpful to have another imported line superimposed right on
top of it, as it makes it very fiddly to try and edit them subsequently.
So, slightly timeconsuming as it is, I think it's probably best to set them
up manually.

On Thu, Feb 17, 2022 at 1:55 PM Tom Chance  wrote:

> I've previously found it valuable to have the ward boundaries in OSM, and
> am responsible for all the Southwark (not Lambeth) ward boundaries, plus a
> few Lambeth, Croydon and Bromley. Sometimes the misalignment of open data
> and OSM data can lead to mistakes. It's not a big deal if they aren't in,
> but I don't see any reason to say they *shouldn't* be.
>
> If you're going to update them (great!) I think they work better as
> relations using - where relevant - existing objects like roads where they
> go down the middle of a road. Otherwise, again, things can get misaligned
> and otherwise go wrong. So a straight import isn't as good an option as the
> rather more painstaking manual approach.
>
> Tom
>
> m: 07866 447 075
> w: http://tomchance.org
>
>
> On Wed, 16 Feb 2022 at 11:46, Russ Garrett  wrote:
>
>> My controversial opinion is that these shouldn't be in OSM.
>>
>> The definitive boundaries are freely available as open data in OS
>> Boundary Line (although they won't usually appear there until after
>> the boundaries take effect). The current UK-wide coverage of ward
>> boundaries in OSM is pretty minimal, although it looks like most of
>> the old Lambeth wards are in OSM:
>>
>>
>> http://overpass-turbo.eu/?q=W291dDpqc29uXVt0aW1lxIHEgzI1XTsKKAogIG53clsiYsSBbmRhcnkiPSJwb2xpxItjYWwixInEqMSqxKxpxK5sX2RpdmlzacSHxKYid8SjZMSxKHt7YsSfeH19KcSUxY8KxI8gxJ9kecSUPsSUxZNza2VsIHF0Ow=BJp6-ioHTL
>>
>> As someone who uses this boundary data relatively frequently, there's
>> no reason why I should use OSM when the data is incomplete, and
>> boundaries in OSM may have been altered (accidentally or otherwise).
>> They're not surveyable, the data is freely available elsewhere - I
>> don't see why it's worth spending our time making sure it's replicated
>> in OSM.
>>
>> Cheers,
>>
>> Russ
>>
>> On Wed, 16 Feb 2022 at 11:27, David Davis via Talk-gb-london
>>  wrote:
>> >
>> > Hello,
>> > a complete revamp of the electoral wards in Lambeth borough comes into
>> effect in May 2022, with 25 new wards.
>> > (See
>> https://love.lambeth.gov.uk/a-new-political-map-for-the-2022-lambeth-borough-council-elections/
>> for info).
>> >
>> > I'm guessing the boundaries are available as open data,
>> > and some bright spark on this list will know how to import it into OSM
>> in a hugely more efficient way that me trying to manually draw and tag the
>> new boundaries...?
>> > (Amusingly, on the map on Lambeth Council's page about it, someone
>> literally has just drawn the boundaries by hand on top of a screengrab from
>> OSM!)
>> >
>> > Anyone interested this task?
>> >
>> > (A few of the existing Lambeth wards were tagged on OSM already, but
>> the majority actually weren't. But every existing ward boundary is changing
>> in any case...)
>> > ___
>> > Talk-gb-london mailing list
>> > Talk-gb-london@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-gb-london
>>
>>
>>
>> --
>> Russ Garrett
>> r...@garrett.co.uk
>>
>> ___
>> Talk-gb-london mailing list
>> Talk-gb-london@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-london
>>
>
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

[Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[David Davis via Talk-gb-london]

Hello,
a complete revamp of the electoral wards in Lambeth borough comes into
effect in May 2022, with 25 new wards.
(See
https://love.lambeth.gov.uk/a-new-political-map-for-the-2022-lambeth-borough-council-elections/
for info).

I'm guessing the boundaries are available as open data,
and some bright spark on this list will know how to import it into OSM in a
hugely more efficient way that me trying to manually draw and tag the new
boundaries...?
(Amusingly, on the map on Lambeth Council's page about it, someone
literally has just drawn the boundaries by hand on top of a screengrab from
OSM!)

Anyone interested this task?

(A few of the existing Lambeth wards were tagged on OSM already, but the
majority actually weren't. But every existing ward boundary is changing in
any case...)
___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london

Re: [talk-au] Deletion of walking tracks/paths

[David Wales via Talk-au]

In my area there are walks which are:

1. In a published local guide
2. Practically invisible on the ground, except for bits of red tape hanging 
from tree branches every 50-100 metres!
3. Definitely unofficial

I've traced them from my personal GPX recordings, and named them according to 
the name in the guide (with permission from the author of the guide).

Is this good practice? Or bad practice?

Regards,
David Wales

On 25 January 2022 7:53:18 pm AEDT, Andrew Harvey  
wrote:
>On Tue, 25 Jan 2022 at 19:22, Little Maps  wrote:
>
>> Hi Andrew, thanks for compiling the walking tracks page, it’s a great
>> resource. It would be good to extend this later on to have separate pages
>> for walking tracks, vehicle tracks and MTB paths, since these issues keep
>> coming up on the forum.
>
>
>Good idea, and eventually these pages could be linked to from
>https://wiki.openstreetmap.org/wiki/Australian%20Tagging%20Guidelines.
>Vehicle tracks should be less controversial and easier. MTB paths is a can
>of worms, I feel the global tagging practises aren't quite there yet, but
>happy to help out with a page.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Review of road surface tags in Victoria

[David Bannon]

What a brilliant piece of work !  And a good outcome too. 
Thanks for that effort.
David
On Fri, 2021-12-03 at 14:22 +1100, Little Maps wrote:
> Hi folks, for anyone interested in rural roads, I’ve put together a
> very nerdy review of the super accuracy of OpenStreetMap’s road
> surface tags (sealed vs unsealed) in Victoria. Lots of maps and
> tables. Hope you find it informative. Cheers Ian
> 
> 
> https://littlemaps692810600.wordpress.com/2021/12/03/openstreetmap-on-australian-roads-how-accurate-are-road-surface-tags-in-victoria/
> 
> 
> ___Talk-au mailing 
> listtalk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-transit] [Talk-GB] Mapping train services in Great Britain

[David Lichti]

Am 01.06.21 um 21:25 schrieb Jarek Piórkowski:

Yes, and some people would like to use this free (Free),
computer-readable dataset to find out whether you should take the
train from Windsor and Eton Central or Riverside.

While other are giving advice on whether it is wise to even try to do this.

Doing timetabling software development for a living, I can tell you that 
train operators and infrastructure managers are paying hordes of 
planners using very complex and specialized tools to manage their 
schedules. This is far beyond the scope and intent of OSM.


OSM is a mapping tool, not a scheduling tool. If you want intermodal 
routing, a combination of OSM with any reliable schedule data source is 
the way to go.


Hälsningar

David


OpenPGP_0x93A7B015199383B9.asc
Description: OpenPGP public key


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

Re: [Talk-GB] UK street addressing

[David Woolley]

On 21/12/2020 11:14, Richard Fairhurst wrote:
More philosophically, post towns violate the “on the ground” principle. 
No one here writes their address as Chipping


Addresses used by local people can also violate the on the ground 
principle. The place name I was given when I moved in appears to have 
been invented by estate agents, and doesn't appear on maps.



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

Re: [Talk-GB] UK street addressing

[David Woolley]

On 20/12/2020 23:21, SK53 wrote:
I'm aware of a number of terraces which are discontinuous, demonstrating 
that individual houses in a terrace are not building:part.


There is a set of maisonettes, which are both semi-detached 
horizontally, and split into four groups, with roads between them, 
around a roundabout, near me.  The individual maisonettes are numbered 
separately from the main street numbers, the development as a whole has 
no street number of its own, and actually has presences on roads with 
three different names!


It actually confuses the council's fly tip and street defect reporting 
app, which tends to reverse geocode it as though the maisonette's were 
directly numbered on the relevant road.  They failed to find one broken 
sign because of that.


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

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[David Woolley]

On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
Also, the steps should have bicycle=dismount, not =yes. This will allow 
people who can't dismount to go around by the road.


Only if it is illegal to try to cycle up and down the steps.  Otherwise 
it is the duty of the renderer (router) to infer that this will be 
necessary because of the steps.


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

Re: [Talk-GB] driveway-becomes-track

[David Woolley]

On 12/12/2020 21:11, Martin Wynne wrote:
What I'm wondering is how the typical recreational country walker would 
find that map, 


Your first problem would be establishing a funding model for it; OSM, in 
general, is not funded to a level that would support large scale end 
user use.


> or get it on their mobile phone app in place of the awful

Google maps? It's a lot of work to create if no-one ever uses it?


Google maps, as used in phones, are vector maps, with the rendering done 
in the phone itself


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

Re: [Talk-GB] driveway-becomes-track

[David Woolley]

On 12/12/2020 13:20, Nick wrote:

Would changing this to Tag:highway=bridleway be a starting point?



I think the OP was saying there is a separate bridleway, almost parallel 
to the feature in question.


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

Re: [Talk-GB] Bridleway across field

[David Woolley]

On 08/12/2020 15:11, nathan case wrote:

I am interested as a path I recently mapped is a PROW but is very dangerous to 
cross. It is now marked as disused:highway=path with 
access=discourged;designated but it is stilla PROW (byway open to all traffic 
in this case):https://www.openstreetmap.org/changeset/93427676


In that example, "Cross Bay Walk - DO NOT ATTEMPT" violates "name is 
only the name".  It may or may not be possible to justify "Cross Bay 
Walk", but the "DO NOT ATTEMPT" is not going to be a valid part of the name.


Unless there is a sign saying "unsuitable for pedestrians, horses, and 
vehicles", or similar, I would say "access=discouraged" violates "do not 
tag for the renderer".  The wiki specifically says that an official sign 
is required before using "access=discouraged".


"warning" appears to be non-standarised, and also subjective.

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

Re: [OSM-talk-fr] Tag pour une commande par téléphone ou internet 48h avant le retrait

[David Crochet]

Bonjour

Le 07/12/2020 à 17:37, emeric Prouteau a écrit :

Auriez vous des idées pour cela ?


opening_hours=* "reservation by phone 48h before" ?

Cordialement

--
David Crochet


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

Re: [Talk-GB] No U-turn on a long stretch of road

[David Woolley]

On 05/12/2020 12:39, Edward Bainton wrote:

Any established tagging system?

The turn restriction wiki 
 envisages 
turn restrictions at junctions only; my case is along the length of a 
major road (~3km). There's no barrier to prevent it, but presumably 
routing engines ought to know that route correction after a wrong turn 
will have to wait until the next roundabout.




That's a subjective judgement, so would be tagging for the renderer. 
The renderer (in this case a router) should be using some sort of 
heuristic like only  permitting U turns on residential or service roads, 
and giving a heavy weighting to the use of formal junctions at the the 
expense of distance travelled.  A real human would consider actual 
traffic levels and sight distances but they would be difficult to 
capture on the map and time and season dependent.


I think No U Turn signs tend only to be used where traffic volumes or 
junction structures, might otherwise suggest U turns were acceptable.


I don't think any driver (or autonomous vehicle) should be making U 
Turns based solely on the instructions of an automated router.


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

Re: [Talk-GB] Idea - OSMUK walkers' map application

[David Woolley]

On 04/12/2020 16:38, Nick Whitelegg via Talk-GB wrote:
However as you say council take up could be problematic. Maybe we could 
provide a link to FixMyStreet?


Some councils insist that problem reports only come through their own 
web sites, or reluctantly, by phone, and will ignore emails (which is 
the default presentation for FixMyStreet).


The web sites generally provide structured input, whereas FixMyStreet is 
generally free text, and also, the web site sometimes bypasses the 
council contact centre, and goes direct to the out sourced contractor.


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

Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

[David Woolley]

On 01/12/2020 10:11, Tom Hughes via Talk-GB wrote:

Of course it's only claiming they do have a copyright that they
can make such a license necessary.


Not necessarily.  If you can establish a contract at every stage in the 
chain, you may be able to impose restrictions that go beyond copyright.


More interesting here is whether it is actually copyright or database 
rights that are at stake.  I think scanning only creates a new copyright 
on the typographical arrangement, and doesn't affect the database 
rights.  However, because there may be contractual restrictions, and 
because it might put OS into a bad position with their supplier, I would 
suggest that one obeys the restrictions that OS are imposing.



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

Re: [OSM-talk-fr] taille des changeset

[David Faure via Talk-fr]

On samedi 28 novembre 2020 13:12:02 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Ça a l'air bon.

Cool, merci à toi et à Marc pour les retours.

Je viens de procéder à l'import initial, tout s'est bien passé.

Un exemple de changeset :
https://www.openstreetmap.org/changeset/94950838
ou plus exotique :
https://www.openstreetmap.org/changeset/94950984

Je relancerai le script tous les weekends maintenant que tout est automatisé
(mais je vérifie les premiers changesets à la main bien sur).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] taille des changeset

[David Faure via Talk-fr]

On vendredi 27 novembre 2020 12:54:11 CET Marc_marc wrote:
> Bonjour,
> 
> >> 1 537 changets pour 9 730 objets.
> >> Ça fait quand même vraiment beaucoup de changesets.
> > 
> > Vraiment ? Avec StreetComplete j'ai fait 764 changesets
> > pour 2727 objets,
> 
> cela dépend beaucoup de ce que tu fais.
> 
> un contributeur qui modifie un café dans un aéroport à Paris
> et un autre café à l'aéroport de Hong-Kong serrait bien avisé
> de ne pas envoyer ces 2 modifs dans le même changeset couvrant
> la moitié du monde. ce ne sont pas les mêmes contributeur pouvant
> vérifier les 2.
> 
> à l'inverse si tu te balade sur les Champs-Élysées pour renseigner
> toutes les lampadaires, il y a aucun soucis à faire un changeset
> même si au final cela te fait 1000 objets en une fois.
> et faire diviser cela tous les 10 lampadaires ne serrait
> agréable pour personne.
> 
> par comparaison :
> - le projet mondial d'import des stations d'essence (qui n'avaient
> pas abouti) avait conduit à diviser pour avoir au moins un changeset
> par pays.
> - les opérations de masses dument approuvée pour virer le bug
> de wheelchair map avait conduit à un changeset par pays pour
> les pays les plus affectés puis à un changeset par continent
> pour le solde, personne n'avait objecté.

OK, bon, pour essayer que tout le monde soit content je coupe la poire en 
deux. J'ai agrandi très largement l'aire maximale pour les changements
(le concept reste pour au moins éviter de mettre les DOM-TOM dans le même 
changeset que la France métropolitaine).

Maintenant ça me donne 66 changesets 8780 objets (et ça inclut la séparation 
des deux types de changesets, ajout de PH=off, et mettre quand c'est vide).

Je commence avec les PH=off.
https://www.openstreetmap.org/changeset/94938297

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On jeudi 26 novembre 2020 15:23:03 CET Frédéric Rodrigo wrote:
> Le 26/11/2020 à 10:09, Marc_marc a écrit :
> > Le 25.11.20 à 21:39, David Faure via Talk-fr a écrit :
> >> Bonjour à tous,
> >> 
> >> Voici un résumé de l'état des choses concernant cet import
> > 
> > pour ma part un import doit être limpide, donc si je résume
> > la première étape :
> > - ne cibler que ceux qui n'ont pas d'horaire cad ne pas toucher les
> > objets qui ont opening_hours ni opening_hours:covid19 (parce qu'on sait
> > pas si osm a une version corrigée des horaires théoriques ou non)
> > - ne pas mixer 2 sujets dans le même changeset, cad ne profiter de
> > l'ajout d'horaire sur certains pour corriger des PH manquant sur
> > d'autre: c'est telement plus propre un changeset séparé qui
> > dit "ajout de PH manquant dans les horaires existant".
> 
> +1

On pinaille un peu non ?
C'est le même sujet, c'est "utilisation des horaires fournis par datanova".

Soit parce qu'il n'y en avait pas, soit parce la différence est seulement 
PH=off. A l'avenir il pourrait y avoir d'autres raisons qu'on considère 
acceptables...

> >> Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de
> >> poste.
> > 
> > pq pas si t'as envie... mais un import avec des changeset n'ayant
> > parfois qu'un bureau, cela limite l'intérêt du changeset.
> > perso un changeset pour la france ou un par région, cela me choque
> > pas, ces bureaux n'avaient de toute façon pas d'horaire.
> > mais peu importe ton choix à ce niveau, ce point est pour moi ok,
> 
> Même avis ici aussi.
> 
> 1 537 changets pour 9 730 objets. Ça fait quand même vraiment beaucoup de
> changesets.

Vraiment ? Avec StreetComplete j'ai fait 764 changesets pour 2727 objets, si 
je comprends bien le "764 Modifications" affiché sur 
https://www.openstreetmap.org/user/Dfaurekde
et le 2727 affiché en haut à gauche dans StreetComplete.

L'idée c'était d'éviter les notifications intempestives, puisqu'apparemment 
certains monitorent une zone bien spécifique et ne veulent pas recevoir de 
notifications intempestives liées à un changement à grande échelle.
D'un autre côté, ça arrive super souvent, non ?
Un exemple au hasard: https://www.openstreetmap.org/changeset/94106441
(merci à toi zorglubu, d'intégrer + de bureaux de postes, ça va m'aider !)

Je peux ajuster la taille de la zone max pour créer moins de changesets.
Mais ... ça change quoi au final ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import d'horaires et :covid19

[David Faure via Talk-fr]

On mercredi 25 novembre 2020 22:27:34 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Bonjour, les messages de Marc et de David sont l'occasion de rappeler à
> propos des horaires que quand on a une source fiable, on n'a pas à se
> poser la question de savoir si on doit ou pas avec un suffixe :covid19.

Ah, en effet.

> Du coup je propose (en dehors du script histoire de ne pas engendrer des
> aller-retours) de supprimer les opening_hours:covid19 si on met à jour
> opening_hours automatiquement.

Ca ne rentre pas tout a fait dans mon approche conservative..
Je ne touche pas aux bureaux avec opening_hours, donc :
- ceux qui ont opening_hours et opening_hours:covid19, j'y touche pas
- ceux qui ont *seulement* opening_hours:covid19 (il y en a 788), oups, il faut 
prendre ça en compte :

* 139 disent "open", bon, on peut laisser ça et importer opening_hours.
* 448 disent "off", ça rentre dans le "désaccord" et du coup je ne devrais pas 
y toucher. Même si je suspecte fortement que ça date du premier confinement et 
que c'est maintenant ouvert, comme indiqué par datanova.
* et 201 ont de vrais horaires, mais différents de ceux de datanova, donc 
pareil, pas touche...

> Ce sont peut-être en partie les bureaux que David trouve avec des
> horaires en conflits OSM <> Datanova.

Ceux qui n'ont rien dans opening_hours sont de nouveaux conflits :-)

Du coup, 649 imports de moins.

Mais bon faut relativiser, y'a jusqu'à 5376 imports potentiels en plus, qui ne 
se font pas parce que la ref:FR:LaPoste est manquante dans OSM.
Donc clairement ce qui aidera le plus après l'import initial, c'est de terminer 
l'intégration de l'import des bureaux de poste (beaucoup de ref manquantes).
http://osmose.openstreetmap.fr/fr/map/#zoom=9=44.147=4.729=7050%2C8020%2C8021%2C8022=1%2C2%2C3=post=

> Auquel cas ça faut le coup de supprimer opening_hours:covid19 si on met
> à jour opening_hours automatiquement.

Avec l'approche conservative de "si y'a, je touche pas", ça veut dire que je ne 
supprime pas opening_hours:covid19
non plus. Sauf si on décide que c'est un cas où on veut donner priorité aux 
données de la poste, mais difficile d'être sûr
de si c'est 100% correct. Je crains toujours le cas d'une ref:FR:LaPoste 
incorrecte (suite à renumérotation par exemple).
Donc je donne priorité à "la fourmi sur place", je ne fournis des données "que" 
pour les 8889 cas où il n'y a pour l'instant aucune info.
C'est déjà pas mal :)

> David, c'est donc ma proposition pour gérer une partie des cas refusés
> pour le moment : on compare avec opening_hours:covid19, si c'est bon on
> supprime opening_hours:covid19 et on met opening_hours à jour.

Malheureusement j'ai 0 cas où datanova == opening_hours:covid19...

Les choses ont changé depuis mars, aucun bureau n'a les mêmes horaires 
maintenant qu'en mars...
Exemple au hasard :
17129A: no opening_hours but covid hours: Mo-Fr 09:00-12:00,14:00-17:00, 
datanova: Mo-Fr 09:00-18:30; Sa 08:30-12:30; PH off

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour à tous,

Voici un résumé de l'état des choses concernant cet import, après les 
discussions ici (et aussi en privé avec Jean-Yvon qui m'a donné de nombreux 
bons conseils).

Pour rappel, tout est documenté sur :
https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours

J'ai de quoi importer des horaires pour 9730 bureaux de poste identifiés dans 
OSM par leur référence LaPoste. La plupart n'ont pas du tout d'horaires pour 
l'instant, et pour 183 d'entre eux les horaires collent sauf qu'il manque "PH 
off" à la fin, je propose donc de l'ajouter pour que soit exactement égal.

Au lieu de la manip manuelle initialement suggérée (avec JOSM),
j'ai maintenant le code qui va bien pour découper en changesets, chacun étant 
limité à une région de 500m² pour éviter les notifications sur une trop grande 
zone.
Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de poste.

Vu les discussions précédentes, je ne touche pas à l'attribut source, 
seulement à opening_hours. Je ne touche pas non plus aux 1057 bureaux qui ont 
un horaire différent dans OSM et datanova. On verra plus tard pour l'idée 
d'ajouter un fixme ou d'utiliser osmose pour montrer ces différences.
On verra aussi plus tard pour intégrer "collection_times". Autant faire 
incrémental.

L'upload de ces changesets est scripté lui aussi, avec osm-bulk-upload.
J'ai testé les scripts sur un bureau de poste prêt d'ici, tout marche.

A ce stade, je me sens donc prêt à uploader tout ça, mais c'est l'occasion de 
faire un dernier point ici pour avoir votre accord d'abord.

Par la suite, ces mêmes scripts mettront à jour les horaires modifiés par 
datanova, si personne n'y a touché dans OSM entre temps. Tout est déjà codé et 
testé pour pouvoir faire ça. Je pense le lancer tous les week-ends, pour bien 
avoir des horaires à jour, y compris quand un bureau décide d'une fermeture 
exceptionnelle pour la semaine suivante.

OK pour tout le monde ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[David Crochet]

Bonjour


Le 25/11/2020 à 15:08, Marc_marc a écrit :

mais pq utiliser l'url de dev alors que c'est en prod
soushttps://bano.openstreetmap.fr  ?



Car https://bano.openstreetmap.fr/20km_chacun.html ne répond pas alors 
que https://dev.osm162.openstreetmap.fr/20km_chacun.html# oui


Cordialement

--
David Crochet

--
David Crochet


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

[OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[David Crochet]

Bonjour

Firefox n'aime pas https://dev.osm162.openstreetmap.fr/ car il lui 
manque quelque chose (un certificat pour faire du 's' en http ?)


Cordialement

--
David Crochet


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

Re: [Talk-GB] Indicating an information board is broken?

[David Woolley]

On 24/11/2020 17:28, Ken Kilfedder wrote:


They'll probably fix it, and the map can stay unchanged.



Although, either way, I don't think this is something to map in OSM, 
councils seem to consider fixing street name signs very low priority.  I 
think one argument they use now is that everyone has sat navs.  That 
causes a chicken and egg problem if OSM is the source for the sat nav!


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

Re: [Talk-GB] electric fences

[David Woolley]

On 23/11/2020 22:13, Gruff Owen wrote:
For Public RIghts of Way, it is highly unlikely that this structure has 
been authorised by the Highways Authority.


Some West Country counties seem to accept electric fences across public 
footpaths, see the last item in 
.


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

Re: [OSM-talk-fr] tag opening_hours vers texte

[David Faure via Talk-fr]

On samedi 21 novembre 2020 20:11:27 CET Noémie Lehuby via Talk-fr wrote:
> Bonjour,
> 
> Vous connaissez un service qui serait capable de transformer un tag
> opening_hours en texte intelligible par un humain ?
> 
> Par exemple "Mo-Fr 09:30-12:00,13:30-18:00" deviendrait "du lundi au
> vendredi de 9h30 à 12h puis de 13h30 à 18h"
> 
> Il me semble avoir déjà entendu parler d'un lib qui ferait ça mais je
> n'arrive pas à remettre la main dessus...

Il existe https://github.com/rezemika/humanized_opening_hours

mais c'est plus vraiment maintenu, cf tout dernier message sur
https://zestedesavoir.com/billets/2653/quelques-statistiques-sur-le-champ-opening-hours-dopenstreetmap/?page=1#p227797

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [Talk-GB] Footways bikes can go on

[David Woolley]

On 21/11/2020 15:46, Mateusz Konieczny via Talk-GB wrote:

there is also bicycle=permissive (based on access=permissive) for
"permitted right now but can be revoked/changed at any time"


The way seems to be in a park, and, in general, permissive is the 
maximum legal status of any path in a park, unless it is also a 
bridleway or public footpath, in the definitive map.




In general modelling "clearly illegal but accepted and normal" is 
problematic

for access/parking tagging in OSM.



There is a modal filter near me, on a temporary traffic regulation 
order.  It has been flouted for all the three months that it has 
existed.  However it is clearly signed as emergency vehicles (and 
non-motor vehicles) only.  In that case accepted use shouldn't represent 
how it is mapped.  (It also has enforcement camera signs, and it might 
be interesting to find how many fines they collect if they do install 
the cameras.  I suspect the abuse will stop until they are moved elsewhere.)


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

Re: [OSM-talk-fr] ascenseur

[David Crochet]

Bonjour

Le 21/11/2020 à 12:51, leni a écrit :
Si je met les "entrance=yes" + "door=sliding", des deux niveaux, 
superposés, Josm m'indique "nœuds à la même position" bien qu'il y ait 
layer=1


Les décaler de 5 cm ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Suffixe :covid19

[David Faure via Talk-fr]

On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> créé pour le premier confinement, lorsque beaucoup de monde espérait
> qu'il soit de courte durée et enraye la pandémie.
> La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> fonctionnement "classique". D'ici quelques semaines (croisons les
> doigts), on aura la même situation : déconfinement, peut-être
> couvre-feu, mais néanmoins covid19 toujours présente.
> 
> Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> confinement (et couvre-feu etc.), il est donc difficile de connaître son
> application. De plus, même si l'on dit qu'il ne s'applique que pour le
> confinement, il est difficile de savoir si les horaires (ou autre) sont
> revenues à la version pré-confinement, sont restées telle-quelles ou ont
> été modifiées.
> 
> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> gérer ces modifications comme des changements classiques ? Que ce soit
> pour les descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par
> la plupart des applications, contrairement aux suffixes :covid19. Cela
> engendre des contradictions si les contributeurs ou applications ne
> gèrent pas les deux.

Je suis 100% d'accord.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On lundi 16 novembre 2020 17:44:24 CET Jérôme Amagat wrote:
> Je suis d'accord, aucune solution n'est parfaite. Mais dire, on supprime
> source=* car la source est quelque part dans l'historique de l'objet, je
> n'y vois pas la solution miracle, loin de là.
> 
> Il faut revenir au sujet de cette discussion, on parle de modifier un tag
> sur 1000 objets en France. 

1.

> Est ce qu'au niveau mondial, il a été décidé de
> supprimer le tag source=* ? A ma connaissance non.
>
> Je ne vois pas de problème à parler de la façon d'indiquer la source, mais
> le principal ici, c'est d'aider David pour son import en se limitant à
> l'usage aujourd'hui. 

Merci pour le recentrage de la discussion, je suis tout à fait d'accord :-)

> Et pour moi, ça veut dire, (toujours pour son
> changeset sur les heures d'ouverture), on ne touche pas à source=*, et on
> met la source sur le changeset

Je suis d'accord.

> on peut aussi l'ajouter dans source:opening_hours=* mais pas d'obligation.

J'hésite à le faire. Le danger, c'est que si un contributeur corrige les 
opening_hours dans le cas ( peu probable :) ) où ils seraient incorrects alors 
son éditeur ne modifierait/supprimerait probablement pas l'attribut 
source:opening_hours. Sauf si je me trompe sur le comportement des éditeurs 
actuels. Du coup on aurait une source fausse, alors que si on n'utilise pas 
source:opening_hours alors c'est clair, pour trouver la source (et le 
coupable) faut aller voir le changeset.

> Et si un jour, il est décidé que le tag source=* était superflu, il sera
> facile de le supprimer à ce moment-là.

Tout à fait d'accord.

Sur le problème de l'attribut source=* existant mais pas forcément 100% 
correct, j'y vois un parallèle avec les copyrights dans les fichiers sources 
des programmes opensource. Le copyright indique souvent l'auteur d'origine 
(tout comme l'attribut source: d'OSM) même si d'autres ont fait des modifs par 
la suite. C'est un fait connu, et si on veut savoir qui a fait quoi 
exactement, on regarde les commits git, donc l'équivalent des changesets dans 
OSM.

Par contre ce qui me manque dans mon parallèle avec le développement 
opensource, c'est le "approved" sur les merge requests :)
J'ai du mal à savoir si c'est OK pour que je procède, que ce soit ici ou sur 
imports@ où j'ai finalement décrit mon import (et eu très peu de retour, juste 
un "This all sounds very good.", un +1, et quelques questions auquel ma page 
wiki répondait).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [Talk-GB] Service road with private locked gate and routing apps

[David Woolley]

On 16/11/2020 11:18, Mat Attlee wrote:
Upon surveying this service road it is very much closed to the public 
with locked gates which I marked as thus 
https://www.openstreetmap.org/changeset/93935943


However these routing apps still use this service road. Have I missed 
something or does it take a while for the changes to propagate?


It takes time for routing engines to update.  However, I would also have 
put access tags on the service road.


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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 13:38:29 CET Éric Gillet wrote:
> Le 15/11/2020 à 12:25, David Faure via Talk-fr a écrit :
> > Je suis d'accord avec toi sur le fond. Mais clairement la communauté OSM
> > n'est pas (encore) de cet avis là.
> 
> Tous les éditeurs ont migré vers les tags de changeset pour indiquer la
> source, "la communauté" est donc à priori de cet avis.

De l'avis de mettre la source dans le changeset, oui.
De l'avis de supprimer la source de l'objet, non.
 
> Si je comprends bien tu es d'accord avec les problèmes que ça engendre,
> que la solution que je propose est la bonne mais ne va pas l'appliquer.

Je suis d'accord que l'attribut source n'aurait jamais dû être mis sur 
l'objet, c'était une erreur de design dès le départ (vision trop court terme).

Mais même si je suis moi-même convaincu, je ne peux pas appliquer une 
*suppression* de données si plusieurs personnes sont contre -- ce qui est 
clairement le cas.

Je ménage mon risque. Quelqu'un qui trouve que mon script n'aurait pas dû 
supprimer un attribut, aura un bon argument pour effectuer ou demander un 
revert. Alors que quelqu'un qui trouve que mon script aurait dû "en faire 
plus", et bien il peut faire ce plus séparément (ou moi, mais en tous cas, pas 
de revert).

> c'est comme si dans tu avais mis dans ton changeset source=A; B

Ça c'est le point avec lequel je ne suis pas d'accord; mon changeset dit 
source=B pour les attributs qu'il modifie. Et par contre la source A 
originelle est celle qui me fournit l'existence du bureau de poste dans OSM, 
son identifiant ref:FR:LaPoste, donc oui je m'appuie bien sur le source A au 
final. Mais c'est pas ambigü, on voit bien ce qui provient de B quand on 
regarde le changeset.

> Désolé de t'avoir fait perdre du temps, je te souhaite bonne
> continuation pour ton import !

Merci :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 11:10:10 CET Éric Gillet wrote:
> > Eric, la modification de wiki nécessaire à ceci (celle à laquelle je
> > pensais en fait) c'est la suppression de "it seems the historic practice
> > of tagging objects or individual attributes has not been officially
> > deprecated yet". Le jour où c'est vraiment déprécié, alors pas de
> > problème pour supprimer, mais clairement ce n'est pas l'avis de tout le
> > monde.
> 
> Pas besoin de déprécier dans ton cas, il n'y a pas d'autres solution que
> de l'enlever pour faire une modification avec une source différente.
> 
> Si tu le laisse, on peut pas savoir à quoi s'applique la source qui est
> sur l'objet et celle qui est dans ton script, à moins de lire son code
> source pour voir ce qu'il vérifie/modifie comme attribut (et faut faire
> pareil pour chacune des version des objets OSM).

Je suis d'accord avec toi sur le fond. Mais clairement la communauté OSM n'est 
pas (encore) de cet avis là.

Quand j'ai modifié les horaires d'ouverture d'un magasin avec l'éditeur ID,
et que j'ai mis source=survey pour le changeset, est-ce que ID a supprimé 
l'attribute source du magasin ? J'en doute.

Quand j'ai renseigné les horaires d'ouverture d'un bureau de Poste avec 
l'application StreetComplete (ce qui m'a donné l'idée de ce projet), est-ce 
que StreetComplete a supprimé l'attribut source du bureau de Poste ?
Non, je confirme que ce n'est pas le cas.
https://www.openstreetmap.org/api/0.6/changeset/92125368/download

Dans ce cadre, il me semble pas raisonnable que mon import soit le premier à 
faire ce genre de choses.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 00:57:22 CET Jérôme Amagat wrote:
> En modifiant le tag opening_hours=*, seule la source dans
> source:opening_hours=* peut être modifiée ou supprimée.

Sauf qu'on a dit que je ne modifiais pas le tag opening_hours s'il était déjà 
là, donc je ne touche pas non plus à source:opening_hours...

Bon, je constate un manque évident de consensus sur la suppression de 
l'attribut source, et je dois donc me ranger avec le camp plus conservateur.

Surtout que c'est pas vraiment pour faire le ménage que je suis venu :)

Eric, la modification de wiki nécessaire à ceci (celle à laquelle je pensais 
en fait) c'est la suppression de "it seems the historic practice of tagging 
objects or individual attributes has not been officially deprecated yet".
Le jour où c'est vraiment déprécié, alors pas de problème pour supprimer,
mais clairement ce n'est pas l'avis de tout le monde.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 21:34:52 CET Éric Gillet wrote:
> Le 14/11/2020 à 21:05, David Faure a écrit :
> > On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:
> > Si quelqu'un change le wiki, je fais :-)⎄
> 
> Je l'ai fait en français et anglais :

OK, merci, j'ai remis la suppression de 'source' dans le script.

Je suis quasiment au bout de la TODO list, je pense que je vais pouvoir faire 
l'import demain, à moins qu'il y ait des objections.

Cf https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours
pour tous les détails sur ce qui est fait par le script, etc.

Je peux aussi fournir un "diff" du XML d'openstreetmap si qqn veut jeter un 
oeil, mais bon c'est pas facile à vérifier :-)
http://www.davidfaure.fr/2020/osm_post_offices_xml.diff  [8.5 Mo]

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:
> Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> > On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
> >> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
> >>>> Et il faut garder les anciennes sources (sauf les anciennes versions de
> >>>> ce que tu importes).
> >>>> 
> >>>> Typiquement tu auras des source
> >>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> >>>> 
> >>>> Il ne fallait pas supprimer la source du bâti (par exemple).
> >>> 
> >>> Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais
> >>> il
> >>> ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
> >>> disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
> >>> touche pas.
> >> 
> >> Je penses que la phrase du wiki "so don't go around deleting those
> >> source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
> >> c'est pour éviter que des contributeurs suppriment/modifient en masse
> >> "uniquement" un tag.
> > 
> > Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
> > implémenter ça.
> > 
> > Mais depuis j'ai vu
> > "Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
> > supprimer ces marques avant qu'une décision générale du projet décide de
> > le faire."
> > https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_le
> > s_objets_et_les_attributs
> > 
> > Et pareil dans la version anglophone, " As usual don't start deleting
> > those tags unless and until there is a general project decision to do so.
> > "> 
> >> [...]
> >> La source précédente (celle existante sur l'objet) n'est pas perdue,
> >> elle est stockée dans l'historique de l'objet. Tout comme le tag
> >> source=* que tu apposes aux changesets.
> > 
> > Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas
> > aller supprimer un attribut si le wiki dit "c'est pas encore vraiment
> > décidé au niveau du projet".
> Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
> horaires :
> 
> - data.gouv.fr:LaPoste - 04/2012 (par exemple)

Cet attribut est sur l'objet lui même, est plus ou moins déprécié et donc 
j'imagine ignoré ? En tous cas s'il ne l'est pas, j'imagine que tout le monde 
comprend ça comme "la source de la création initiale de l'objet, quelques 
détails ont pu changer depuis".

> - datanova.laposte.fr, 2020-11-15

Cette valeur de l'attribut source est sur le changeset, pas sur l'objet.
Le changeset montre clairement qu'il modifie les horaires.

Si quelqu'un change le wiki, je fais :-)⎄

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Numérotation des semaines (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 13:08:24 CET Frédéric Rodrigo wrote:
> À vérifier, mais je pense qu'il y a un risque que les horaires affichés
> sur place soit une simplification des horaires Datanova. Et que la
> différence ou les exceptions soient simplement gérés par des affichettes.

Je pense aussi, pour des trucs ponctuels (ponts par exemple).
Pour quelque chose qui va être valide toute l'année (semaines paires/impaires)
ce serait étrange d'avoir un papier scotché toute l'année

> Sur le comptage des semaines, attention il y une différence entre les
> semaines anglaises qui commencent le dimanche (et nous le lundi), quand
> l'année commence un dimanche.

Y'a un standard ISO derrière tout ça (ISO-8601), et c'est plus compliqué que 
la différence démarrage lundi / démarrage dimanche : le standard ISO dit "la 
semaine 1 est celle qui contient le premier jeudi du mois" (ou "celle qui 
contient le 4 janvier", c'est équivalent). Je sais que les américains 
utilisent une règle différente pour la numérotation des semaines...

Par contre ça me met le doute sur ce qui est fait en France...

Si https://calendrierfrance.fr/semaines-2021 est correct, la France ne suit 
pas le standard ISO 8601 ?? (Ce site dit que la semaine du 4 au 10 janvier 
2021 s'appellera la semaine 2, et non pas 1 comme dit le standard ISO).
Je me demande si ce site est correct. 
https://fr.wikipedia.org/wiki/Num%C3%A9rotation_ISO_des_semaines
et https://fr.wikipedia.org/wiki/Semaine ne parlent pas d'une autre 
numérotation utilisée en France.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On samedi 14 novembre 2020 11:16:27 CET Yves P.  wrote:
> Ça donnerait (à vérifier aux changements d'années :
> 
> Mo,Th 08:00-11:30,14:00-16:00;
> Tu08:00-11:30,14:00-17:00;
> Fr08:00-11:30,14:00-18:00;
> Su,PH off;
> 
> week 01-53/2 We 08:00-12:00;
> week 02-53/2 Sa 09:00-12:00

Je vois, merci pour la suggestion.

(et le "Su," peut être supprimé, ça par contre c'est fait)
 
> > je suis vraiment curieux de voir le panneau sur la porte de ce bureau :-)
> 
> Mercredi xxx semaine impaire
> Samedi yyy semaine paire

OK, mais cette description devient incorrecte en 2021...
Ils vont devoir changer le panneau pour échanger "paire" et "impaire", si les 
horaires prévus sont corrects...

> Bon, à voir avec l'auteur de la grammaire : Odd and even weeks over a
> year #351 <https://github.com/opening-hours/opening_hours.js/issues/351>

Merci.

Mais justement je peux comprendre si la grammaire ne prévoit pas quelque chose 
de quasi impossible à écrire sur un panneau ("Ouvert mercredi 8h-12h une 
semaine sur deux à partir du mercredi 3 janvier 2018").  :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

OK, donc pas 1).

Du coup il reste mon 2) (comparer datanova du dernier import et datanova+OSM 
du jour) ou ta suggestion (comparer OSM du dernier import et datanova+OSM du 
jour).

A mon avis les deux marchent, et ma solution me semble plus simple à 
implémenter (probablement juste parce que j'ai déjà la donnée sous la main,
et qu'il n'y a qu'à comparer deux chaînes de caractères).

Tu as une objection par rapport à ma solution "2)" ?

PS: OK je laisse tomber import@, ça me va :)

Merci pour tous les conseils, je pense que j'y suis presque :)

On vendredi 13 novembre 2020 23:36:14 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Ça tu oublies, oui tu sauve à part.
> 
> Tu peux aussi regarder avec overpass les bureaux qui ont changé depuis
> ton import.
> 
> Car overpass te permet d'inspecter l'historique de la base.
> 
> Par exemple si le dernier à avoir modifié l'objet c'est ton robot, tu
> peux foncer.
> 
> Et sinon tu prends l'image juste après ton dernier import : un export
> CSV par exemple daté avec id, opening_hours et dernier modificateur (si
> tu veux vérifier que c'est bien les données du robot afin de ne pas
> tester tout opening_hours).
> 
> Jean-Yvon
> 
> Le 13/11/2020 à 22:32, David Faure via Talk-fr -
> 
> talk-fr@openstreetmap.org a écrit :
> > 1) quand je sauve un opening_hours (sur un objet qui n'en avait pas,
> > donc),
> > je le duplique dans un tag spécifique (datanova:opening_hours ou un truc
> > comme ça) que je sauve aussi dans l'objet. Au moment du réimport je
> > compare les deux champs, et je ne met à jour (les deux) que s'ils sont
> > encore égaux. Sinon c'est que quelqu'un a fait un changement, alors j'y
> > touche plus (et on passe sur la solution du fixme et de la suggestion,
> > auquel cas ça fait quand même trois champs qui parlent d'horaires
> > d'ouverture, au total...).
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 18:51:32 CET Francois Gouget wrote:
> On Thu, 12 Nov 2020, David Faure via Talk-fr wrote:
> [...]
> 
> > 10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th
> > 09:00-12:00,14:30-17:00; Sa 09:00-12:00; Su,PH off
> > 
> > Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je
> > vois souvent que la seule différence entre OSM et datanova c'est que je
> > génère "Su,PH off" à la fin alors que dans OSM ça n'y est pas. Je sais
> > que ça revient au même,
>
> Pas tout à fait. Le "Su off" est bien redondant mais pas le "PH off",
> même si tous les français se doutent bien que le bureau de poste sera
> fermé les jours fériés.

Ah, oh. Bonne remarque.

Wow, c'est une erreur super courante. "PH " n'apparaît que pour 47 bureaux de 
poste dans OSM (dont 1 venant de mon import de test).

Je le remet alors, mais si OSM et datanova sont d'accord sauf PH off, je vais 
les considérer égaux quand même. 

> Pour ce qui est des mises à jour au fil de l'eau (après l'import
> initial) ; est-ce que le script serait capable de ne faire une mise à
> jour que si les horaires ont changés dans Datanova ?

Yep. Ça peut se faire sur la base de l'import précédent, cf sous-thread 
"Réimport".

> Cela limiterait les cas d'écrasement des modifications des utilisateurs
> sur place : si un utilisateur corrige un horaire, cette correction ne
> serait écrasée que la prochaine fois qu'il y a un changement dans
> Datanova, auquel cas on peut supposer qu'il serait de toute façon
> nécessaire de faire une vérif / mise à jour.

Ah, mais donc ça écraserait (et perdrait) une donnée manuelle; d'autres ne 
sont pas d'accord avec ça. Et je vois un risque en cas d'erreur d'identifiant 
la poste (même si je n'ai pas d'exemple concret où ça arrive).

Au 2e import, j'aurai :
 * ancienne valeur datanova ("old")
 * nouvelle valeur datanova ("new")
 * valeur stockée dans OSM ("osm")

Si osm==new, on ne fait rien. Et sinon :

Tu suggères 
  if (new != old) { osm = new }
alors qu'il me semble que le consensus est
  if (osm == old) { osm = new }
  else { suggested_hours = new + add fixme }

Ça semble moins risqué.

> Le principal cas de faux positif serait si Datanova contient une fermeture
> exceptionelle pour un jour particulier.

Genre "Jan 16: off" ?
D'une part je ne génère pas ça pour l'instant (si c'est un seul jour je 
l'ignore, si c'est plusieurs jours sans récurrence détectable ça va dans la 
case "non résolu, ne pas importer"). Et d'autre part, au max 3 mois plus tard 
l'import suivant supprimerait ça, donc pas de chance que ça impacte l'année 
suivante.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 12:20:37 CET Frédéric Rodrigo wrote:
> Perso, je n'aime pas l'idée d'écraser des choses dans OSM.

A la réflexion, je vais adopter cette pensée "conservatrice" parce qu'il 
existe un risque dont on a peu parlé : un mauvais ref:FR:LaPoste sur un bureau 
de poste dans OSM. Par exemple suite à renommage/renumérotation.

On vendredi 13 novembre 2020 09:58:58 CET Brice wrote:
> Idéalement, si ré-import, application des modifications de Datanova
> uniquement ssi pas de changement dans OSM depuis l'import précédent

Oui, c'est ce que je me dis depuis longtemps.

Je vois deux manières de faire ça :

1) quand je sauve un opening_hours (sur un objet qui n'en avait pas, donc),
je le duplique dans un tag spécifique (datanova:opening_hours ou un truc comme 
ça) que je sauve aussi dans l'objet. Au moment du réimport je compare les deux 
champs, et je ne met à jour (les deux) que s'ils sont encore égaux. Sinon 
c'est que quelqu'un a fait un changement, alors j'y touche plus (et on passe 
sur la solution du fixme et de la suggestion, auquel cas ça fait quand même 
trois champs qui parlent d'horaires d'ouverture, au total...).

2) ou alors je sauve le fichier des horaires parsés dans le git de mon code,
après chaque import, et je m'en sers pour comparer les horaires la fois 
suivante. Avantage, ça pollue moins OSM. Inconvénient, ça fait un peu "base de 
données à part". Mais vu que c'est entièrement pour les besoins du script 
d'import, ça me semble logique de faire comme ça.


Pour info, quelques stats :
==
16699 post offices ready for import, 683 post offices with unresolved rules.

Current status of the OSM data: I have 17371 unique post office IDs in the 
datanova data, while the overpass query outputs only 11593 nodes with a 
ref:FR:LaPoste attribute.

Current outcome: after comparing with OSM, I have 9186 opening_hours 
modifications to send.

The rest is 224 agreements, 962 disagreements, 767 not in datanova, 429 not 
ready (parser failed).
==

La très très grande majorité des horaires (9186 sur 11593) seront donc 
maintenus par l'import régulier. On peut même y inclure les 224 où ça colle 
déjà, en cas de mise à jour.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
> >> Et il faut garder les anciennes sources (sauf les anciennes versions de
> >> ce que tu importes).
> >> 
> >> Typiquement tu auras des source
> >> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> >> 
> >> Il ne fallait pas supprimer la source du bâti (par exemple).
> > 
> > Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais il
> > ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
> > disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
> > touche pas.
> 
> Je penses que la phrase du wiki "so don't go around deleting those
> source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
> c'est pour éviter que des contributeurs suppriment/modifient en masse
> "uniquement" un tag.

Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait 
implémenter ça.

Mais depuis j'ai vu
"Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à supprimer 
ces marques avant qu'une décision générale du projet décide de le faire."
https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs

Et pareil dans la version anglophone, " As usual don't start deleting those 
tags unless and until there is a general project decision to do so. "

> [...]
> La source précédente (celle existante sur l'objet) n'est pas perdue,
> elle est stockée dans l'historique de l'objet. Tout comme le tag
> source=* que tu apposes aux changesets.

Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas aller
supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé au 
niveau du projet".

> > Bon ben va falloir se mettre d'accord sur ce point là aussi :-)
> > https://wiki.openstreetmap.org/wiki/Key:created_by peut soit dire JOSM
> > vu que j'uploade le changement avec JOSM (mais bon il n'aura pas fait
> > grand chose dans l'histoire), soit j'y mets le nom de mon script comme
> > dans le premier test que j'ai fait,
> > https://www.openstreetmap.org/changeset/93931921
> > 
> > La page wiki sur created_by ne mentionne pas le cas des imports
> 
> L'important est que l'outil et la personne soient identifiables. La
> méthode me paraît secondaire. Mais ce n'est pas l'avis de tous, et
> certains sont très stricts là-dessus. Le mieux à mon avis c'est de
> mettre en place toutes les méthodes possibles d'identification de
> l'import pour espérer ne pas te faire revert. Il y a d'autres
> suggestions sur le wiki :
> https://wiki.openstreetmap.org/wiki/Import/Guidelines

OK. J'avais lu cette page au début, mais je viens de la relire, et là c'est 
bien clair :
Step 6 : You *must* use a dedicated user account.
C'est fait.

Comme ça c'est ceinture et bretelle, je fais compte spécifique et created_by.

> Personne ici n'a à donner d'ordres ;) La seule chose souhaitable c'est
> de chercher un consensus, mais souvent il n'est jamais atteint sur les
> mailing lists (je suppose dû au format et au public).

Chouette :-)
En plus je viens de lire que je dois aussi parler de l'import sur 
impo...@openstreetmap.org,
histoire d'avoir des avis différents de gens qui se parlent pas directement 
entre eux, MDR :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste / vérification terrain

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 20:15:23 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Pour, on peut lever un drapeau fixme = horaires à vérifier, XXX selon la
> Poste.
> 
> Car ça peut être les horaires XXX, pas la peine de laisser la fourmi se
> taper le texte s'il suffit de le vérifier.
> 
> Ou :
> 
> fixme = horaires à vérifier, voir si suggested:opening_hours contient la
> bonne valeur.
> 
> suggested:opening_hours=XXX

Ah, pourquoi pas, ça me plaît.
En plus comme ça Osmose peut facilement afficher la suggestion, sans avoir 
besoin de dupliquer le code complexe de parsing des données datanova.

J'imagine que s'il y a déjà un fixme, je concatène avec un ";" entre les deux.

Cf ci-joint la liste des fixme existants sur des bureaux de poste, par 
curiosité.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





























































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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

t.

> "Gabarit du contenu de la popup".

Wow c'est super lent quand on tape dans ce champ...
[Firefox tourne à 100% CPU pendant très longtemps à chaque appui de touche]

OK c'est prêt :
http://umap.openstreetmap.fr/fr/map/horaires-bureaux-de-poste_522248

> > Hmm, je veux mettre à jour les horaires, pas supprimer des bureaux de
> > poste, ça semble dangereux et hors périmètre :-)
> > Je pense que la création et la suppression seraient plutôt à faire à
> > partir d'une autre source de données, la liste des bureaux de poste
> > https://datanova.laposte.fr/explore/dataset/laposte_poincont2/
> > Mais ça je laisse volontiers à quelqu'un d'autre...
> 
> On a déjà ça (Fred confirmera).

Effectivement j'ai vu 
https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Import_des_points_de_contact_postaux
entre temps.

> >> Horaires : oui on a le droit d'ajouter/modifier des horaires, on met en
> >> général un source=La Poste, 2020-11-08 (histoire de savoir d'où ça vient
> >> et de quand ça date).
> > 
> > Dans le changeset, j'imagine. OK.
> 
> Pas forcément certains mettent sur l'objet das le cas d'imports.

Mais je ne crée pas l'objet, je change juste son opening_hours.

> Et il faut garder les anciennes sources (sauf les anciennes versions de
> ce que tu importes).
> 
> Typiquement tu auras des source
> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> 
> Il ne fallait pas supprimer la source du bâti (par exemple).

Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais il ne 
faut pas effacer.
Je croyais avoir lu le contraire (et aussi Éric disait qu'il fallait effacer, 
cf mail de mardi).
Pas de problème, j'y touche pas.

> > Pas de mention de l'outil d'importation, au cas où quelqu'un veuille
> > remonter à comment un mauvais import a eu lieu ?
> 
> Non 

Bon ben va falloir se mettre d'accord sur ce point là aussi :-)
https://wiki.openstreetmap.org/wiki/Key:created_by peut soit dire JOSM
vu que j'uploade le changement avec JOSM (mais bon il n'aura pas fait grand 
chose
dans l'histoire), soit j'y mets le nom de mon script comme dans le premier test
que j'ai fait, https://www.openstreetmap.org/changeset/93931921

La page wiki sur created_by ne mentionne pas le cas des imports

> car pour utiliser un robot tu dois créer un compte spécifique.
> Par exemple DavidFaure_bot.

Ah, c'est vrai que j'avais lu de créer un autre compte et que j'ai oublié de le 
faire.
Mais je vois la réponse de Jérôme, je vous laisse vous mettre d'accord, et 
j'obéirai :-)

> >> Ah oui, j'ai vu cette page, mais je ne comprends pas bien la différence
> >> entre ses sections. Les imports ne sont-ils pas tous "communautaires" ?
> 
> La plupart, tu peux aussi avoir des personnes payées pour (qui doivent
> aussi avoir l'accord de la communauté).

OK mais ça me laisse confus par rapport à la question de "dans quelle section 
de Import/Catalogue je dois ajouter mon import". Je vois trois sections qui 
pourraient coller...
Community : oui. One time : oui pour l'instant. Ongoing, fully scripted : oui 
c'est l'idée.
(Enfin 99% scripté, faut quand même passer par JOSM pour uploader, 
malheureusement...)
 
> >> N. B. : préalable : vérifier avec Osmose par exemple que les bureaux de
> >> poste sont bien dans OSM : ce serait dommage de vouloir mettre à jour
> >> des horaires de bureaux inconnus.

En fait je ne vois pas comment ça peut arriver. Le processus (comme conseillé 
par Jérôme)
c'est une requête overpass pour les bureaux avec une ref, je trouve la ref dans 
les données
datanova, je modifie opening_hours, je pousse via OSM. A aucun moment ceci ne 
peut
amener à "vouloir mettre à jour des horaires de bureaux inconnus".

Si un bureau est dans datanova et pas dans OSM, il ne sera jamais regardé 
puisque 
l'itération se fait sur les bureaux OSM.

Et si un bureau est dans OSM et n'est pas dans datanova, ou bien a des horaires
non résolus (comme CERESTE ci-dessus), alors j'y touche pas.

Et pour l'instant si un bureau est dans les deux et a des horaires dans OSM,
j'y touche pas non plus.

Malgré tout ça, j'ai déjà 9179 objets modifiés à envoyés, ça vaut le coup :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 21:48:36 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Il est possible que ce fichier soit de grande qualité comme de
> piètre qualité.

OK, on va voir :-)

> Je te propose de jouer pour ref:FR:LaPoste
> <https://wiki.openstreetmap.org/wiki/Key:ref:FR:LaPoste?uselang=fr>
> 10115A. Pas d'horaires actuellement, là encore il y a eu les horaires
> covid mais je dois avoir une photo des horaires d'avant - et les connais
> à peu près. C'était du style demi-tordu sans doute à cause d'un temps
> partiel modifié.

10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th 09:00-12:00,14:30-17:00; 
Sa 09:00-12:00; Su,PH off

Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je vois 
souvent
que la seule différence entre OSM et datanova c'est que je génère "Su,PH off" à 
la fin
alors que dans OSM ça n'y est pas. Je sais que ça revient au même, mais est-ce 
qu'il y
a une bonne pratique par rapport à ça ? Je peux le supprimer de ma génération
pour que ça colle plus aux données existantes, si c'est considéré plus lisible.
Ou le laisser si c'est considéré plus explicite.

Je viens de rajouter un coup de https://github.com/rezemika/oh_sanitizer sur 
les deux données
mais la différence reste, apparement oh_sanitizer n'y touche pas.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 18:32:53 CET Brice wrote:
> Le 11/11/2020 à 15:57, David Faure via Talk-fr a écrit :
> > Dis moi où tu habites et j'aurai des infos super précises sur les horaires
> > d'ouverture de ton bureau de Poste :)
> 
> OK pour un mini-mini échantillonnage, je vérifierai :
> https://www.openstreetmap.org/node/326243219
> https://www.openstreetmap.org/node/6140793094
> https://www.openstreetmap.org/node/249560489
> mais horaires très simples, on est pas vraiment dans le rural;-)

Voilà ce que sort mon script, sur la base des données datanova :

14181A|PARIS BELLEVILLE BP|Mo-Fr 09:00-19:00; Sa 09:00-13:00; Su,PH off
14266A|PARIS SAMBRE ET MEUSE|Mo-Fr 09:00-20:00; Sa 09:00-13:00; Su,PH off
14298A|PARIS PERNETY PLAISANCE|Mo-Fr 08:30-19:30; Sa 09:00-13:00; Su,PH off

Apparemment c'est donc stable sur les 3 prochains mois, pas de cas particulier.
Ce qui est intéressant c'est que OSM n'a pas les mêmes horaires :

Paris Belleville : Mo-Fr 10:00-16:00
(marqué comme opening_hours:covid19, je ne vois pas de tag opening_hours tout 
court)

Paris Sambre et Meuse : Mo-Fr 09:00-20:00; Sa 09:00-13:00 --> sur celui là on 
est d'accord.

Paris Pernety / Plaisance : Mo-Fr 08:00-20:00; Sa 09:00-13:00  --> différent

Tu as moyen de vérifier les horaires réels ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 13:31:02 CET Brice wrote:
> > ensuite pour les autre questions :
> (...)
> 
> > - tes données ont beaucoup plus de chance d'être à jour que celles
> > présentes dans osm donc moi je dirais qu'il faut remplacer l'existant
> > qui peut être là depuis des années.
> 
> Pas trop d'accord, il serait dommage de partir d'un à priori qu'un
> organisme central connaisse parfaitement les horaires de toutes ses
> implantations, quand se comptent en milliers : pas sûr du tout.
> Je suis pour ne compléter que les bureaux de poste avec horaires non
> encore renseignés et laisser tels quels les horaires existants pour
> qu'ils soient corrigés, si nécessaire, au fur et à mesure.

Merci pour ton retour, c'est utile qu'on en discute.
Est-ce que tu as regardé les données datanova ?
Je pense qu'elles sont bien plus précises que tu ne le penses, et pour info 
elles sont mises à jour *tous les jours* automatiquement.

Les données datanova nous disent par exemple que le bureau de Poste de 
DENEUILLE LES MINES sera ouvert le mardi de 09:00 à 12:00 
aux dates suivantes :
  2020-11-03 2020-11-10 2020-11-17 2020-11-24
et de 08:15 à 12:15 aux dates suivantes :
  2020-10-27 2020-12-01 2020-12-08 2020-12-15 2020-12-22 2020-12-29 2021-01-05 
2021-01-12 2021-01-19 2021-01-26
... ce qui veut dire qu'il y a un changement temporaire en Novembre.
Quelle est la probabilité que quelqu'un aille noter ce changement temporaire 
dans OSM manuellement ? Et surtout, quelle est la probabilité que cette donnée 
soit fausse, et que les horaires affichés sur la porte soient plus corrects ?

Dans le même style, datanova contient les changements horaires qui auront lieu 
à partir du premier janvier 2021, toujours avec une précision jour par jour.
J'ai aussi détecté bureaux qui sont ouverts un samedi sur deux, ou qui sont 
fermés le dernier samedi de chaque mois. Et d'autres avec des cas encore plus 
tordus de fermetures exceptionnelles ou d'alternance entre deux horaires sans 
récurrence détectable. Tout ça pour dire que c'est super précis.

En cas de désaccord entre le opening_hours existant dans OSM et la donnée 
datanova.laposte.fr, qu'est-ce qui est le plus probable ? Que datanova se 
trompe ou que la donnée OSM ne soit pas à jour ? Au vu de la précision des 
données publiées, je dirais que c'est le second cas, à coup sûr.

Dis moi où tu habites et j'aurai des infos super précises sur les horaires 
d'ouverture de ton bureau de Poste :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 19:10:26 CET Jérôme Amagat wrote:
> Ce qu'il est possible de faire, il y a surement d'autre façon de faire,
> mais je n'ai essayé que ça :
> - obtenir les bureaux de poste avec l'overpass api via une requête de ce
> type : https://overpass-turbo.eu/s/ZUw (pour josm il faut du xml et out
> meta)
> -  faire un script qui va lire le xml, détecter les tags ref:FR:LaPoste=*
> et ajouter les opening_hours=* au bon élément, il faut pour que josm sache
> que l'élément a été modifié et qu'il faut envoyer l'élément au serveur,
> ajouter un action='modify' au bon endroit pour chaque élément modifié.
> - une fois modifié, ouvrir avec josm ce fichier enregistré en .osm
> - envoyer les modification

Merci beaucoup pour ces instructions.

Je viens de les utiliser pour soumettre mon premier changeset avec JOSM :
https://www.openstreetmap.org/changeset/93931921
Est-ce que tout semble correct ?
En particulier la suppression de la source de l'objet (déprécié), l'ajout des 
horaires bien sûr, le created_by et la "source" du changeset, et le 
commentaire avec le lien wiki.

Si ça semble bon je vais pouvoir industrialiser :-)

PS: J'ai utilisé https://github.com/mvexel/overpass-api-python-wrapper
et 5 lignes de python pour faire la requête overpass en ligne de commande, 
c'est plus pratique.
Mes scripts sont maintenant en ligne sur 
https://github.com/dfaure/DataNovaImportScripts

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 21:32:40 CET Frédéric Rodrigo wrote:
> Si le générateur des horaires d'ouvertures est codé en python 

Je connais bien mieux perl que python donc pour l'instant c'est en perl.
Si quelqu'un veut m'aider à convertir en python... :)

> ça serait bien aussi de l'ajouter à Osmose

Pour refaire l'import en temps réel et voir si ça colle ? Ou bien je pige pas 
l'idée ?

C'est peut-être surtout l'autre sens qui serait utile, valider que les 
horaires sont syntaxiquement corrects ? Mais bon ça je compte le faire avant 
import de toutes façons.

> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merg
> e_poste_FR.py
> http://osmose.openstreetmap.fr/fr/map/#zoom=9=45.215=0.104=705
> 0%2C8020%2C8021%2C8022=1%2C2%2C3==

Wow, merci pour ce lien. Ça m'explique pourquoi j'ai 17371 identifiants 
différents de bureaux de poste dans les données datanova, alors que la requête 
overpass de Jérôme ne me sort que 11503 bureaux avec un attribut 
ref:FR:LaPoste.
osmose montre que de nombreux bureaux n'ont pas cet attribut, et certains ont 
une valeur qui n'existe plus chez laposte (renumérotation ? fermeture ... ?).

Et ben c'est pas simple tout ça :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 19:42:59 CET Yves P. wrote:
> > Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
> > Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> > ne vont pas dans opening_hours, donc je les considère hors périmètre.
> > C'est déjà assez compliqué comme ça :-)
> 
> On pourrait suffixer collection_times ;)
> 
> On trouve cet exemple dans le wiki :
> collection_times = Mo-Fr 09:00-12:00,17:00; Sa 14:00
> collection_times:local = Mo-Fr 23:00; Su 23:00
>
> Ça donnerait donc quelque chose comme :
> collection_times:parcel = Su-Fr 23:00

OK, noté dans la TODO list :)
C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?
Ou bien c'est une suggestion "à faire standardiser d'abord" ?

> collection_times:chronopost = Su-Fr 18:00
> Parcel est générique et doit se retrouver dans tous les pays.
> chronopost est une marque. Existe-t-il un terme générique anglais pour ce
> type de paquets ?

Ça ne me rappelle rien.

Dans les autres pays les paquets sont livrés, contrairement aux chronoposts, 
bien souvent :-) :-)

> >>> Detect cases like "every other Saturday", which seems to happen.
> 
> Je ne comprend pas cette expression. DeepL me dit "un samedi sur deux".

Oui.

> C'est bien ça ? Ça ne serait pas plutôt premier et 3e samedi du mois ?
> Ou samedi des semaines paires (ou impaires) ?

Non.

> Le langage d'opening_hours permet cela :
> Su[1,3]   # 1er et 3e samedi du mois
> week 01-53/2  # semaines impaires
> week 02-53/2  # semaines paires

Comme je disais, ça fait pas du "1 sur 2" au changement d'année, alors que 
c'est vraiment ça que je vois dans certains bureaux de poste...

D'autres font du Sa[-1], j'ai pas fini de tomber sur des cas tordus :-)

> Il faut peut-être l'ajuster d'une année sur l'autre ?

Oui je vais devoir faire ça du coup...

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

es quantités de données...
Peut-être osmsync ferait l'affaire ?

> N. B. : préalable : vérifier avec Osmose par exemple que les bureaux de
> poste sont bien dans OSM : ce serait dommage de vouloir mettre à jour
> des horaires de bureaux inconnus.

Hmm, encore un autre outil :-)
JOSM ne permet pas de vérifier ça ? Ou osmsync ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour à tous,

J'ai le projet d'importer les horaires des bureaux de poste de toute la France, 
depuis les données disponibles sur datanova.laposte.fr.

La page Import/Guidelines indique que je dois en discuter avec la communauté 
alors me voici :-)

Je viens de créer la page 
https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours
avec l'état actuel de ce projet.

Vous y trouverez aussi quelques questions, comme celle de garder les valeurs 
actuelles ou de les remplacer, et la stratégie de remise à jour après le 
premier import. Votre avis sera le bienvenu.

Est-ce que vous avez un conseil sur la solution technique à utiliser pour cet 
import ?
Mon script génère les valeurs au format OSM pour l'attribut opening_hours, la 
prochaine étape est d'interfacer avec OSM,
et je vois sur https://wiki.openstreetmap.org/wiki/Import/Software qu'il existe 
beaucoup de solutions...


PS: pour plus de contexte sur moi et l'origine de cette idée, cf.
https://wiki.openstreetmap.org/wiki/User:Dfaure

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Données fournies par fichier SIRET

[David Crochet]

Bonjour

Le 29/10/2020 à 11:23, Georges Dutreix via Talk-fr a écrit :

Observez-vous la même chose autour de chez vous ? Merci.



Oui je pense que la fiche contient l'adresse postale du propriétaire de 
l'entreprise et il loue souvent un local soit en son nom propre, soit 
dans le cadre d'une SCI.


Cordialement

--
David Crochet

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

Re: [Talk-es] Herramienta para mejorar los procesos de creación de consensos en la comunidad

[David Marín Carreño]

Hola de nuevo.

Creo que no he logrado transmitir lo que quería decir.

Por supuesto es necesaria una normalización para que todos acabemos
mapeando de una manera compatible para que la base de datos sirva para
algo, por mucho que todos podamos meter mano e inventarnos etiquetas.
Tampoco es razonable tener distintos juegos de etiquetas para mapear la
misma realidad.

Lo que quería decir es que, llegado el caso de un debate constructivo sin
opiniones enconadas ni enfrentadas (como es el caso del tema de las
dehesas), basta con que la persona intersada en la normalización recoja el
consenso de la conversación en una página de normalización de la wiki
(primero en español, y luego ir más allá si es necesario) y continuar con
el proceso.

O si no está clara la decisión, la persona interesada puede solicitar una
votación o realizar una encuesta a la comunidad, que podría llevar a
resolverse también a través de la lista o a través de cualquier otro medio.

Vamos, que creo que el tema de tomar decisiones o llegar a consensos no
depende tanto de las herramientas empleadas para alcanzar este objetivo,
sino de que la persona interesada coja la bandera y la lleve hasta el final
de donde haga falta.
--
David Marín Carreño 



El vie., 16 oct. 2020 a las 15:26,  escribió:

> Me alegro de que se haya apuntado una voz nueva :)
>
> @David: Tu descripción describe correctamente cómo funcionamos ahora
> mismo. Estamos entrando en terreno filosófico sobre qué visión tiene cada
> uno de este proyecto que es de todos. Intento resumir al máximo la mía
> porque si no entramos en un debate eterno (aunque interesante): En una base
> de datos la anarquía debe reducirse al máximo. El pilar en que se sustenta
> la usabilidad de OSM es que haya reglas y definiciones y que si alguién
> decide no seguirlas se pueden, no, se DEBEN corregir. OSM funciona
> razonablemente bien porque si alguien decide cambiar la AP-7 a "track", al
> día siguiente otro contribuidor la habrá vuelto a poner como estaba y ha
> avisado al contribuidor responsable. Y si repite la jugada porque le sale
> de los co..nes se banea. Soy consciente, la realidad es compleja y por
> tanto es complejo representarla con todo detalle en un mapa de forma
> homogénea en el mundo entero. Por ello siempre habrá variaciones, problemas
> de encaje de conceptos o diferentes maneras para hacer cosas parecidas.
>
> Esto no quita que idealmente estas variaciones anárquicas se deben
> minimizar al máximo. Ejemplo: Ahora estamos debatiendo sobre las dehesas y
> la realidad de etiquetaje en este momento es la siguiente:
>
> 560 = natural grassland - dehesa
>
> 51 = natural grassland - montado
>
> 21 = natural grassland - oak_savanna
>
> 1 = landuse agroforestry - dehesa
>
> 1 = landuse farmland - crop:agroforestry
>
> 9 = name: "algo con agroforestry", en combinación con landuse:orchard,
> landuse:farmland etc
>
> 3 = name: agroforest, en combinación con natural=wood
>
> 3 = "agroforest" incluido en la description en combinación con natural=wood
>
> -> Sin contar todas las opciones creativas que otros habrán usado para
> mapear lo mismo.
>
> Este tipo de "anarquía" no me parece ni romántica ni deseable. Si queremos
> multiplicar el potencial de OSM deberíamos encontrar un criterio
> consistente y si la realidad requiere entiquetados complejos con subkeys
> complejos esto es infinitamente más útil que dejar que cada uno lo ponga
> como le da la gana. Idealmente (y sabiendo que nunca es posible del todo)
> no debería existir ninguna etiqueta ni ninguna manera de mapear que no este
> consensuado o aprobado - o como mínimo en status de proposal. Cuando
> alguién se da cuenta que no puede reflejar la realidad adecuadamente lo
> primero que debería hacer es inciar un debate y proposal para que el resto
> del mundo empieze a adaptarlo en su comunidad
>
> A lo que voy es que para conseguirlo creo que no es suficiente basarse
> únicamente en el "clima generado", y que me parece contraproducente el
> "siempre y cuando se mantenga dentro de lo razonable" porque significa que
> como todos los tags que he puesto arribe están dentro de lo razonable y
> mañana Miguel, de forma razonable, podría etiquetar un area con
> landuse=parkland seguimos con un colorido ramillete de etiquetas que ni se
> renderizarán bien ni facilitarían un análisis científico/académico ni
> cualquier futuro uso.
>
> Detalle técnico: Loomio te avisa con un mail sobre cualquier nueva
> respuesta y por tanto es igual de fácil seguir un debate allí que en la
> lista.
>
> Saludos,
>
> Marcos
>
> Am 16.10.2020 13:53, schrieb David Marín Carreño:
>
> Hola a todos.
>
> Varias ideas sobre esto:
>
> Sobre cómo alcanzar consensos, creo que la lista has

Re: [Talk-GB] Multi-lingual tagging in Wales

[David Woolley]

On 16/10/2020 14:08, Gruff Owen wrote:
With that in mind, and admittedly polemicising the debate a little. If 
we accept the premise that the native language of Wales is Welsh and 
that OSM is a community mapping project where we have an opportunity to 
respect native communities in a way that past colonial mapmakers didn't. 
Could we take this as an opportunity to prioritise authentic Welsh place 
names where that's possible? I understand that there will be objections 
to this, but I'm not sure we can disregard it completely as an option?




My understanding of how it works is that it is up to the local 
communities to ensure that road signs, etc., in the local area, reflect 
the community preferences, and OSM will reflect whatever the signage 
says.  This is even more important in areas where people are shelling 
each other over such issues.  Using what is on the ground is the only 
way that OSM can avoid taking sides.


There is nothing to stop a Welsh language supporter running a map tile 
server that uses name:cy, in preference to name, where it exists.


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

Re: [Talk-es] Herramienta para mejorar los procesos de creación de consensos en la comunidad

[David Marín Carreño]

Hola a todos.

Varias ideas sobre esto:

Sobre cómo alcanzar consensos, creo que la lista hasta ahora ha funcionado
razonablemente bien.
No estamos hablando de la aprobación de las leyes del reino, sino de un
proyecto que conlleva en sí algo de anarquía como nuestro wiki-mapa, en el
que cualquiera puede entrar y cambiar lo que le dé la gana.

Hasta ahora, si hay algo que se quiere implantar o cambiar, se comenta, se
debate y, a partir del clima generado, se puede ver si hay un consenso o
que, al menos, no hay un disenso o opiniones fuertemente contrarias que
podrían llevar a guerras de ediciones. Este proyecto se basa en la buena fe
de los que colaboramos en él, y salvo algunas raras excepciones, el clima
lleva siendo agradable y colaborativo.

Al final, el que hace las cosas pues es el que lleva la voz cantante,
siempre y cuando se mantenga dentro de lo razonable.

Si al final se decide usar una herramienta para realizar votaciones en
aquellos casos o discusiones en los que se decida que haya que votar (que
sería lo único para lo que la lista NO funciona) pues me parece bien.

Yo mantendría las discusiones y debates aquí. Hay pros y hay contras. Pero
la lista la leo varias veces al día y (hablo por mi) dudo mucho que si se
desplaza a otra herramienta vaya a visitarla tan a menudo.

Como única sugerencia, que cualquier herramienta esté alojada bajo el
dominio openstreetmap.es.

Un cordial saludo,
--
David Marín Carreño 



El vie., 16 oct. 2020 a las 12:55,  escribió:

> Veo que estamos de acuerdo en lo principal:
>
> Debate que requiere consenso en Telegram, el foro, Twitter, Whatsapp,
> Matrix, etc. -> la lista
>
> Evidentemente como menos plataformas diferentes mejor, por eso intento
> convencer que probemos Loomio no para tener otra más sino para reemplazar
> la lista.
>
> Lo de usar Loomio como único canal de decisón durante el periodo de prueba
> evidentemente no tiene que ser obligatorio, lo he mencionado porque me
> parecía que si tenemos que debatir algo, como por ejemplo el tema dehesas,
> tener que llevar el debate an ambas plataformas en paralelo sí que sería un
> cacao y que sería lógico llevarlo solo en Loomio. De lo contrario habría
> que hacer copy/paste de lo que escribes en un canal y pasarlo por el otro
> de nuevo y no creo que tenga sentido ni que ayude a que le gente participe
> más. Pero bueno, yo me adapto si la comunidad así lo prefiere.
>
> Si empezamos a usar Loomio de verdad para unos cuantos temas y no convence
> - nada, volvemos a la lista.
>
> Saludos,
>
> Marcos Martinez
>
> Am 15.10.2020 21:26, schrieb Jorge Sanz Sanfructuoso:
>
>
> Todo lo que se hable en Telegram en el foro o en cualquier plataforma se
> puede plasmar después en la lista y por así decir terminar de decidirse. No
> hay problema. Si ha funcionado cuando pase a la lista poco habrá que
> añadir. Y si se quiere usar cualquier otra herramienta se puede hacer
> igual. Y si se ve con el tiempo que es mejor y así se decide en la
> comunidad, cambiar a la nueva herramienta como lugar de decisión.
> Igualmente cuanto menos herramientas diferentes se usen lo veo mejor por no
> dividir a la comunidad. Pero entiendo que a veces como en este caso puede
> ser necesario.
>
> Esto lo comento porque en el anterior mensaje decias que hay que usarla un
> tiempo y debe ser durante ese tiempo el único canal de decisión. Esto no es
> hacerlo con calma. Lo de añadir el enlace como comentas en el último
> mensaje y has hecho en el tema de las dehesas si lo veo correcto.
>
> No estoy diciendo que sea mejor o peor herramienta porque sin usarla
> claramente no puedo opinar sobre ello.
>
> Saludos.
>
> El jue., 15 oct. 2020 a las 21:01,  escribió:
>
>> Buenas igualmente y bienvenido al debate.
>>
>> Como he intentado explicar anteriormente no se trata simplemente de tener
>> un nuevo canal, Loomio no tiene nada que ver con lo que pueda signifacar
>> Telegram que al fin y al cabo no es más que un canal adicional de
>> comunicación para que la gente comente, pregunte, opine o se cuente un
>> chiste. En esto tienes razón, plataformas de este tipo van y vienen y pasan
>> de moda. Pero no me meto con esto, cada uno elige el que más le guste, ya
>> sea el foro, reddit, Telegram o lo que sea. Pero hay UN canal para
>> realmente decidir cosas y este no es opcional: la lista. Si unos cuantos
>> debaten en el foro y se ponen de acuerdo en que se use forest=dehesa - no
>> tiene validez ninguna. Lo mismo pasa en cualquier otro canal incluyendo
>> Telegram. Porque estas cosas obligatoriamente deben pasar por la lista.
>>
>> La intención es simplemente encontrar algo mejor que la lista. Y te doy
>> la razón en que algo tan elemental como la lista no se puede reemplazar a
>> la ligera cada 3 meses

Re: [talk-au] Sufficient permission?

[David Wales]

As an example, this path is called "The Ruins Track" by the author of
the guide, as it passes the ruins of an old settlers cottage:
https://www.openstreetmap.org/way/855355616

This part of the track is called "Racklyefts Finger Track":
https://www.openstreetmap.org/way/856270065

Due to the existence of the guide, and the lack of signs on the ground,
I imagine that most people use the names in the guide, or no name at
all. However, I do not belong to a local walking group, so I don't know
if there are other conventions.

However, the author of the guide has walked all the tracks himself, and
created and maintains some of them.

On 7/10/20 9:54 am, Mateusz Konieczny via Talk-au wrote:
>
>
>
> Oct 6, 2020, 23:10 by daviewa...@disroot.org:
>
> "You may use any names I have applied to tracks as my main
> intention is to get people walking."
>
> I am not a lawyer but it sounds like something that is at least
> intended to be
> https://en.wikipedia.org/wiki/Public-domain-equivalent_license like say
> https://en.wikipedia.org/wiki/WTFPL
>
> note that there is also special mailing list (legal-talk).
>
> I am more worried about
>
> You will find names in the guide that are not accepted
> geographical names,
> but by becoming common usage names they will eventually be adopted.
> I am fitting (nailing) laminated signs with map to trees.
>
> part - are this names already used by people except author of the guide?
>
> (I just added place=locality with name used by people from a single
> camping spot[1], so
> my standards are not high - but some actual use should be present)
>
> [1]
> https://www.openstreetmap.org/node/7973988988#map=16/49.4727/21.3801
> 
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



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

[talk-au] Sufficient permission?

[David Wales]

Hi all,

I like to walk tracks with my GPS running, and trace them into OSM
afterwards.

A long time ago, I sent an email to Robert Sloss, who makes lots of
bushwalking guides in my region. I asked if it was OK for me to use the
track names from his books to name the tracks in OSM. (Many of the
tracks are not signposted, so you can't find out the name on the ground.)

His reply was

"You may use any names I have applied to tracks as my main intention is
to get people walking."

Does this sound like sufficient permission for OSM?
The full email chain is pasted below:

From: "Robert Sloss" 
To: "'David Wales'" 
Subject: RE: OpenStreetMap Bushwalking tracks
Date: Mon, 22 Sep 2014 19:43:06 +1000

Hi David

I have no objection to using the name Cadastral; I used this name as there
is no street nae for the right of way between the two properties. 

You will find names in the guide that are not accepted geographical names,
but by becoming common usage names they will eventually be adopted. I am
fitting (nailing) laminated signs with map to trees. \

You may use any names I have applied to tracks as my main intention is to
get people walking.

Regards 

Robert Sloss 

-----Original Message-
From: David Wales [mailto:daviewa...@gmail.com] 
Sent: Friday, 19 September 2014 6:16 PM
To: rob...@robertsloss.com.au
Subject: OpenStreetMap Bushwalking tracks

Hi Robert,

I have recently gone on a bushwalk in the Buxton area, using your book
Bushwalking - Cycling : Wollondilly & Macarthur.
I logged the route using a GPS, and have traced the track onto
OpenStreetMaps.

(See this link: http://www.openstreetmap.org/#map=17/-34.24863/150.51763 )

However, I have not added the name of the track, because it was not
signposted.
According to your book, the track name is Cadestral Track, but I thought I
should ask your permission before copying that name.

For future reference, do you mind if I use the names from your book to name
trails I trace on OpenStreetMap from GPS tracks?

Regards,
David Wales.



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

Re: [OSM-talk-fr] Cartographie des dégâts de la tempête Alex dans les Alpes Maritimes

[David Crochet]

Bonjour

Le 05/10/2020 à 11:03, Percherie OnDaNet a écrit :
Si l'accès est coupé de manière temporaire (quelques semaines ou 
mois), est-il envisageable d'y ajouter un tag dédié permettant à 
l'ensemble des outils de routage de prendre en compte cette restriction ?



cf Pont Mathilde à Rouen

Cordialemennt

--
David Crochet


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

Re: [Talk-GB] Blocked / overgrown / inaccessible footpaths and bridleways

[David Woolley]

On 29/09/2020 14:29, Gareth L wrote:
I’ve prioritised tagging width values on canal towpaths in some 
locations where, whilst legal, it’s precarious to try and cycle along as 
they’re practically less than a metre wide.


Unless you are just tagging with the actual width, I'd suggest that 
would be a dangerous precedent.  I've seen people wanting to invalidate 
official cycle routes because they think the traffic is too dangerous.



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

Re: [Talk-GB] UPRN Locations Map

[David Woolley]

On 26/09/2020 13:06, Russ Garrett wrote:

There is no legal obligation for FoI responses to be openly licensed.
The point of FoI is to make information available for inspection, but
not (necessarily) for reuse.


To expand on that.

Larger UK companies tend to be very intellectual property based, so 
making information freely available is never going to be a government 
objective.


The actual objective will be more towards open government; ensuring that 
decisions, and the information behind them are open to scrutiny.  A 
secondary purpose is probably to try to ensure that the taxpayers have 
the results of work paid for from their taxes.


OS are in a funny position, in that they are in the public sector, but 
are expected to be self funding.  To the extent that they succeed in the 
latter, they don't owe a duty to the taxpayer.


Although FoI is often used as a tactic for obtaining information for 
republication, as the response points out, that republication isn't 
actually authorised by the FoIA; the information is provided for the 
personal use of the requestor.


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

[Talk-pt] Frases especiais em portugues no Nominatim

[David Morais Ferreira]

Bom dia,

Após uma discussão no canal de telegrama, reparei que algumas frases
"especiais" [1] utilizadas pelo Nominatim [2] não estão traduzidas em
português [3]. Estas frases permitem a pesquisa localizada.

Um exemplo seria quando se procura "farmácia perto de Lisboa" na caixa
de pesquisa. O Nominatim não é capaz de traduzir o pedido para uma
pesquisa de farmácias, e assume que estão a pesquisar
nodes/ways/relations chamadas “farmácia”.


Estas frases são importadas para Nominatim numa base irregular,
portanto pode levar algum tempo a ser importado. Há uma issue no
Github [4] que visa automatizar este processo, por isso espero que
haja uma importação automática, ou manual num futuro próximo.


Há interessados? :)

Cumprimentos

David (dmlu)

[1] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/PT
[2] https://wiki.openstreetmap.org/wiki/Pt:Nominatim
[3] https://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases/EN
[4] https://github.com/osm-search/Nominatim/issues/235

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

Re: [Talk-GB] Jewson - is it shop=doityourself or shop=trade?

[David Woolley]

On 18/09/2020 21:55, Mark Goodge wrote:

but B, Wilko and Wickes are consumer


My impression is that Wilko is genuine consumer, but B, is mix of 
consumer and informal economy trade (aka handymen) and Wickes is mainly 
a mix of formal and informal economy trade.


(I'm not sure to what extent handymen are really in the informal 
economy, or simply do properly taxed small B2C jobs.)


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

Re: [Talk-GB] Jewson - is it shop=doityourself or shop=trade?

[David Woolley]

On 19/09/2020 13:32, Phil Endecott via Talk-GB wrote:

i.e.
some chains may describe themselves in a way that allows
them to get permission to operate on cheaper industrial
estates rather than more expensive retail parks.  I don't
think that's very useful information for map users.


I think you are assuming the typical OSM user is the man in the street. 
My impression is that the heavy users are actually academic and 
professional, for whom planning type issues may actually be very important.


OSM isn't trying to be a retail directory, and the very patchy nature of 
its coverage for initial addition and updates, means it will not be a 
good one, except in small areas, in the foreseeable future.



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

Re: [Talk-GB] Brexit and OpenStreetMap

[David Woolley]

On 14/09/2020 14:41, Andy Mabbett wrote:

Change sets and item histories contain user names, for example.


If those don't fall under some sort of exemption, you have rather more 
fundamental problems than Brexit; you probably can't make the map 
available outside the EU without some sort of NDA.


An analogy would seem to be film credits.  Google didn't provide 
anything helpful on that.  Most hits were about tax credits!


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

Re: [Talk-GB] Brexit and OpenStreetMap

[David Woolley]

On 14/09/2020 13:51, Tony Shield wrote:
By thinking of moving OSMF from UK to EU because of Brexit are you 
saying that OSMF may never be able to function outside the EU - what 
about Switzerland where many international organisations are based, or 
United States. These are respected countries which should be considered 
if relocation is deemed necessary.




The United States is generally understood to have very weak data 
protection laws, but still manages to operate within Europe, although 
sometimes using Irish or Luxembourg proxies.


With respect to data privacy what is to stop OSMF mandating in its 
contracts and operation that the relevant EU data laws are adhered to. 
Maintaining data integrity and security is a function of OSMF, these 
functions are mandated by EU law, OSMF wherever it is domiciled can base 
its operations on the implementation of EU law.


I imagine that is the way that most big organisations will go, not just 
on privacy.


Having said that, is it actually the case that data protection law is 
being revoked at the end of the year.  I doubt it.


Of course, the map itself should not contain any personal data, as, even 
when based in the UK, I don't see how adequate controls could be applied 
to unpaid volunteers.



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

Re: [Talk-GB] New Bing Imagery

[David Woolley]

On 19/08/2020 16:21, Russ Garrett wrote:

5m accuracy


You'll accumulate that error in a couple of centuries, just from 
continental drift: 
, 
given that OSM is referenced to WGS-84, not the British mainland.


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

Re: [Talk-GB] Proposal: Import EV charging point data

[David Woolley]

On 18/08/2020 00:11, Steven Hirschorn wrote:
I'm hoping to import a dataset of EV vehicle charging points in London. 
I've created a wiki page here: 
https://wiki.openstreetmap.org/wiki/SourceLondon




There was a lot of discussion about importing EV charging station data 
recently, so the first thing you should do is go through the list archives.


Also, note that you need the agreement of the community before you start 
any import.



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