Re: [OSM-talk] software requirements for OSM Editor: Firefox

[Brian M. Sperlongano]

This is not OSM's problem to solve.

Ancient web browser slowly becomes unusable = expected behavior.

On Fri, Oct 6, 2023, 7:26 AM Martin Trautmann  wrote:

> On 23-10-06 12:55, Tom Hughes via talk wrote:
> > No it was released in June 2020. October 2021 was the last
> > security patches.
> >
> > To answer the original question there have been any deliberate
> > changes that I know but given the error it's entirely possible
> > that FF has fixed something in what CSP rules it checks for what
> > requests.
>
>
> I doubt that since FF did not see any changes here for some time,
> unfortunately. So it appears to be from an OSM editor's change.
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed bulk removal of service=driveway2

[Brian M. Sperlongano]

Since there seems to be community consensus for the removal, I have
notified the main proponent at:

https://www.openstreetmap.org/changeset/130249355

And also opened a matching thread on the community forum.

On Tue, Jun 27, 2023 at 6:07 AM Andy Townsend  wrote:

> On 25/06/2023 00:02, Brian M. Sperlongano wrote:
> > And indeed, nine months later, we see that not only has the work not
> > gotten done, but while we all squabbled away with our pet views about
> > automated editing, we find that we agreed to nothing, and the mapper
> > has quietly continued to add this nonsense tag to the database unabated:
> > https://taginfo.openstreetmap.org/tags/service=driveway2#chronology
> >
> > For the original thread, see:
> >
> https://lists.openstreetmap.org/pipermail/talk/2022-September/087734.html
> >
> Has anyone actually mentioned this discussion to the proponent of the
> tag?  If I've got the right user (and I may not have)
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=741163
> suggests not.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed bulk removal of service=driveway2

[Brian M. Sperlongano]

On Mon, Sep 5, 2022 at 12:00 PM Tobias Knerr  wrote:

> On 03.09.22 at 12:52, Simon Poole wrote:
> > Anyway IMHO this would seem to make more sense as a maproulette
> > challenge or osmose warning than a bulk edit given the number is quite
> > manageable and at least some of the objects can probably be mapped to
> > one of the "proper" subtypes.
>
> Perfect is the enemy of good and insisting on doing it manually will
> just result in the work not getting done.
>
> I support doing this as an automated edit. Anyone who wants to set up a
> Maproulette task to inspect all ways that were previously tagged
> service=driveway2 is welcome to do so. This way, if the task doesn't get
> done, at least it won't have prevented the removal of a nonsensical and
> confusing value from the database.
>

And indeed, nine months later, we see that not only has the work not gotten
done, but while we all squabbled away with our pet views about automated
editing, we find that we agreed to nothing, and the mapper has quietly
continued to add this nonsense tag to the database unabated:
https://taginfo.openstreetmap.org/tags/service=driveway2#chronology

For the original thread, see:
https://lists.openstreetmap.org/pipermail/talk/2022-September/087734.html
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

[Brian M. Sperlongano]

On Wed, May 3, 2023 at 3:38 PM Mike Thompson  wrote:

> On Wed, May 3, 2023, 1:00 PM Brian M. Sperlongano 
> wrote:
>
>> I would caution against hyper-simplifying the combativeness of
>> the mailing lists
>>
> I am not sure using a term such as "combative" is going to be effective in
> bringing about the change you desire.   First the term has strong negative
> connotation
>

Whether it's negative is a value judgment, but it's absolutely my
observation. For me, it's descriptive, and I've simply adapted to dealing
with it to get things done on the project. So far, the mailing list hasn't
gone away as a relevant communication space, though I do agree that its
influence is waning. So here I am, dealing with it out of necessity.
However, I absolutely believe people when they express disdain for this
forum.

and second it is non specific.
>

When I send a message to the list, I craft it with several expectations
regarding how it will be received.

I expect that every word of any message I send to the lists may be picked
apart and quoted out of context. I expect that my motivations may be
questioned and that commenters will assume a hidden agenda. I expect
argumentation, criticism, judgment, and accusations that I should have
known better or been aware of a more correct or expected
behavior, principle, or expectation. I expect my
personal/professional/project affiliations, nationality, demographics, and
socio-economic status to be scrutinized in search of bias. I expect threads
to diverge into rabbit holes and meta-discussions. I expect new ideas to be
quickly dismissed. I expect the forest may be lost for the trees and for
hyper-specific details to be nitpicked. I expect that good-faith proposed
solutions to problems may be dismissed without offering alternatives. I
expect to be held to an unreasonable or unattainable standard of evidence
or performance.

That is probably not an exhaustive list, but that's what I mean by
combative, and I don't think that minor changes in word choice will change
the fundamental nature of how people communicate here. I'm sure I'm not
alone in this experience.

And worse, to meaningfully participate here, I often feel compelled to
engage in many of these same combative behaviors that I'm describing to
make my voice heard against this backdrop, so it becomes self-reinforcing.

The people you view as combative probably don't see themselves as combative
> and don't what specifically is causing you to perceive them as such, and
> thus don't know what to do differently.
>

Indeed.

That's why I'm glad that people much smarter than I am on these topics are
exploring the problem.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

[Brian M. Sperlongano]

I would caution against hyper-simplifying the combativeness of the mailing
lists as "cultural differences". I can think of several German participants
on Slack and Discord that dispel this stereotype.  Similarly, I can think
of several American commenters who are notoriously abrasive on the mailing
lists.  Some have suggested that "open source absolutists" as a group are
the issue. However, we don't seem to have the same complaints about the new
Discourse community forum. Other explanations I've heard suggest that
real-time chat, moderation, and emoji reactions make for a more
collaborative atmosphere for some reason. I don't have the answer, but I
think this thread highlights that there are very real differences in the
various communication spaces that are worth exploring. I welcome any effort
to learn more about how we can maximize people's willingness to participate
in the project. If a meaningful demographic is repeatedly saying that
people's behaviors in communication spaces are reducing participation, I
don't think that should be dismissed or hand-waved away with simple
explanations. Unlike others apparently, I don't especially care who does
that research. If the data, analysis, or methodology are bad or opaque then
that will speak for itself. In the meantime, I assume good faith and await
what the people willing to get their hands dirty and work on the problem
have to say.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Survey about OSM communication behaviors

[Brian M. Sperlongano]

On Sun, Apr 30, 2023 at 1:06 PM Courtney 
wrote:

> This conversation has opened up important new questions.  Why is the main
> "Talk" channel the only one that is producing pushback? Why is it the only
> one that is producing such a negative tone?
>


> I don't understand the degree of ire and frankly, incredulity that is
> being levied here.
>


> Is that the standard here? Wait for perfection or do nothing?  Is that how
> OSM itself was built? I don't understand the tone or the defensiveness of
> these comments. If the goal is to advance the OSM project, is it better to
> gate keep all inquiries to a suffocating degree?
>

I'd say you've succinctly captured the nature and character of this
particular communication channel and illuminated one reason why so little
chatter happens here compared to elsewhere.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

[Brian M. Sperlongano]

I agree with the proposed edits.

On Sat, Feb 11, 2023 at 12:58 PM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

> Errata: paragraph 4 from the bottom should be
>
> "There is no point in manual drudgery here, with values clearly
> replaceable by better matches."
>
> sorry, I copied wrong bot edit justification template.
>
> Feb 11, 2023, 18:48 by talk@openstreetmap.org:
>
> I propose to replace following surface tags by doing an automated edit:
>
> obvious typos:
>
> `surface=paving stones` → `surface=paving_stones`
> `surface=Paving_stones` → `surface=paving_stones`
> `surface=paving_stones:` → `surface=paving_stones`
>
> different form than standard surface value:
>
> `surface=wooden` → `surface=wood`
> `surface=cobblestones` → `surface=cobblestone`
>
> Polish name to English one:
>
> `surface=żwirowa` → `surface=gravel`
> `surface=kostka` → `surface=paving_stones`
> `surface=gruntowa` → `surface=unpaved`
>
> English vs very close to English but actually different:
>
> `surface=asfalt` → `surface=asphalt`
>
> Edit would be automatic, rerun from time to time, split into small
> changeset by geographic areas and run by
>
> https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history%20bot%20account
>
> Why it is useful? It helps newbies to avoid becoming confused. It
> protects against such values becoming established. Without drudgery
> that would be required from the manual cleanup. It also makes easier to
> add missing surface= values
>
> Why automatic edit? I have a massive queue (in thousands and tens of
> thousands) of automatically detectable issues which are not reported by
> mainstream validators, require fixes and fix requires review or
> complete manual cleanup.
>
> There is no point in manual drudgery here, with values completely useless.
>
> This values here do NOT require manual overview. If this cases will
> turn out to be an useful signal of invalid editing than I will remain
> reviewing nearby areas where bot edited.
>
> And I fixed some manually and they were not a great sign of a problematic
> data.
>
> Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
> map data quality will improve.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Dubious websites added to tourist attractions?

[Brian M. Sperlongano]

Looks like most of these have been cleaned up but there's a couple left:

https://overpass-turbo.eu/s/1qU8

On Thu, Feb 2, 2023 at 11:13 AM Dave F via talk 
wrote:

> Hi
>
> You may wish to take a look at these changesets by a single contributor to
> decide if  you think these are  dubious websites added to tourist
> attractions.
>
> https://www.openstreetmap.org/user/Aliaksandr%20Kopyshau/history#map=1/37/3
>
> The one in my locale had poor spelling (translation to English?) &
> grammar, took a long time to load & claimed if was copyright of the
> organisation/object that the webpage was about, even though it clearly
> wasn't (It was a bridge owned by the local authority).
>
> They all have similar, yet slightly different URLs
>
> From the wiki:
> The website tag can be used to provide the full URL to the
>
> *official website. *These are clearly not official.
>
> DaveF
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[Brian M. Sperlongano]

Navigational landmarks while hiking.

On Wed, Jan 18, 2023, 10:17 PM john whelan  wrote:

> Perhaps you could expand on the benefits of mapping them?
>
> Thanks John
>
> On Wed, Jan 18, 2023, 10:09 PM stevea,  wrote:
>
>> I'd like to say "oh, please..." because this seems a bit harsh.  But I
>> understand that people can be sensitive.
>>
>> But this is OSM and I'd like to believe we live in a world that is more
>> free rather than less free.  What's next, do we stop mapping pre-school or
>> kindergartens because they have children?
>>
>> Criminals are going to use maps, yes, that is going to happen.  We
>> mappers ourselves are not criminals for mapping.
>>
>> Map.  Map well.  Criminals will be criminals.  While there are book
>> banning people, librarians are not criminals.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[Didier M.]

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

Re: [OSM-talk] Use of "Proprietary" imagery to edit OSM

[Brian M. Sperlongano]

On Sun, Oct 30, 2022 at 9:00 PM Minh Nguyen 
wrote:

> Vào lúc 07:11 2022-10-30, Greg Troxel đã viết:
> > But then the company doing the editing should document which company's
> > imagery and which revision year they are using.   Things should be as
> > transparent as possible, and this doesn't feel that way.
>
> We could ask if the honor code should apply to such a prolific editing
> team. But do we actually have a problem with Lyft fabricating edits? I
> haven't seen evidence of that; it would be quite surprising for a
> company so invested in our project.
>

I have to say, I'm pretty unconcerned with abstract notions of
"transparency" here, as the entire project essentially works on the honor
system.  What I am concerned about is, if an editor is using an imagery
source that a random mapper can't access, they ought to at least indicate
the age of that imagery, to assist the next mapper that looks at the edit,
to understand why an edit may appear different from the current publicly
available imagery.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] razed railways and other things that don't exist today

[Brian M. Sperlongano]

On Tue, Oct 25, 2022 at 1:45 PM Colin Smale  wrote:

> Are underground pipelines and electricity transmission cables just as
> controversial? They are covered over, built on, and completely unobservable
> from the surface. They may also have been taken out of service many decades
> ago.
>

In the US, generally no.  They are quite infrequently mapped, and they're
tagged as an underground feature when they are.  That's quite a different
scenario from an ostensibly above-ground feature that is not present to the
above-ground observer.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] razed railways and other things that don't exist today

[Brian M. Sperlongano]

On Tue, Oct 25, 2022 at 4:37 AM Frederik Ramm  wrote:

> in the spirit of friendly collaboration I would say that a limited amount
> of
> stuff-that-should-not-be-in-OSM can be *tolerated*. If someone does a
> lot of good work for OSM otherwise and would really like to record an
> ancient former railroad that ran through where their house now sits - I
> shrug and let them do it.


In my experience, it is more often the opposite situation that happens.  A
mapper, unaware of the lengthy debates on the topic of former railroads, is
mapping her house and removes the bit of abandoned rail currently on the
map in that spot, assuming it is a data error or poor import.  After
all. she's quite aware that there is a house and not a railway at that
location as she has personally surveyed it.  Sometime later, an abandoned
railway enthusiast comes along and angrily harasses the mapper for removing
the bit of railway that quite rightly isn't there. It's been my experience
that allowing enthusiasts to map phantom railways causes far more grief and
contention between mappers than simply drawing a line and saying "we don't
map things that aren't there."
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-se] highway=trunk in Sweden

[Brian M. Sperlongano]

Given this, can you comment specifically on an example?  OSM way and photo
below:

https://www.openstreetmap.org/way/199230893
https://www.mapillary.com/app/?focus=photo=WgHheFQe7tkY-5yEbWchbA=57.6457275332997=11.96102332764884=17

Should that way get tagged with any of the following:

1) foot = no
2) motorroad = yes
3) sidewalk = no + shoulder = no

?


On Sat, Jan 23, 2021 at 3:10 PM Ture Pålsson via Talk-se <
talk-se@openstreetmap.org> wrote:

>
>
> 23 jan. 2021 kl. 20:48 skrev Ture Pålsson :
>
> If the wiki is to be believed, highway=trunk is used for roads declared by
> the government to be ”nationell stamväg”, which translates literally to
> ”national trunk road”, except the bits of those that are highway=motorway.
> This, by itself, says nothing about the accessibility for pedestrians. As
> far as I can tell, one must look for explicit foot=* or motorroad=* tags to
> determine pedestrian rights.
>
>
> I should add for clarity that walking is allowed everywhere (on public
> roads) except where explicitly forbidden, which it is on motorways,
> motorroads (E1/E3 here:
> https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Anvisningsmarken/),
> and roads with the ”no pedestrians” sign (C15 here:
> https://www.transportstyrelsen.se/sv/vagtrafik/Vagmarken/Forbudsmarken/).
>
> (And when you leave the public roads, walking is still allowed almost
> everywhere, but then you’re probably not on a highway=trunk anymore! :-) )
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-us] Extremely long Amtrak route relations

[Brian M. Sperlongano]

It seems that OSM has a an architectural problem with over-large relations?
>
+1

The Tongass National Forest [1] was recently mapped with great detail.  It
comprises most of the Alaska panhandle and all of its islands and inlets.
The relation has 28,000 members and contains over 2 million nodes.  It does
not load on osm.org, and is single-handedly responsible for a 48-hour
increase in the amount of time it takes to render the global tileset.

Meanwhile, on the opposite coast, a few users moved all of Hampton
Roads/Chesapeake Bay, and all of its inlets and estuaries, inside the
coastline [2], in order to speed up the amount of time it takes to render
the coastline and reduce the frequency of users breaking coastline
continuity.  A heated discussion on this continues over on the tagging list.

Personally, I think if the world is complicated, the model should be
complicated.  If the thing we're modeling is large in the world, it should
be large in the map.  It seems that we are increasingly doing things to
simplify the model because certain tooling can't handle the real level of
complexity that exists in the real world.  I'm in favor of fixing the
tooling rather than neutering the data.

[1] https://www.openstreetmap.org/relation/6535292
[2] https://www.openstreetmap.org/changeset/94093155
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] How is protect_class used in Canada?

[Brian M. Sperlongano]

Great idea.  I just sent out a message to user webfil, who seems to have
initially mapped those lands.

On Mon, Nov 16, 2020 at 8:16 AM john whelan  wrote:

> >I am guessing that some or all of the categories on that list under
> class 7 can simply be deleted.
>
> Have you attempted to contact the original mappers?
>
> We have a few mappers in Canada who have been mapping for more than ten
> years.
>
> John
>
> On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
> wrote:
>
>> Hello neighbors to the north,
>>
>> I have been working to clean up and improve documentation on tagging of
>> protected areas.  I've found that in many cases the documentation on the
>> wiki does not match how tagging is actually done in real life, so I am
>> working to make the wiki more accurate and make the information more useful
>> to mappers.
>>
>> The wiki [1] lists seven different categories that are tagged
>> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
>> them, but the other items in the list looked like generic terms that were
>> just tossed in there by the original author ~10 years ago.
>>
>> So..  what does protect_class=7 tagging mean in Canada?  Does this have
>> real meaning or is it a long-ago forgotten convention?  Since this value
>> does not render on the default map, it is always paired with something like
>> leisure=nature_reserve to force the drawing of an outline.  An overpass
>> inspection [2] shows that this value is almost entirely in Quebec.
>>
>> I am guessing that some or all of the categories on that list under class
>> 7 can simply be deleted.  I'd like to understand how this tagging is
>> actually used in order to make the documentation useful and/or understand
>> what the Canadian consensus for how these values *should* be used.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
>> [2] https://overpass-turbo.eu/s/10bS
>>
>> -Brian (Rhode Island, USA)
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] Your experience in reaching out to Maps.me users ?

[Brian M. Sperlongano]

Huh. Yes, that's exactly what it did.  Certainly not the behavior I'd
expect.

On Thu, Nov 12, 2020, 11:58 AM Michał Brzozowski 
wrote:

> Hi Brian, the comment was probably made into an OSM Note. Check Notes on
> that OSM user page.
>
> Greetings
> Michał
>
> czw., 12 lis 2020, 17:56 użytkownik Brian M. Sperlongano <
> zelonew...@gmail.com> napisał:
>
>> I downloaded and made a test edit (adding an address to a local POI) with
>> maps.me just now to understand how it works.  It does at least make you
>> log in to OSM.  I entered in a comment on the change, however, I note that
>> maps.me overwrote my user-entered comment with a generic comment in the
>> changeset.
>>
>> On Thu, Nov 12, 2020, 10:27 AM Stephan Knauss 
>> wrote:
>>
>>> Hello,
>>>
>>> On 12.11.2020 10:55, Jean-Marc Liotier wrote:
>>> > Is it just me or are Maps.me Openstreetmap contributors unaware of
>>> > Openstreetmap messages ? Does anyone here have seen Maps.me
>>> > Openstreetmap contributors answer to Openstreetmap messages ?
>>>
>>> I share your experience. Typical maps.me edits are of low quality and
>>> frequently show a misuse of tags, certainly not following to our
>>> community standards.
>>>
>>> I have a very low response rate on comments. Probaly one out of hundred
>>> responds. And I have not seen them going back to fix their edits ever.
>>>
>>> I think OSM API should block edits until email address is confirmed.
>>> And probably re-check the response to emails once a year or switch the
>>> account into read-only mode.
>>> Participating in changeset discussions or using osm messaging could
>>> reset that counter as well.
>>>
>>> Stephan
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Your experience in reaching out to Maps.me users ?

[Brian M. Sperlongano]

I downloaded and made a test edit (adding an address to a local POI) with
maps.me just now to understand how it works.  It does at least make you log
in to OSM.  I entered in a comment on the change, however, I note that
maps.me overwrote my user-entered comment with a generic comment in the
changeset.

On Thu, Nov 12, 2020, 10:27 AM Stephan Knauss 
wrote:

> Hello,
>
> On 12.11.2020 10:55, Jean-Marc Liotier wrote:
> > Is it just me or are Maps.me Openstreetmap contributors unaware of
> > Openstreetmap messages ? Does anyone here have seen Maps.me
> > Openstreetmap contributors answer to Openstreetmap messages ?
>
> I share your experience. Typical maps.me edits are of low quality and
> frequently show a misuse of tags, certainly not following to our
> community standards.
>
> I have a very low response rate on comments. Probaly one out of hundred
> responds. And I have not seen them going back to fix their edits ever.
>
> I think OSM API should block edits until email address is confirmed.
> And probably re-check the response to emails once a year or switch the
> account into read-only mode.
> Participating in changeset discussions or using osm messaging could
> reset that counter as well.
>
> Stephan
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Use of area/relation icons on boundaries

[Brian M. Sperlongano]

Hello,

I've been working to improve various pages on the Wiki.  I've encountered
inconsistencies in how the "area" and "relation" icons are used in the wiki
documentation of boundary relations.  It's not clear which of the two icons
should be used when describing tags that may be applied to boundaries (as
opposed to mere multipolygons).  Various pages across the wiki are using
the icons inconsistently, and having consistent pictoral representations
are useful in providing clear documentation and intent to the community.

I wrote up a more detailed description of the problem on Talk:Wiki and
would appreciate community input on which convention should be used:

https://wiki.openstreetmap.org/wiki/Talk:Wiki#Usage_of_icons_on_boundaries
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] [OSM-talk] changeset: 89516909

[Brian M. Sperlongano]

I see.

Considering that, I've reverted my changes.

On Tue, Aug 18, 2020 at 9:41 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> i was told i could not use do to licence GIS to.
>
>
>
> Tuesday, August 18, 2020 8:38 PM -05:00 from Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
> All,
>
> I fixed this boundary relation and also one neighboring town (Wheeling,
> IL) using the Cook County, Illinois GIS as the data source, and re-used all
> of the original boundary relations.  Unfortunately it appears that all of
> Cook County needs to be updated to reflect the county GIS data (found here:
> https://hub-cookcountyil.opendata.arcgis.com/pages/boundary-open-data).
> Those census polygons are fairly close, but different.  The two border
> towns I checked just north in Lake County appear to line up perfectly with
> the Cook County data so this might just be a Cook County issue.  This is a
> start but there's lots of work to do there.
>
>
> On Tue, Aug 18, 2020 at 9:10 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> lines no relations yes
>
>
>
> Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson <
> miketh...@gmail.com
> >:
>
>
>
> On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> <http://e.mail.ru/compose/?mailto=mailto%3atalk%2...@openstreetmap.org>>
> wrote:
>
> i will fix anything that i missed but the lines are truth.
>
> and it is not a polygon,
>
> As far as I know, boundary relations have to, in effect, be polygons, in
> other words, they have to close.
>
>
> and i broke nothing i fixed what the other guy broke and did it all by
> hand.
>
> The boundary relation (126598)  is currently broken. for one thing, it
> doesn't close at the location of Williamsberg Square residential area.
> ___
> talk mailing list
> t...@openstreetmap.org <http:///compose?To=t...@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/talk-us
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org <http:///compose?To=talk%2...@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] changeset: 89516909

[Brian M. Sperlongano]

All,

I fixed this boundary relation and also one neighboring town (Wheeling, IL)
using the Cook County, Illinois GIS as the data source, and re-used all of
the original boundary relations.  Unfortunately it appears that all of Cook
County needs to be updated to reflect the county GIS data (found here:
https://hub-cookcountyil.opendata.arcgis.com/pages/boundary-open-data).
Those census polygons are fairly close, but different.  The two border
towns I checked just north in Lake County appear to line up perfectly with
the Cook County data so this might just be a Cook County issue.  This is a
start but there's lots of work to do there.


On Tue, Aug 18, 2020 at 9:10 PM 80hnhtv4agou--- via Talk-us <
talk-us@openstreetmap.org> wrote:

> lines no relations yes
>
>
>
> Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson <
> miketh...@gmail.com>:
>
>
>
> On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us <
> talk-us@openstreetmap.org
> > wrote:
>
> i will fix anything that i missed but the lines are truth.
>
> and it is not a polygon,
>
> As far as I know, boundary relations have to, in effect, be polygons, in
> other words, they have to close.
>
>
> and i broke nothing i fixed what the other guy broke and did it all by
> hand.
>
> The boundary relation (126598)  is currently broken. for one thing, it
> doesn't close at the location of Williamsberg Square residential area.
> ___
> talk mailing list
> t...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Comptage d'objets avec overpass

[Marc M.]

Le 29.06.20 à 22:34, Florian LAINEZ a écrit :
> j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp

non ce n'est pas ce que tu as demandé dans ta requête
avec (._;>;); tu demandes aussi tous les objets "enfants"
cad les noeuds des ways qui les composent
du coup le comptage les contient.

je sort la hache pour virer tout ce qui n'est pas utile
https://overpass-turbo.eu/s/VAD
résultat 4 nœuds 4 chemins = 8 :)
a noter que out count est encore plus clair pour faire
des stats https://overpass-turbo.eu/s/VAE

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

Re: [OSM-talk-fr] Alternative locale à Mapillary

[Marc M.]

Bonjour,

Le 29.06.20 à 12:19, Eric SIBERT a écrit :
> Question : y a-t-il un moyen de faire quelque chose de similaire sans
> passer par Mapillary?

il y a une discussion un clic à côté :)
en gros on expérimente diverses briques
la brique pour récupérer les images depuis un compte mapillary va bien,
les afficher sur une carte aussi. tout le reste est à faire ou à
(re)trouver.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

[Marc M.]

Le 29.06.20 à 10:39, Yves P. a écrit :

> *hiking*=yes je ne le met pas car dans ma région il servent  
> autant pour les randos pédestres, vélo, VTT, cheval…

ou mettre les 3 (parce que si tu veux sélectionner "chevaux",
ca va être compliqué de faire une requête "si région=celle
de yves, alors pas de valeur=vélo+vtt+cheval" :)
il y a souvent des pictogrammes indiquant les moyens de transport,
c'est dans ce sens là que j'ajoute ces tags.

> *pole:position* a-t-il encore un intérêt avec une qualité correcte
> d'orthophotos et surtout une vue mapillary ?

sûrement du détail peu utile, (pour les bornes incendies, on le fait
parfois quand la borne est masquée par les hautes herbes. pour un
poteau je doute que la végétation monte si haut)
Mais j'aurais surtout utilisé la clef courante location=*

> *start_date* ?

c'est quoi la question ?

> *arrows* n'est pas standard et est-ce vraiment utile.

j'aurais mis direction=les 3 valeurs

> mapillary:wide
> Je propose donc de ne mettre que la photo la plus lisible

proposer d'effacer est rarement le plus agréable.
mapillary=valeur1;valeur2;valeur3
si c'est logiciels ont du mal avec le support des valeurs
multiples, il faut les améliorer au lieu d'effacer des données.

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

Re: [OSM-talk-fr] coupure serveur overpass-api osm.fr

[Marc M.]

Bonjour,

Le service est rétablit sur osm47
https://overpass-turbo.eu/s/Vyy
Il devrait être plus rapide qu'avant.
n'hésitez pas à signaler d'éventuelle anomalie
ici ou sur tech ou sur github
https://github.com/osm-fr/infrastructure/issues/19

A suivre :
- les améliorations pour le rendre plus robuste aux pannes
- maj du code overpass (pour entre autre nwr)
- le retour des graphes munin

Cordialement,
Marc

Le 26.06.20 à 12:39, Marc M. a écrit :
> Bonjour,
> 
> pour diverses raisons (manque d'harmonisation entre les hosteurs,
> soucis de perf sur l'un d'eux), les 2 serveurs overpass-api osm-fr
> subissent des jours de lag, au point que j'ai coupé le service.
> 
> une nouvelle base est en cours de maj sur un ssd
> avec l'espoir d'y réactiver le service ce we.
> s'en suivra la maj applicative tant attendue,
> ainsi que diverse amélioration pour essayer de rendre cela
> plus robuste
> 
> Cordialement,
> Marc
> 


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

Re: [OSM-talk] OSM Carto not updating

[Marc M.]

Le 28.06.20 à 14:23, Ture Pålsson a écrit :
>> 27 juni 2020 kl. 17:20 skrev Marc M. :
>> Le 27.06.20 à 17:04, ET Commands a écrit :
>>> Is something wrong with the OSM Carto servers?
>> one diff freeze the update
>> sequenceNumber=4082799
>> timestamp=2020-06-26T19:17:02Z
>> ppl on #osm-dev are working on this.
> Does anyone have the osm ID of the geometry that tripped things up? Seems 
> like a good test case. :-)

tmp fix target 3 relations with multiples errors (self-crossing outer)
https://overpass-turbo.eu/s/Vxd

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

Re: [OSM-talk] OSM Carto not updating

[Marc M.]

Le 28.06.20 à 00:25, Lynn W. Deffenbaugh (Mr) a écrit :
> Where is #osm-dev? 

on irc://irc.oftc.net/osm-dev

info about irc/web/mnatrix client
https://wiki.openstreetmap.org/wiki/IRC

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc M.]

Le 26.06.20 à 14:09, Florian Lohoff a écrit :
>> I don't care about SLA. Does OSM have SLA?
> The point is when you distribute your storage to people at
> home we will have at most 10% of images online all the time.

what facts are you basing that number on ?
The worst internet connection I have has 98% availability.
of course, it's not mandatory to have a pay-per-use dialup :)
not to mention local chapters or companies with servers in datacenters
or with fiber connection (where 2 instances of the PoC are running
right now).

> Disregarding the case that upstream bandwidth internationally
> is pretty bad so you tend to have access times
> for images of about 4-5 seconds at best. (3MByte image at
> a typical ADSL upstream with 1.5MBit/s and international latencys)

your logic does not correspond to a distributed storage.
it is not "one disk that sends one photo to one user"
it is the pool that sends the pool of requests to all users.
if you have 1000 adsl to serve 100 simultaneous requests,
this is the equivalent of 15Mb/s par request (minus the management).
I leave it up to you to imagine an order of magnitude for the conversion
between simultaneous requests and users.

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

Re: [OSM-talk-fr] maj base de rendu bloquée (osm.org, osm.fr, osm.ch et surement d'autres)

[Marc M.]

Le 27.06.20 à 20:35, Jacques Lavignotte a écrit :
> Le 27/06/2020 à 17:24, Marc M. a écrit :
>> pour info, un diff bloque le maj des bases de rendu utilisant osm2pgsql,
> 
> Merci de nous informer, Marc
> 
> De quelle machine s'agit-il ?
> 
> https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France

pour osm-fr c'est https://munin.openstreetmap.fr/osm-day.html
(osm25 a en plus un bug dans son graphe, osm105 était déjà ko
par arrêt des soins palliatifs avant ce bug ci).

pour osm.org c'est https://munin.openstreetmap.org/renderd-day.html
partie "Data import lag"

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

[OSM-talk-fr] maj base de rendu bloquée (osm.org, osm.fr, osm.ch et surement d'autres)

[Marc M.]

Bonjour,

pour info, un diff bloque le maj des bases de rendu utilisant osm2pgsql,
entre autre celle de osm.org, osm.fr, osm.ch
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z

On attend le correctif :)

Regards,
Marc

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

Re: [OSM-talk] OSM Carto not updating

[Marc M.]

Hello,

Le 27.06.20 à 17:04, ET Commands a écrit :
> Is something wrong with the OSM Carto servers?

one diff freeze the update
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z
ppl on #osm-dev are working on this.

Regards,
Marc

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

Re: [OSM-talk-fr] Nouveau jeu de données IdfM (STIF)

[Marc M.]

Bonjour,

Le 26.06.20 à 11:19, Florian LAINEZ a écrit :
> Ile-de-france-mobilité, l'autorité organisatrice des transports
> anciennement nommée STIF, vient de publier un jeu de données comparant
> leurs données avec celles d'OSM :
> https://data.iledefrance-mobilites.fr/explore/dataset/ecarts-arrets-referentiel-et-openstreetmap/information/

y a-t-il un moyen de flager erreur côté opendata <> osm <> a vérifier ?

comment fonctionne le menu de gauche ? j'ai essayé de trouver
l'arrêt avec une différence de 7km, il m'affiche  Filtres actifs
Distance (m) 7460 mais j'ai toujours toutes les différences sur la carte

Cordialement,
Marc

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc M.]

Hello,

Le 26.06.20 à 12:42, Florian Lohoff a écrit :
> this is NOT a trivial

no one said it is trivial, or it would be over by now.
but some of us try more positive alternatives than "sitting
down and doing nothing because it's impossible".
maybe it will succeed, maybe it will only be 1/10th of what
is hoped for, maybe it will not succeed.

with this in mind 20k€/year for storage is one to explore.
distributed storage, too.

I don't care about SLA. Does OSM have SLA?
No, we're doing the best we can.

today, it is easy to make a map for your own photo storage.
it's also possible to make a thematic instance for a local community.
it's possible and easy to feed it from your mapillary account.
it's already not so bad!

i don't remember osm starting with a 100k£ call before the first test.
thanks to the precursors for not being aware that it's not a hobby pet
project someone is running from his/her basement.

Regards,
Marc

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

[OSM-talk-fr] coupure serveur overpass-api osm.fr

[Marc M.]

Bonjour,

pour diverses raisons (manque d'harmonisation entre les hosteurs,
soucis de perf sur l'un d'eux), les 2 serveurs overpass-api osm-fr
subissent des jours de lag, au point que j'ai coupé le service.

une nouvelle base est en cours de maj sur un ssd
avec l'espoir d'y réactiver le service ce we.
s'en suivra la maj applicative tant attendue,
ainsi que diverse amélioration pour essayer de rendre cela
plus robuste

Cordialement,
Marc

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

Re: [OSM-talk-fr] listing des cinémas sur data.gouv

[Marc M.]

Le 26.06.20 à 10:59, PanierAvide a écrit :
> qu'est-ce qui serait à documenter, et où ?

si un jour quelque chose se grippe et que les fichiers ne sont plus
à jour sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/ il va
chercher pourquoi ou cliquer sur "contacter openstreetmap".
celui chez qui cela arrive (je sais même pas qui) serra content
d'avoir les 4 lignes que tu viens d'écrire :)

je ne sais pas vraiment quel est le meilleur endroit pour cela.
faire une page wiki.openstreetmap.org listant les différents export
du compte osm sur data.gouv.fr ?

genre
sujet / source / hébergement / code / url
ciné / download.osm-fr/... / OpenDataFrance /
https://framagit.org/PanierAvide/GeoDataMine /
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/

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

Re: [OSM-talk-fr] listing des cinémas sur data.gouv

[Marc M.]

très sympa.
suggestions : documenter quelque part et ajouter un lien vers ce quelque
part sur le comment cela tourne (où est le code qui prend le dump
geodatamine pour l'envoyer sur www.data.gouv.fr, où cela tourne,
où signaler une anomalie si un jour c'est ko

Le 25.06.20 à 18:41, PanierAvide a écrit :
> Pour les curieux, les exports sont disponibles via GéoDataMine pour
> toutes les thématiques présentes dans l'outil (France métropole +
> DROM/COM, màj quotidienne) : https://geodatamine.fr/dump/
> 
> Adrien P.
> 
> Le 25/06/2020 à 17:58, Florian LAINEZ a écrit :
>> Hey, cadeau du jour : un extract quotidien des cinémas de france sur
>> data.gouv :
>> https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/
>> Merci de ne pas encore communiquer largement sur le sujet : ce n'est
>> qu'une première version, vu tout le boulot qu'on est en train de mener
>> sur le sujet actuellement, attendez vous à voir bouger les données.
>> On espère avoir une "V1" d'ici quelque temps donc votre aide est la
>> bienvenue pour améliorer les données dans OSM. En particulier on a
>> besoin d'aide pour créer les infos de contact : adresse, numéro de
>> téléphone, site web, page facebook ...
>>
>> Avec Adrien on va par ailleurs publier pas mal de nouveaux jeux de
>> données sur data.gouv sur des sujets différents, on vous tient au jus
>> pour ça aussi.
>>
>> -- 
>>
>> *Florian Lainez*
>>
>> @overflorian 
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Zone de croisement pour fauteuil roulant

[Marc M.]

Bonjour,

Le 25.06.20 à 22:38, Emmanuel Aubert a écrit :
> il y a des pistes piétonnes  pas bien larges.
> Sur ces pistes, il y a des surfaces que je soupçonne être 
> des zone de croisement. 
> Y a t’il un tag pour ça ?

un bout de way avec le width=* qui va bien ?

Cordialement,
Marc

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc M.]

Le 25.06.20 à 16:16, Florian Lohoff a écrit :
> Mapillary themselves say on their web pages that they already
> have 1,199,363,907 images. Thats 3515625 GB or 3.5TB Data 
> assuming 3MByte per image.

3 500 000 GB ~ 3 500 TB ~ 3.5 PB ?
~100k€ ~100k$ hardware cost for the storage.
or 1000 people sharing a 6TB disk on a distributed system

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

Re: [Talk-us] National Forest boundaries

[Brian M Hamlin]

seconded stevea -- very interesting and cogent, definitely reading these 
National Forest expositions


best regards from Berkeley, California   --Brian M Hamlin MAPLABS



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

Re: [OSM-talk-fr] Bano v2

[Marc M.]

Bonjour,

Le 24.06.20 à 09:40, Cyrille37 OSM a écrit :
> Le 07/05/2020 à 10:59, Marc M. a écrit :
>> la veille base dont il dépend ne se met plus à jour
>> depuis le 11 avril, et donc les fichiers produits ne le sont pas.
> 
> C'est largement suffisant pour être très utile.

ce n'est pas moi qu'il faut convaincre :)

hélas le serveur n'a pas l'option upgrade
--inutilement-différent-des-autres-mais-fix-sans-que-j-y-passse-des-heures
:)
la culture du "mutualisation minimale" a un prix humain et fonctionnel,
les mêmes choix conceptuels sont discutés pour la v2, avec donc
les mêmes conséquences tant à court terme (l'install) qu'à long terme
(la maintenance)

Merci à Jacques d'avoir trouvé une des causes (fichier de style
contenant une ip publique en dur, hors celle-ci ont changés récemment)
j'ai appliqué le correctif.

a vu de nez, il y en a au moins encore 2 (droit sur la bdd, https)

Cordialement,
Marc

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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr ???

[Marc M.]

Bonjour,

Le 23.06.20 à 11:37, Hélène PETIT a écrit :
> Après une migration mouvementée de win7 à debian10

félicitations :)

> c'est chouette ; ça résout mon problème immédiat

et pour fêter cela, la configuration a été corrigée
pour http://cadastre.openstreetmap.fr
(adaptation du fichier de config suite à la maj
d'il y a 2-3 jours. c'était passé inapercu).

Cordialement,
Marc

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

Re: [OSM-talk-fr] feed mastodon cassé sur osm.fr

[Marc M.]

Le 23.06.20 à 18:48, Florian LAINEZ a écrit :
> -une belle 404 ;) https://www.openstreetmap.fr/null-island

c'est bien trouvé :)

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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Marc M.]

Le 23.06.20 à 15:56, Vincent Bergeot a écrit :
> Je pense que tout ne se ferra pas du jour au lendemain

pour préciser, la seule chose qu'il manque c'est la feuille
de style v2 tout le reste existe.
si qlq se sent d'attaque pour l'écrire, je la met sur un serveur
et cela tourne pendant qu'on discute philosophie sur tech :)

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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Marc M.]

Bonjour,

>> il y a des mois j'ai découvert BANO. Je l'utilisais selon mes besoins
>> et ma manière de contribuer. C'était lent, mais bon... ça marchait;
>> Y'a que moi que ça gêne ?

si tu parles du rendu ko depuis mai, non il n'y a pas que toi.
mais ceux qui savent le rétablir le savent, du coup bah...

Cordialement,
Marc

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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Marc M.]

Le 22.06.20 à 19:03, Christian Quest a écrit :
> je peux m'en charger en lançant le script sur un serveur perso

installe le front de fred pour supprimer la contrainte humaine ?

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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Marc M.]

Bonjour,

Le 22.06.20 à 10:29, Stéphane Péneau a écrit :
> Recensons les alternatives complètes ou partielles à Mapillary, les
> briques réutilisables, etc...

https://github.com/gitouche-sur-osm/mapillary_takeout
https://github.com/frodrigo/mapillary_takeout_web
en cours d'install sur l'infra osm.fr

> il manque au moins le floutage, le nerf de la guerre.

cela ne dépend-t-il pas du but et de l'accessibilité ?
par analogie geofabrik a restreint les données personnelles
aux contributeurs osm mais ils sont accessible aux contributeurs.
du coup un openstreetview accessible qu'aux contributeurs osm
est peut-être un groupe privé dispensé de ce genre de soucis.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Data OSM

[Marc M.]

Le 20.06.20 à 14:20, Georges Dutreix via Talk-fr a écrit :
> 
> Le 20/06/2020 à 12:53, Nelson Tayou a écrit :
>>
>> L'URL serait alors osmdata.openstreetmap.fr
>>  Qu'en pensez-vous ?
>>
> Pourquoi repréciser "osm" et pas plus simplement data.openstreetmap.fr
>  ?

data c'est ultra générique pour des données brutes
alors qu'ici c'est un outil précis et plus une interface
vers les données que les données eux meme.
sinon overpass turbo et api pourrait aussi devenir data
download.osmn-fr aussi
etc :)

moi j'aime l'idée que l'url d'un outil porte le nom de l'outil

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Marc M.]

Le 20.06.20 à 12:28, Andy Mabbett a écrit :
> Were you not aware that your contributions to OSM, and Mapilary, are
> already under an open licence, which allows anyone - including
> Facebook - to reuse them, even commercially?

having the right to download images is not at all the same thing
as, for example, having access to ip/cookies/timestamp
and a great deep learning database.

for some people, contributing to increasing FB profiling,
even with a open license, is not the same thing as contributing
to a open license database not owned by a gafam member.

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

Re: [OSM-talk-fr] Data OSM

[Marc M.]

Bonjour,

Le 20.06.20 à 12:53, Nelson Tayou a écrit :
> il est pas adequat vu la ressemblance avec "JOSM". 

c'est en effet mieux d'éviter la confusion orale.

> Nous avons envisagé un nouveau nom plus simple qui pourrait être "OSMdata".

j'aime le oeil à OpenData

Cordialement,
Marc

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Bonjour,

Le 19.06.20 à 17:01, Stéphane Péneau a écrit :
> Le 19/06/2020 à 16:23, Marc M. a écrit :
>> - des personnes pour établir les besoins/buts. ex faut-il faire
>> les 3 par défaut ? à l'époque c'était évidement, ajd p'tre que
>> l'utilisateur voudrait configurer le partage qu'à une partie des 3)
> Si on souhaite se défaire de ce genre de problème, il faut une solution
> complète qui ne soit pas rattachée à une entreprise.

j'entends bien ce que tu dis, mais il y a surement des contributeurs
souhaitant continuer à alimenter xyz
si un outil permet à ces personnes de contribuer à la solution
communautaire en même temps que leur solution favorite,
n'est-ce pas le meilleur moyen de les faire participer ?

pour être plus pragmatique, le démonstrateur peux en effet viser
à alimenter la copie locale et opentrailview par exemple.
et rien n'empeche qlq de faire un plugin pour alimenter xyz
par la suite

Cordialement,
Marc

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

Re: [OSM-talk-fr] Pas de cadastre ce matin

[Marc M.]

Le 19.06.20 à 10:30, Cyrille37 OSM a écrit :
>> https://tms.cadastre.openstreetmap.fr/*/tout/17/67603/46680.png
>> ne répond plus.
> 
> le ticket https://github.com/osm-fr/infrastructure/issues/188

c'est rétablit

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Bonjour,

Le 19.06.20 à 16:41, Vincent de Château-Thierry a écrit :
> si quelqu'un.e a *envie* qu'un démonstrateur "proxy Mapillary/OSC" voit le 
> jour, qu'il/elle n'hésite pas à se lancer

je ne partage pas ta vision du communautaire.

*j*'ai envie de me lancer dans le sujet, comme je l'avais dis
il y a plus d'un an.
mais ce que je n'ai pas envie, c'est d'un Xieme projet mono-leader
qui s'arrête ou se grippe le jour où le mono-leader est indisponible.
le monde libre est plein de projet agonisant, quel gâchis de ne
pas se concentrer sur le durable, ce qui implique aussi d'être
humainement durable. c'est en ce sens que je disais que la
communauté n'avait pas eu envie en 2018 du sujet, ou dit
autrement, il n'y avait pas une manifestation de porteur*s*
pour que l'idée se poursuive

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Le 19.06.20 à 16:15, PanierAvide a écrit :
> Plutôt un manque de temps / ressources ? 

du temps surement, les resources technique pour un démonstrateur
sont dispo (= entendre par là qu'il n'y a évidement pas 1000 To
disponible, mais la première étape est de faire un démonstrateur
avec une taille disque limitée)

> De quoi a-t'on besoin pour voir un tel mécanisme émerger ?

- des personnes pour établir les besoins/buts. ex faut-il faire
les 3 par défaut ? à l'époque c'était évidement, ajd p'tre que
l'utilisateur voudrait configurer le partage qu'à une partie des 3)
- un sysadmin pour créer une vm sur l'infra avec un peu d'espace,
je veux bien m'en charger
- choisir la techno pour avoir la marche à l'entrée la plus faible
- voir les briques existantes utilisables (par exemple ce qui
existe autour de mapillary/osc)
- réfléchir oü héberger la "propriété" du projet. osm.fr ? osmf ?
le premier est rapide à mettre en oeuvre, le 2ieme facilite
une collaboration mondiale sans qu'un s'approprie la chose.
- coder ce qui manque
- des utilisateurs qui l'utilisent :)
- rever la suite :)

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Le 19.06.20 à 08:50, PanierAvide a écrit :
> À quand un Mapillary/OpenStreetCam libre et décentralisé ? ;-P

lors de l'appel aux dons 2018, il avait été évoqué de faire
un démonstrateur permettant à un contributeur d'envoyer
ses photos à un seul endroit, à charge pour cet endroit
d'en faire une copie locale (permettant un usage communautaire
voir un jour entrainer un apprentisage) et un double envoi OSC/mapillary

domage que cela n'ai pas interessé la communauté à l'époque,
l'actualité montre bien les limites d'utiliser des outils non libre :
quand on est lié à l'ateur ou on perd en fonctionalité sans pouvoir
forker le tout

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

Re: [OSM-talk-fr] Fontaine fleurie

[Marc M.]

auqul on peux ajouter flowers=yes
même s'il manque sans doute un tag principal genre
landuse=flowerbed
landuse=meadow (pas trop du tout)
leisure=garden garden:style=flower_garden (micro-mapping ?)

Le 18.06.20 à 10:26, European Water Project a écrit :
> Je dirai ...  abandoned:amenity
> =fountain
> .
>  
> qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales
> sur une carte .
> 
> voici deux catégories où tu pourrais peut-être mettre cette photo :
> 
> https://commons.wikimedia.org/wiki/Category:Defunct_fountains  
> 
> https://commons.wikimedia.org/wiki/Category:Former_fountains  
> 
> 
> 
> On Wed, 17 Jun 2020 at 21:07, Yves P.  > wrote:
> 
> Bonsoir,
> 
> Comment taguer une fontaine remplie de terre et ornée de fleurs
> 
> 
>  ?
> 
> Il n'y a rien dans le wiki, je ne trouve pas non de catégorie dans
> Wikimedia (quel est le nom en anglais).
> 
> amenity=fountain seulement va dépiter les cyclistes et randonneurs
> assoiffés cet été :D
> disused:amenity=fountain va empêcher le rendu. Avec ou sans eau,
> c'est un bon point de repère…
> 
> __
> Yves
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Comment tagguer plusieurs caméras de vidéosurveillance sur un poteau

[Marc M.]

Bonjour,

Le 18.06.20 à 06:28, Quentin Salles a écrit :
> un poteau dans lequel 4 caméras sont posés dessus.
> Chacune de ces caméras cible différentes directions.

camera:direction =valeur1;valeur2;valeur3;valeur4
devices=4

Cordialement,
Marc

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

Re: [OSM-talk-fr] "Échallier" pour VTT

[Marc M.]

Bonjour,

Le 17.06.20 à 11:56, Yves P. a écrit :
> J'ai mis une photo dans la discussion Tag:barrier=stile # Stile for
> bicycles .

barrier=stile bicycle=designated ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 17.06.20 à 10:33, Guy Godfroy a écrit :
> Je ne sais pas quoi déduire ce cette conversation.

au plus on essaye de faire ultra compliqué en une fois,
au moins cela abouti.
j'ai proposé de faire la première étape "papier"
et même là il y a pas concensus puisque Donat
dit qu'un poi doit les accepter tous (ce qui implique
qu'il n'est pas nécessaire de demander la marque)
tandis que d'autre disent que ce n'est pas exact.
et pourtant ce point doit être vérifié pour pouvoir
faire une quête SC efficace et correcte à la fois.

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

Re: [OSM-talk-fr] Comment tagguer un bar à jeux ?

[Marc M.]

Bonjour,

Le 17.06.20 à 08:49, Francescu GAROBY a écrit :
> un lieu (bar/pub/...) qui propose toute une série de jeux de
> sociétés/de cartes/... à ses clients.

si cela avait été son activité principale : amenity=toy_library ?
du coup soit 2 objets amenity=bar et amenity=toy_library takeaway=no
soit un objet amenity=bar toy_library=yes
dans les 2 cas un tag description est sans doute utile.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Sortie de RTKBase V2

[Marc M.]

Bonjour,

Le 16.06.20 à 16:20, Stéphane Péneau a écrit :
>>> S'il y a des obstacles sous les 10 - 15 °, ce n'est pas grave.
>>> Au-dessus par contre c'est problématique.
>> cette exigence disqualifie les endroits auquels je pensais
> Ah dommage...

quel est l'impact d'un obstacle tel qu'un arbre ou une maison dans cet
angle ? on va perdre un sat mais faire la même qualité de fix si on
a assez de sat ? et perdre en précision si on manque de sat et si oui
est-ce que cela arrive souvent de manquer de sat ?

je crois d'ailleurs que c'est une question générale pour plusieurs
éléments technique, je me souviens de ma période CB, avec une antenne
fouet hélicoïdale pour voiture sur un plan de masse 10cmx10cm,
cela ne m'empéchait pas de discuter à courte portée sans différence
avec ceux qui avaient une antenne demi-onde sur leur toit.

Cordialement,
Marc

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

Re: [OSM-talk-be] Renderen van addr:flats

[Marc M.]

if one building have 2 entrance, it's useful to describe with entrance
need to be used to reach this flats number.
but having all flats number on the building or on one-only entrance,
is like "to reach the inside of the building, reach the building".
it's a bit like adding entrance=yes on the building to say that a
building has an entrance somewhere, you don't add any real information.

so at this place, I would not have added any addr:flats which would have
solved the problem of rendering :) I will only use it in the case of a
building with more than one entrance, and so addr:flats on the entrance
does not disturb the display of addr:housenumber for the whole building.

Le 15.06.20 à 13:55, Lionel Giard a écrit :
> The tagging is correct, it is just not supposed to be on area from the
> wiki perspective. But indeed I don't see why it is incorrect when a
> building is only containing this series of flats and only one entrance ?
> And if that's incorrect why are they rendering addr:flats on area and
> not node ?! ^^'
> 
> Le lun. 15 juin 2020 à 13:32, joost schouppe  <mailto:joost.schou...@gmail.com>> a écrit :
> 
> Most of this data comes from the GRB import, I would guess. So it
> comes from CRAB. We use the addr:flats to map the "subaddresses".
> It seems a little weird to not be able to add the subaddresses on
> the same object that has the main address.
> The CRAB import tool mentioned this as an optional tag, that is not
> so useful for OSM:
> 
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> I would concur that the quality of the data is not good enough to
> import it.
> Both examples come from endless_autumn, who did a rather
> quick-and-dirty GRB import - a lot of which was reverted.
> The GRB-import-validator Midgard made actually flags the flats tag
> as "consider removing" as well.
> That said, the wiki doesn't say much about the logic of
> "subaddresses", maybe we shouldn't use the addr:flats tag -at all-
> for subaddresses?
> 
> 
> Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere
> mailto:sander...@gmail.com>>:
> 
> Hmm,
> 
> it seems indeed that, according to the wiki, this should not be
> placed on areas.
> However, I expect that in all these cases, all flats are
> accessible behind the same door.
> So correcting the tag will have the same effect.
> 
> Op ma 15 jun. 2020 om 09:12 schreef Marc M.
> mailto:marc_marc_...@hotmail.com>>:
> 
> Hello,
> 
> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
> 
> https://www.openstreetmap.org/way/499694374
> this look like a mistake :
> wiki :  marking range of numbers of flats behind a door,
> but the object isn't a door, it's a building
> 
> maybe osm.carto should avoid to render tagging mistake and
> target
> only node and maybe only with entrance or door tag
> 
> Regards,
> Marc

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

Re: [OSM-talk-be] Renderen van addr:flats

[Marc M.]

Hello,

Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> https://www.openstreetmap.org/#map=19/50.87528/4.69102

https://www.openstreetmap.org/way/499694374
this look like a mistake :
wiki :  marking range of numbers of flats behind a door,
but the object isn't a door, it's a building

maybe osm.carto should avoid to render tagging mistake and target
only node and maybe only with entrance or door tag

Regards,
Marc

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Marc M.]

Bonjour,

Le 14.06.20 à 21:02, Arnaud Champollion a écrit :
> Je suis preneur de toutes vos expériences et conseils pour réaliser ces
> relevés sur le terrain de façon fiable et tenable dans le temps.

j'a d'abord fait comme toi : une série de photo de ce qui m’intéresse,
pensant pouvoir les assigner au retour devant un pc.
hélas, même en planifiant de faire la rue dans un ordre précis (par ex
toujours les impairs en premier), il y a toujours un cas tordu qui vient
mettre la pagaille (genre un poi au no3 dont l'entrée est après le poi
au no5). et tout s'écroule dans la série en cascade.
la précision du gps qui ne tourne pas en continue est aussi catastrophique.
du coup maintenant je fais toujours 3 photos par poi : le no, son nom
et l'horaire.
et si l'un des 3 n'est pas photographié, je fais une photo vide
pour garder la série de 3.

j'ai testé aussi l'éditeur sur le terrain, je le trouve trop chronophage
(le temps qu'on passe sur le terrain à encoder sur un clavier minuscule
n'est pas compensé par le temps gagné sur le pc, hormis pour des choses
très ponctuelle genre un no de borne incendie que j'encode tout en
continuant de marcher, idem pour des noms en zone très peu dense)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs

[Marc M.]

Le 14.06.20 à 14:36, osm.sanspourr...@spamgourmet.com a écrit :
> avec la version de Marc tu vas avoir 3 glaciers.

ben non :)
1 natural=glacier + name
1 natural=snowfield ou natural=ice_mass sans nom
1 geological=moraine et/ou natural=scree sans nom

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

Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs

[Marc M.]

Bonjour,

Le 14.06.20 à 09:28, Arnaud Champollion a écrit :
> Quand le glacier a une partie visible et une partie recouverte, on le
> coupe en deux et on ajoute surface=scree sur la partie recouverte ?

> Est-ce que les deux parties doivent alors porter le nom ?

vu qu'il n'ŷ a qu'un glacier avec ce nom,
je ne ferrais qu'un objet pour le nom (qui comprend la partie blanche
et sa moraine). puis si on veux faire plus précis, 2 autres objets
pour tager séparement les 2 parties, sans nom.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

[Marc M.]

Bonjour,

Le 13.06.20 à 20:25, Florimond Berthoux a écrit :
> abréviation de vingt-huitième

https://wiki.openstreetmap.org/wiki/FR:Names#Abr.C3.A9viation_.28.C3.A0_ne_pas_faire.29

la règle est de ne pas mettre d'abréviation dans name

> mais le terrain prime :)

ce n'est pas parce qu'une plaque de rue a une taille limitée,
que osm doit se limiter.
sinon supprimons 99% des noeuds des frontières administratives,
le terrain prime, et il n'y a rien sur le terrain ? :)

Cordialement,
Marc

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

Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

[Marc M.]

Bonjour,

Merci pour vos retours.
Voici la compilation chronologique des 8 personnes ayant répondu avec
utilisation et/ou besoin/souhait.
un doubble étonnement : le nombre limité à 8 et le peux de retour
sur les outils existant, à croire qu'on peux fermer la moitié :)

- avoir un éditeur web consensuel utilisable (le fameux id-consensuel
grâce aux patchs de fred)
- accompagner les petites structures pour un switch2osm, ce qui implique
d'avoir un doc Leaflet en français par ex
sur http://www.openstreetmap.fr/fonds-de-carte/
- soutenir les rendus existant (par ex fr) ou à grandir (cyclosm) parce
qu'une donnée qui se voit mal est une donnée un peu gâchée.
- diminuer la marche à l'entrée pour les contributeurs :
-- faciliter/accompagner lorsque quelqu'un veux faire une amélioration
sur un outil majeur, écrire p'tre une doc, identifier les problèmes.
-- avoir des serveurs de test pour cela (par exemple tester une modif de
rendu à plusieurs, ce n'est pas facile. faut installer un docker, le
rendre accessible à l'extérieur, installer le style, etc)
-- faciliter le correspondance besoin<>aidant en aidant par exemple la
communauté à bâtir une page listant les besoins, afin que ceux qui le
souhaitent puisse y piocher sans devoir "parcourir le web".
-- soutenir les communautés locales à grandir voir à se créer dans les
endroits qui en sont dépourvu.
-- aider à l'ajout d'opendata dans osm, non seulement osmose, mais aussi
en discutant d'un possible groupe de travail import/intégration ciblé
(certaines infos ont un "match"
facile entre osm-opendata qui rend inutile de demander un clic par
objet). cfr aussi le osmmybiz version opendata-fr
- un outil qui envoie un mail de présentation d'OSM dès que l'on tagge
email=moncoiff...@orange.fr. Avec un lien vers un soutien financier
- maquette de présentation/communication osm auprès des POI
- éditeur axé poi osmmybiz + horaire, un wizard/éditeur d'ajout de POI
tout public, notamment pour les commerces.
- retour du rendu BANO
- une instance française de https://nrenner.github.io/achavi/ ?
- communiquer autour de  http://geosm.openstreetmap.fr
- URL de chaque point de vente d'une enseigne
https://lists.openstreetmap.org/pipermail/talk-fr/2020-May/099075.html
- du Docker sur l'infra OSM-FR (suposé possible avec proxmox 6 à court
terme)
- du switch2osm qui parle de tuiles vecto
- une version d'Osmose dédié à l'OpenData
- un canal de discussion pour remplacer twitter "Mapillary team fr"
- pouvoir suivre des objets osm en particulier, et être alerté (mail,
flux rss, autre) en cas de modification.
- interface ‘carte cyclable’ rafraichie tous les jours, comme l’est
l’excellent cyclOSM
- completer le docker osm-carto switch2osm afin d'avoir la brique
"récupérer le style"
- CyclOSM
- BD Ortho IGN
- UMap

j'en ai fait un pad pour rajouter facilement d'étentuel avis à venir
https://annuel2.framapad.org/p/osm-retour-communaute-9h8d

Cordialement,
Marc

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

Re: [OSM-talk-fr] GPS Opens source

[Marc M.]

Le 12.06.20 à 14:42, Eric SIBERT a écrit :
> Le 2020-06-12 13:46, ades a écrit :
>> Bonjour
>> Est-ce quelqu’un a des news sur l »’avancement de la réalisation 
>> d’un gps open source ?

parles-tu du projet de Stéphane Péneau "Et si on fabriquait notre
récepteur/logger GPS ?" en mars 2018 ?
https://lists.openstreetmap.org/pipermail/talk-fr/2018-March/088111.html

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

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Marc M.]

Le 12.06.20 à 13:00, Frederik Ramm a écrit :
> desirable

imho yes, including offline editor like maps.me,
when a contributor edit one object at the airport
of departure and another at the airport of arrival,
both in the same changeset.

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Bonjour,

je pense qu'il faut revenir aux fondamentaux : SC est fait pour des
quêtes simples dont les réponses ne sont pas rébarbatives.
avec une quête avec 50 choix et un schéma fr-fr, cela ne va pas.
pourquoi pas revenir au début ?
ce poi accepte-t-il les tickets resto papier ? oui/non/limité
et reporter à + tard (et surtout au niveau mondial) une hypothétique
héritage des tags entre eux, qui changerait tout bien au dela de
la seule question d'une marque précise multi-usage.

Cordialement,
Marc

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

Re: [OSM-talk-fr] politique de la ville et umap

[Marc M.]

Le 12.06.20 à 10:05, Laurence P a écrit :
> Par contre les iframe n'ont plus l'air de fonctionner et je ne sais pas
> pourquoi :/
> 

le contenu de l'iframe est en erreur
https://storify.com/Cyrille37/cartopartie-lariche-ouest/embed?template=slideshow
https://storify.com dit qu'ils ont fermé en mai 2018

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

Re: [OSM-talk-fr] surveiller une liste d'objet (était : et si c'était Nöel ? liste de souhait et d'intérêt des outils existant)

[Marc M.]

Le 11.06.20 à 16:19, Stéphane Péneau a écrit :
> Le 11/06/2020 à 15:23, BEGUIN,Bruno a écrit :
> je n'ai pas trouvé comment surveiller un node en particulier.

j'ai surveillé un vandale multi-compte comme suit :
- récupération des diff
- grep sur chaque diff pour voir si les id s'y trouvent
- email en cas si cela se produit.

pour en faire un service un peu sympa, il faudrait
évidement au moins quelque chose pour qu'un utilisateur
soumette sa liste. et p'tre sortir un flux rss pour
éviter le volume d'email sortant si beaucoup veulent
l'utiliser

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Bonjour,

Le 09.06.20 à 20:37, Yves P. a écrit :
> Je ne sens pas intermittent=yes

je partage cet avis. un magasin fermé pendant les vacances annuelles
est-il plus ou moins intermitant qu'un projecteur de cinéma actif
à cet endroit tous les lundis ?

> opening_hours="cinéma itinérant : consultez les horaires"

c'est une tautologie :) bof. cinéma itinérant est une description
consulter les horaires ? ok la clef opening_hours donc ? qui dit
de consulter les horaires :)
opening_hours:url est plus utile. ou un début d'info.
et si on a rien sur les horaires, pas de clef opening_hours

Cordialement,
Marc

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

[OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

[Marc M.]

Bonjour,

au niveau de la liste de l'asso osm-fr, démarre une discussion
autour de "à quoi l'asso devrait affecter ses ressources humaines
et financière".
Du coup je trouve que c'est l'occasion de demander à la communauté
ce qu'elle a besoin mais qui n'existe pas, ce qui existe et qu'elle
utilise et de classer un peu tout cela en fonction de priorité (qui
sont évidement propre à chacun).
Cela pourrait éclairer l'association dans ses choix.
La liste des services fournit par l'asso est +- dispo sur
https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France#VMs

Et donc je commence par moi-même :)
- avoir un éditeur web consensuel utilisable (le fameux id-consensuel
grâce aux patchs de fred)
- accompagner les petites structures pour un switch2osm, ce
qui implique d'avoir un doc Leaflet en français par ex
sur http://www.openstreetmap.fr/fonds-de-carte/
- soutenir les rendus existant (par ex fr) ou à grandir (cyclosm)
parce qu'une donnée qui se voit mal est une donnée un peu gâchée.
- diminuer la marche à l'entrée pour les contributeurs :
-- faciliter/accompagner lorsque quelqu'un veux faire une amélioration
sur un outil majeur, écrire p'tre une doc, identifier les problèmes.
-- avoir des serveurs de test pour cela (par exemple tester une modif
de rendu à plusieurs, ce n'est pas facile. faut installer un docker,
le rendre accessible à l'extérieur, installer le style, etc)
-- faciliter le correspondance besoin<>aidant en aidant par exemple
la communauté à batir une page listant les besoins, afin que ceux
qui le souhaitent puisse y piocher sans devoir "parcourir le web".
-- soutenir les communautés locales à grandir voir à se créer
dans les endroits qui en sont dépourvu.
-- aider à l'ajout d'opendata dans osm, non seulement osmose,
mais aussi en discutant d'un possible groupe de travail
import/intégration ciblé (certaines infos ont un "match"
facile entre osm-opendata qui rend inutile de demander
un clic par objet). cfr aussi le osmmybiz version opendata-fr

Cordialement,
Marc

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

Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable

[Marc M.]

Le 09.06.20 à 14:36, Julien djakk a écrit :
> En fait, je ne pense pas faire de relations, trop casse-pied à gérer,

c'est pourtant le plus facile pour détecter que le réseau est complet.

> quand deux itinéraires vélo "secondary" se rejoignent,
> ça peut donner un itinéraire vélo "primary" etc.

j'ai en souvenir ta vision très controversé du réseau voiture.
du coup un exemple et une source utilisable pour osm sur ce point ?
ou c'est juste un feeling comme pour les voitures ?

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

Re: [OSM-talk] fake mapping

[Marc M.]

> it is useful to add something like
> note=edited based on survey

or survey:date=
in the hope than one day, editor 'll warn a mapper
if his source is older than the previous one.

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 09.06.20 à 11:53, Tyndare a écrit :
> Un resto peut

SC n'aime pas (et moi non plus) les quêtes qui en théorie ont plusieurs
réponses mais qui en pratique ont 99% de la même.
du coup les questions à se poser pour faire la quête sont :
- les cas "le midi mais pas le soir" ou inversement, sont-ils fréquent
au point de devoir l'inclure dans les réponses ou c'est purement
théorique ? perso je n'en connais pas. idem pour les cartes.
- il y a un lien ou pas entre papier et électrique méritant de demander
l'électrique qu'en cas de réponse oui au papier ou cela mérite 2 quêtes
totalement indépendante ? j'aurais tendance à croire qu'un commercant va
continuer le papier pendant une période transitoire vers l'électronique.

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

Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable

[Marc M.]

Bonjour,

Le 09.06.20 à 12:35, Julien djakk a écrit :
> Je souhaite hiérarchiser

n'est-ce pas la première lettre de network=icn/ncn/rcn/lcn ?
international <> national <> regional <> local route

le wiki renseigne aussi cycle_network=cycle_highway
qui a l'air d'être... hum.. pas très clair :)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Bonjour,


Le 09.06.20 à 09:34, Florian LAINEZ a écrit :
> Je me suis également rendu compte que dans la liste des cinémas fermés
> en 2018
> il y en a un qui a simplement changé de numéro

c'est bien là tout le soucis.
sans ref, osm aurait été juste.
l'ajout de la ref conduit à avoir une info fausse sans osm.
il faut donc que cela soie contrebalancé par une utilité.

pour Sirene, j'imagine qu'il suffit de demander à Fred
d'activer la catégorie adéquate.
J'imagine qu'une autre analyse pourrait tout aussi bien
alerter "cinéma dans osm mais fermé dans sirene"

Cordialement,
Marc

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Bonjour,

Le 09.06.20 à 10:41, Guy Godfroy a écrit :
> pour l'instant il suffit de répondre oui ou non à la question
> "Est-ce que ce restaurant accepte les titres restaurants".
> Est-ce qu'on est d'accord là dessus ?

Pour la France oui, avec le soucis papier<>électronique.
est-ce que tout ceux qui accepte l'electronique accepte
aussi obligatoirement le papier ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Bonjour,

et tu listes 2 ref ? hum

pour éviter de faire une nouvelle particularité fr-fr,
et vu qu'on a trouvé aucune utilité a dupliquer
la ref de la route sur toutes les bornes,
je suis partisant de respecter la situation actuelle
cad pour ton exemple :
highway=milestone
distance=22
operator=SANEF
ref=77PR22DC

chaque pays qui invente son propre schéma,
c'est nuisible pour osm, surtout quand
aucun argument n'est émis.

Cordialement,
Marc

Le 09.06.20 à 08:47, didier2020 a écrit :
> afin de trouver une solution sans "ref" :
> 
> proposition d'utilisation des attributs de la base rrn
> description complète :
> http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf
> 
> Pour les "nodes" highway=milestone
> attribut base rrn
>   
> valeur dans la base rrn
>   
> tag osm proposé
>   
> valeur tag osm
>   
> nota
> route
>   
> A0004
>   
> ref:FR:route
>   A0004   
> ref "A 4" est sur le way
> pr
>   
> 22
>   
> distance
>   
> 22
>   
> information visible sur le terrain
> dep
>   
> 77
>   
> concession
>   
> C
>   
>   
> concédé n'est pas synonyme de payant
> cote
>   
> D
>   
> D,G ou U
> gestionnaire
>   
> SANEF
>   
> operator
>   
> SANEF
>   
> plo
>   
> 77PR22DC
>   
> ref:FR:plo
>   77PR22DC
> avec le plo, on peut retrouver tous les autres attributs et inversement
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> et pour être cohérent, 
> pour les "way" highway=*_link ou junction=roundabout
> attribut base rrn
>   
> valeur dans la base rrn
>   
> tag osm proposé
>   
> valeur tag osm
>   
> nota
> route
>   26N953220   
> ref:FR:route
>   26N953220   
> pr
>   
> 2
>   
>   
> le pr correspond a un n° de bretelle
> dep
>   
> 77
>   
> concession
>   
> C
>   
>   
> cote
>   
> D
>   
> le coté est toujours D
> gestionnaire
>   
> DIRCE
>   
> operator
>   
> DIRCE
>   
> plo
>   
> 26N953220_2
>   
> ref:FR:plo
>   26N953220_2 
> avec le plo, on peut retrouver tous les autres attributs et inversement
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> dans le champs source:plo, l'attribution et le milésime
> 
> 
> Le lundi 08 juin 2020 à 13:26 +0200, didier2020 a écrit :
>> comme il n'y a pas de consensus sur l'utilisation des tags
>> complémentaire a higway=milestone,
>>
>> j'ai téléchargé le pbf de la france et filtrer les nodes
>> highway=milestone pour voir ce qui existe :
>>
>> sur 10935 higway=milestone, 
>> - 9057 ont un tag ref
>> - 442 ont un tag ref avec une valeur numerique
>> - distance :
>>  705 n'ont pas de valeur distance
>>  60 sont du texte/inclus un . ou +
>>  170 ont des valeurs supérieur a 1000, donc a prioris des metres plutot
>> que des kilometres
>> - 400 avec un tag ref:highway
>>
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Le 08.06.20 à 18:07, Florian LAINEZ a écrit :
> @marc M j'imagine que tu penses à ajouter le numéro de SIRET 
> comme suggéré par Christian ?

non, je pensais à l'utilisation de la base sirene pour détecter les
cinémas manquant dans osm et les cinémas fermés depuis longtemps.

> Question : d'après vous, devrait-on rajouter une valeur
> *ref:FR:CNC=null* (ou "none") pour les cinémas non-listés dans le
> fichier du CNC ? J'ai bien envie de faire ça.

Je doute comme JB de l'utilité de ce genre de ref mais si tu veux le
faire, la valeur standard =no me semble être *le* choix (comme =yes est
la valeur standard pour dire il y a en a une, à rafiner + tard)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Le 08.06.20 à 17:42, Francescu GAROBY a écrit :
> géoloc des cinémas, ça aiderait beaucoup !

sirene via osmose ?

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

ok pour le besoin de doc.

Donat vient de nous informer que c'est tout ou rien en France,
donc la marque n'est pas nécessaire voir induirait en erreur.

pour le namespace, oki lorsqu'il y a un conflit (par exemple une route
sur un point peux avoir un nom pour la route et un pour le pont,
donc logique d'avoir bridge:name)
mais pour les tickets restaurants, cela me sembble une mauvaise
idée de faire dépendre le tag en fonction de l'étendue commerciale
d'une marque genre payment:meal_voucher=Sedexo puisque mondial
et payment:meal_voucher:FR=trucmuchlocal parce que fr-fr
avoir besoin de consulter le plan d'affaire d'une entreprise
pour choisir le tag n'a pas de sens.

Le 08.06.20 à 15:01, Topographe Fou a écrit :
> Par "pas claire" j'entends que le wiki ne propose rien aujourd'hui (ni
> sur la page anglaise, ni sur la française) et que la clé n'étant utilisé
> que 212 fois dans le monde dont seulement 30 fois pour autre chose que
> yes/no (pour Sodexo en l'occurrence) c'est qu'il doit sûrement rester un
> peu de discussion à avoir (83 fois en France métropolitaine avec 82
> yes/no + 1 chèque vacances).
> 
> Par ailleurs il peut y avoir plus d'un émetteur de titre (certes la CRT
> centralise les 4 plus gros émetteurs mais il n'y a pas qu'eux). Par
> 'brand' tu veux dire une liste des titres acceptés séparés par un ; ?
> Cela peut être une option mais d'expérience cela cafouille vite et puis
> la limite du nombre de caractères jouera probablement vite les troubles
> fêtes avec l'arrivée des nouveaux acteurs. D'où ma suggestion de rester
> dans la veine des autres moyens de paiement, ce qui renforce la
> cohérence. Le 'FR:' est une touche personnelle pour éviter d'éventuels
> conflits de noms quand un émetteur est clairement franco-français (ex :
> chèque vacances).
> 
> Le lun. 8 juin 2020 à 14:42, Marc M.  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Le 08.06.20 à 13:58, Topographe Fou a écrit :
> > il faudrait déjà un schéma claire, ce qui n'est pas le cas
> aujourd'hui.
> 
> =yes/brand/no c'est pas clair ?
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> 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: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 08.06.20 à 13:58, Topographe Fou a écrit :
> il faudrait déjà un schéma claire, ce qui n'est pas le cas aujourd'hui.

=yes/brand/no c'est pas clair ?

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Le 08.06.20 à 13:26, didier2020 a écrit :
> - 9057 ont un tag ref

ce serrait sans doute utile de chercher quelques photos
de borne avec la ref visible.

>  60 sont du texte/inclus un . ou +

. est le séparateur décimal dans osm, du coup c'est numérique.
le + est + étrange.

> ref:highway
> serait une solution

à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
donc intégrons déjà toutes les bornes sans ref:highway

> "notre" besoin de référence unique

quel besoin ? si la ref dans la source n'est pas unique, elle n'est pas
unique.
prenons un exemple fictif : si la sncf décide de peindre ses places
de parking en commençant par 1 sur tous ces sites, cela ferra des ref=1
non unique dans osm.
ce n'est pas le rôle d'osm d'inventer une ref genre ref:FR:SNCF:siteA
par dogme d'unicité dans osm.
ou exemple réel : la route ref=1 n'est pas unique dans osm,
c'est la réalité, cela n'empêche pas son utilisation.

dupliquer + tard un ref:highway s'il y a un cas d'usage et un consensus,
c'est toujours possible

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

Re: [OSM-talk-fr] Osmose - proposition analyse sur public_transport=stop_position

[Marc M.]

Le 08.06.20 à 10:40, Percherie OnDaNet a écrit :
> Juste pour être certains que je ne fasse pas d'erreur : Peut-on avec 
> le schéma Public Transport V2 placer deux nœuds pour un arrêt, n°1
> l'emplacement de l'arrêt (stop_position) et n°2 l'emplacement des
> passagers (platform) ? Ou est-ce à éviter ?

c'est possible, non obligatoire et c'est la version la plus "complète"
avis perso : je commencerais par toutes les plateforme
avant d'ajouter éventuelement les stop_position.
histoire d'avoir un réseau qui a au moins une fois l'info (la
plateforme) pour tous les arrêts au lieu d'avoir un réseau
qui est super précis mais qui n'est pas complet)
mais c'est un choix qui t'appartient.

> Pour l'arrêt "Cave Coopérative", le nœud
> https://www.openstreetmap.org/node/2466864152 est bien sur le chemin et
> il à le tag "highway=bus_stop". Je m'attendais à avoir le fix-edit de
> Osmose propose le tag "public_transport=stop_position" au lieu de
> "public_transport=platform". Quelle est la réponse idéale ?

oui idéalement osmose devrait dire "cela appartient à la route,
donc fix avec stop_postion ou déconnectez de la route pour une plateforme"

> Pour l'arrêt "La Ricarde", le nœud
> https://www.openstreetmap.org/node/4498238410 est isolé mais porte des
> tag nécessitant d'être rattaché au chemin (stop_position et bus_stop).
> Je m'attendais à ce qu'Osmose demande à ce qu'il soit rattaché OU BIEN
> que les tag soient modifiés (platform) pour que cela corresponde à un
> nœud isolé. Pour l'instant Osmose ne remonte aucune erreur sur
> "public_transport=stop_position" sur des nœud isolé.

oui idéalement osmose devrait dire "rattachez le stop_position à la
route si c'est l'emplacement du véhicule ou corriger en plateform
si c'est le lieu d'attente du véhicule

Cordialement,
Marc

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

Re: [OSM-talk-fr] Osmose - proposition analyse sur public_transport=stop_position

[Marc M.]

cBonjour,

Le 08.06.20 à 09:47, Percherie OnDaNet a écrit :
> J'avais mis pas mal emplacement où s'arrête le bus comme nœud isolé
> alors qu'ils doivent être placé sur le chemin.

Je pense que tu as mal interprété l'anomalie osmose.
il y a 2 façons, selon les régions du monde de maper un arrêt de bus :
- soit un objet décrivant où attendent les passagers
- soit un objet décrivant où s'arrête le véhicule.
historiquement les 2 se tag avec highway=bus_stop

pour harmoniser et lever l'ambiguïté, la PTv2 propose
d'ajouter la fonction public_transport=plateform au premier
et public_transport=stop_position au 2ieme.

>   * Remonte dans Osmose : https://www.openstreetmap.org/node/2466864152

texte osmose : Préciser s’il s’agit d’une station (“platform”)
ou d’un emplacement sur la route (“stop_position”)
fait partie de la route -> stop_position
avec la plateforme https://www.openstreetmap.org/node/7589051409
PS: il ne faut pas 2 bus_stop par arrêt. sauf si on représente
2 arrêts de part et d'autre de la rue

> Pas d'erreur dans Osmose : https://www.openstreetmap.org/node/4498238410

mais cela ne semble pas être le lieu oü s'arrête le véhicule.
cela devrait donc être public_transport=plateform

Cordialement,
Marc

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Bonjour,

Le 08.06.20 à 08:55, Guy Godfroy a écrit :
> Donc quelle est votre opinion là dessus ?

Pour.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Aide sur une requête OverPass

[Marc M.]

Bonjour,

Le 07.06.20 à 20:13, Gad.Jo a écrit :
> Ce qui me pose problème est la fusion des deux requêtes

ta première est déjà en elle même une fusion de plusieurs requêtes
la syntaxe est :
(
première;
deuxième;
...;
);
la () servant à grouper le tout.

En suivant cette logique, j'ai réécrit la proposition en une fusion
j'ai aussi simplifié node+way en nwr (rien n'interdit d'avoir une
relation pour ces tags, mais c'est surtout plus lisible)
j'ai aussi évité d'avoir plusieurs fois le filtre bbox
j'ai transformé l'expression régulière !~.* en négation
j'ai rajouté la 3ieme partie qui avait disparu

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

Cordialement,
Marc

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

Re: [OSM-talk] VANDALISM !

[Marc M.]

Hello,

Le 07.06.20 à 15:07, 80hnhtv4agou--- via talk a écrit :
> how do you put it all back ?

giving a link to get a neutral opinion is often a good idea :)
the first time, just put a public message on the changeset.
there is the revert plugin in josm to cancel all the changes.
if it happens again, contact the DWG mentioning the changeset
with the comment.

Regards,
Marc

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

Re: [OSM-talk-fr] Etang sur arroux

[Marc M.]

Bonjour,

Le 07.06.20 à 11:55, Gaël Simon a écrit :
> une entité du nom de « Etang sur arroux » (sans majuscule à arroux) apparaît 
> sur le rendu osm standard 

hormis la déchetterie, il n'y a rien dans cette zone avec arroux
https://overpass-turbo.eu/s/UO6
vu que le rendu des premiers niveaux ne se fait qu'une fois
par semaine, je conseille d'attendre une semaine au cas oü
quelqu'un a entre temps corrigé le problème.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Le 04.06.20 à 17:02, didier2020 a écrit :
> dans le référentiel, la bretelle est définie par 2 plo, non visible
> sur le terrain
> - la référence métier est sur un way

séparer l'intégration en 2 :
- les bornes réelles d'un côté
- les ref de route non indiquée sur le terrain...
sans doute qlq chose pour unsigned_ref.
très pratique pour éviter qu'un guidage te propose
de suivre une ref que tu ne vois pas.

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Bonjour,

mon avis:
- la ref de la voie n'est pas la ref de la borne
- la distance c'est distance= :)
- donc la réf de la borne, puisqu'elle est parfois visible
sur le terrain, c'est tout simplement ref comme dans les autres pays :)

je n'ai pas compris le point B des bornes de bretelles,
en quoi c'est différent pour osm d'une autre ?

Cordialement,
Marc

Le 04.06.20 à 16:37, Frédéric Rodrigo a écrit :
> Je résume.
> La question porte sur l'usage du tag ref pour un highway=milestone.
> Certains utilisent la ref de voie (A 63), d'autres la distance. Il y a
> en plus une référence "métier" non inscrite sur les bornes.
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone
> 
> Mon avis perso. La ref de la voie ne peut pas être la ref de la borne
> car ça ne rend pas cette référencée unique dans son contexte
> d'utilisation, c'est à dire la voie.
> 
> 
> Le 04/06/2020 à 16:04, didier a écrit :
>> Bonjour,
>>
>> Afin qu'osmose puis permettre d'intégrer des données du réseau routier
>> national,
>> F.Rodrigo m'a demandé de voir l'utilisation des tags pour
>> highway=milestone
>>
>> Préambule :
>> Le céréma gère le référentiel du réseau routier national (RRN), qui est
>> a l'origine une base de donnée patrimoniale :
>>   - Une route et sa représentation géométrique (Polyline) : A0001, N0001
>> etc...
>>   - Une route pour les bretelles d'entrée, sortie, échange ou giratoire
>> : 60A900130DC, 78A901310 etc...
>>   - Des "points localisants" (plo) qui sont associés a une route
>>    + chaque plo a une distance cumulée par rapport au début de la route
>> (l'ecart entre deux plo est appelé inter-pr)
>>   les 2 types de localisants qui sont "interressant" sont
>>    + SC pour section courante (plo 93PR1D pr 1, 60PR30GC pr 30)
>>    + DB pour début bretelle (plo DB1 pr 1, plo DB2 pr 2)
>>    + FB pour fin bretelle (plo FB1 pr 1, plo FB2 pr 2)
>>
>> ces 2 tables sont le référentiel rrn et sont suffisantes pour décrire
>> le réseau routier et ses différentes caractéristiques et ceci sans
>> coordonnées.
>> exemple: sur la route A0001, 100 metres après le plo 93PR1D et jusqu'a
>> 10 metres après le plo 93PR2D, le nombre de voie est de 5, la vitesse
>> de 90 km/h
>>
>> Différents export de cette base sont disponible sur data.gouv.fr mis a
>> disposition par le Ministère de la Transition écologique et solidaire
>> entre autre :
>> https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national/
>> https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/
>>
>>
>> La question pour l'intégration dans Openstreetmap est sur l'utilisation
>> des tags, lesquels utiliser ?:
>> A) Pour les routes, il n'y a pas de données précise mis a disposition
>> sur data.gouv.fr.
>>   ref est utilisé sur les way et dans les relations routes mais avec un
>> espace entre la lettre et les chiffres
>> Il n'y a pas de donnée a intégrer
>>
>> B) Pas retenu pour une intégration avec osmose :
>>   Pour les plo de type DB ou FB, cela correspont a des entrées, sorties,
>> giratoires ou bretelles d'interconnexion => type:way et
>> highway=motorway_link, trunk_link, primary_link...
>>   cela correspond :
>> https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/
>>
>> (les données de bretelle et de bornage sont mélangées)
>>   la référence ne sera pratiquement jamais visible sur le terrain.
>>   je propose
>>   nat_ref = 60A900130DC_1
>>   car cela correspond a ce qu'utilise bison-futé pour la géolocalisation
>> de ses données événementielles
>>
>> C) Pour les plo de type SC, cela correspont au bornage routier =>
>> type:node et highway=milestone
>> les données sont disponibles :
>> https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national
>> (les données de bretelle et de bornage sont mélangées)
>> (pour info, les données intégrables commencent après la ligne 13454)
>>
>> dans le wiki, les tags highway=milestone sont distance et ref
>>
>> je propose cette correspondance pour des attributs du csv
>> - x coordonnées lon epsg:2154
>> - y coordonnées lat epsg:2154
>> - z toujours a 0, a ignorer
>>
>> - abs : toujours a 0,
>> => a ignorer
>> - cumul : distance cumulée depuis le début de la route
>> => a ignorer ou inventer
>>
>> - route: A0004 (a modifier pour faire correspondre a A 4)
>> => ref
>> - pr : 1 pour une meme route, il peut y avoir le meme pr dans chaque
>> département
>> => distance
>>
>> - pour ces 3 données
>>   + depPr : le département gestionnaire (pas le département ou se situe
>> le plo)
>>   + concessionPr : C pour concédé a un concessionnaire, N pour non
>> concédé
>>   + cote : D, G, I. Dans la base du Céréma c'est D pour coté droit (sens
>> des pr croissant), G pour coté gauche (sens des pr décroissant), U pour
>> unique (un seul localisant pour les 2 sens de circulation)
>>   utilisation de la description plo qui correspond a : plo = deptPr +
>> 'PR' + pr + cote
>> en sachant que route + plo est un identifiant unique
>>
>> C'était un peu long comme description 

Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

[Marc M.]

modifs appliquées histoire qu'on puisse voir l'effet.

si tu veux traduire en français ce qui ne l'est pas,
c'est le bienvenu :)

pour le drapeau, l'actuel est fournit par le projet principal
https://github.com/taginfo/taginfo/blob/master/web/public/img/logo/fr.png
si tu le souhaites, soumet un fr-metropolitaine.png dans
https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo/files qui
se configurera dans
https://github.com/osm-fr/ansible-scripts/blob/master/roles/taginfo/files/taginfo-config.json#L13
il faudra aussi rajouter du code inspiré de
https://github.com/osm-fr/ansible-scripts/blob/master/roles/taginfo/tasks/main.yml#L88
si tu n'arrives pas ou ne souhaites pas tout faire, le mieux c'est de
soumettre le ticket dans ansible, c'est là que se ferra la modif.

pour france métro sous europe, cela provient du fait que l'un est
une partie de l'autre (chaque niveau est extrait du précédent)
du coup idéalement cela devrait se nomner france métropolitaine
avec sans doute un lien de l'un vers l'autre pour longtemps afin
de ne pas casser ceux qui utilise les pbf et diff en automatique.
osm-fr a le même soucis
https://download.openstreetmap.fr/extracts/europe/ (qui mériterait aussi
d'être corrigée)
je veux pas parler pour geofabrik, mais pour osm-fr,
ce serrait incohérent d'avoir une sous-région d'europe
avec des objets hors europe et casse pied à faire (ajout d'exeption
dans le script qui dit que quand on découpe europe pour la france,
faut fusionner alors qu'on a d'abord besoin de france métropolitaine
pour fusionner avec les dom)

pour l'étendue qui inclu Guernsey, on effet leur polygone mériterait
d'être affiné avec quelques points.
pour le taginfo osm-fr, j'avais basculé sur la frontière exacte
tout en gardant entièrement les objets à cheval sur celle-ci.

Le 04.06.20 à 15:39, Topographe Fou a écrit :
> Note :
> http://taginfo.geofabrik.de/europe/france/tags/maxspeed=35%20mph#map me
> sors des objets à Guernsey, et en effet en regardant de plus prêt le
> périmètre de l'export sur
> https://download.geofabrik.de/europe/france.html c'est inclut dedans.
> Vais leur demander de retirer Jersey et Guernsey de leur export France.
> 
> Le jeu. 4 juin 2020 à 14:58, Topographe Fou  <mailto:letopographe...@gmail.com>> a écrit :
> 
> J'ai fait une pull-request changeant uniquement le nom de l'instance
> taginfo. J'ai tout laissé en anglais mais me suis demandé pourquoi
> ce n'est pas en français. Ce qui sauterait au yeux serait de mettre
> une précision près du drapeau mais en effet je ne le trouve pas non
> plus. Le meilleur Github pour ouvrir un ticket concernant le drapeau
> est-il celui infrastructure ou ansible-scripts ?
> 
> Concernant geofabrik cela se complique : sur
> https://download.geofabrik.de/europe/france.html la zone
> géographique de l'export n'englobe que la métropole mais dans la
> liste des 'Sub regions' on retrouve les DOM. Peut-être est-ce lié au
> fait que France soit sous Europe dans leur arborescence (Europe
> géographique vs Europe politique). Du coup soit je leur demande si
> ils peuvent renommer "France" en "France métropolitaine" (et dans ce
> cas les DOM n'auraient pas leur place en Sub-regions... arg la
> cohérence) soit je leur demande si ils peuvent inclure les DOM dans
> l'export France (et dans ce cas on est tout bon ! et notre taginfo
> sera bien sur la France) soit si ils peuvent rajouter un niveau
> (donc avoir un export France complet + un export France
> métropolitaine + Un export par région/DOM). Je penche pour la 2 ou
> la 3. Avis ?
> 
> Je ne suis pas spécialement demandeur d'une instance taginfo France
> incluant les DOM, j'aime simplement quand les choses sont cohérentes
> et sans ambiguïté :) .
> 
> Le jeu. 4 juin 2020 à 13:20, Marc M.  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> oui pour le moment taginfo .fr n'a pas les données domtom.
> Mais les données ne sont pas un soucis, elles sont dispo sur
> l'infra.
> 
> avec plaisir pour le ticket osm-fr ajout de l'info
> "métropolitaine" :)
> et au moins des liens dans about vers les instances domtom
> https://github.com/osm-fr/infrastructure
> si tu es motivé, la configuration est là
> https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo
> la partie France saute aux yeux :)
> mais le drapeau ne semble pas là oü il devrait l'être.
> n'hésites pas à en soumettre un si tu le souhaites.
> 
> pour le ticket geofabrik, je peux pas garantir qu'ils le traiteront
> mais cela me semble toujours une bonne idée de signaler une erreur.
> 
> à toi de me dire si cela corr

Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

[Marc M.]

oui pour le moment taginfo .fr n'a pas les données domtom.
Mais les données ne sont pas un soucis, elles sont dispo sur l'infra.

avec plaisir pour le ticket osm-fr ajout de l'info "métropolitaine" :)
et au moins des liens dans about vers les instances domtom
https://github.com/osm-fr/infrastructure
si tu es motivé, la configuration est là
https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo
la partie France saute aux yeux :)
mais le drapeau ne semble pas là oü il devrait l'être.
n'hésites pas à en soumettre un si tu le souhaites.

pour le ticket geofabrik, je peux pas garantir qu'ils le traiteront
mais cela me semble toujours une bonne idée de signaler une erreur.

à toi de me dire si cela correspond à ton besoin ou si une instance
france complète serrait aussi utile.

Le 04.06.20 à 12:43, Topographe Fou a écrit :
> Ahhh !!! En fait le taginfo France est un taginfo France
> _métropolitaine_. Donc à supposer que l'on puisse mettre plusieurs
> cartes côte à côte il n'y aurait probablement pas les données pour les
> remplir... Donc ma question tombe à l'eau.
> 
> Un peu trompeur ce drapeau français et ce .fr. Ne peut-on pas rajouter
> un petit "METROPOLE" sous le drapeau de
> https://taginfo.openstreetmap.fr/ ou rajouter dans le titre ? De même
> sur geofabrik remplacer "Database: France" par "Database: France
> métropolitaine" serait adéquat. Je peux créer des tickets si retours
> positifs.
> 
> Le jeu. 4 juin 2020 à 12:29, Marc M.  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> la liste https://rlin.eu/osm/geofabrik/?id=france
> mais il n'y a pas d'instance France.
> ce que osm-fr et geofabrik nome France est la France métropolitaine
> https://taginfo.geofabrik.de/europe/france/keys/building#map
> Si cela répond à un besoin, cela peux s'envisager.
> Mais p'tre que les taginfo sub-nationaux suffisent ?
> 
> Le 04.06.20 à 12:10, PanierAvide a écrit :
> > Effectivement dans cet esprit Geofabrik met à disposition des
> instances
> > de Taginfo sur la base des exports qu'ils proposent sur leur site
> > https://download.geofabrik.de/europe/france.html
> >
> > Il suffit de changer dans l'URL le nom du fichier concerné, exemple :
> >
> > http://taginfo.geofabrik.de/europe/france/reunion/keys/building#map
> > http://taginfo.geofabrik.de/europe/france/guyane/keys/building#map
> >
> > Cordialement,
> >
> > Adrien P.
> >
> > Le 04/06/2020 à 11:57, Philippe Verdy a écrit :
> >> Là tu parles de l'instance d'OSM France. On peut noter que cette
> >> instance continent un sélecteur de langue mais cela ne change pas les
> >> résultats.
> >> Pour voir les cartes des autres pays il faut trouver les autres
> >> instances de TagInfo (autres sites), et elles ne sont pas liées entre
> >> elles.
> >> Il y a sinon la carte mondiale sur l'instance OSM.org:
> >>
> >> https://taginfo.openstreetmap.org/keys/drinking_water#map  
> >>
> >>
> >>
> >> Le jeu. 4 juin 2020 à 11:41, Topographe Fou
> mailto:letopographe...@gmail.com>
> >> <mailto:letopographe...@gmail.com
> <mailto:letopographe...@gmail.com>>> a écrit :
> >>
> >>     Bonjour à tous,
> >>
> >>     Aux administrateurs du taginfo français : est-ce possible
> >>     d'ajouter une carte par DOM en plus de celle de la métropole dans
> >>     l'onglet "Carte" ? Example :
> >>     https://taginfo.openstreetmap.fr/keys/drinking_water#map
> >>
> >>     Si ce n'est pas possible techniquement (ce que je soupçonne) je
> >>     peux ouvrir un ticket sur
> >>     https://github.com/taginfo/taginfo/issues car c'est dommage de
> >>     limiter la France à sa métropole et il doit probablement exister
> >>     d'autres cas où plus d'une zone géographique seraient les
> bienvenues.
> >>
> >>     Par avance merci.
> >>
> >>     LeTopographeFou

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

Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

[Marc M.]

la liste https://rlin.eu/osm/geofabrik/?id=france
mais il n'y a pas d'instance France.
ce que osm-fr et geofabrik nome France est la France métropolitaine
https://taginfo.geofabrik.de/europe/france/keys/building#map
Si cela répond à un besoin, cela peux s'envisager.
Mais p'tre que les taginfo sub-nationaux suffisent ?

Le 04.06.20 à 12:10, PanierAvide a écrit :
> Effectivement dans cet esprit Geofabrik met à disposition des instances
> de Taginfo sur la base des exports qu'ils proposent sur leur site
> https://download.geofabrik.de/europe/france.html
> 
> Il suffit de changer dans l'URL le nom du fichier concerné, exemple :
> 
> http://taginfo.geofabrik.de/europe/france/reunion/keys/building#map
> http://taginfo.geofabrik.de/europe/france/guyane/keys/building#map
> 
> Cordialement,
> 
> Adrien P.
> 
> Le 04/06/2020 à 11:57, Philippe Verdy a écrit :
>> Là tu parles de l'instance d'OSM France. On peut noter que cette
>> instance continent un sélecteur de langue mais cela ne change pas les
>> résultats.
>> Pour voir les cartes des autres pays il faut trouver les autres
>> instances de TagInfo (autres sites), et elles ne sont pas liées entre
>> elles.
>> Il y a sinon la carte mondiale sur l'instance OSM.org:
>>
>> https://taginfo.openstreetmap.org/keys/drinking_water#map  
>>
>>
>>
>> Le jeu. 4 juin 2020 à 11:41, Topographe Fou > > a écrit :
>>
>> Bonjour à tous,
>>
>> Aux administrateurs du taginfo français : est-ce possible
>> d'ajouter une carte par DOM en plus de celle de la métropole dans
>> l'onglet "Carte" ? Example :
>> https://taginfo.openstreetmap.fr/keys/drinking_water#map
>>
>> Si ce n'est pas possible techniquement (ce que je soupçonne) je
>> peux ouvrir un ticket sur
>> https://github.com/taginfo/taginfo/issues car c'est dommage de
>> limiter la France à sa métropole et il doit probablement exister
>> d'autres cas où plus d'une zone géographique seraient les bienvenues.
>>
>> Par avance merci.
>>
>> 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
> 
> ___
> 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] Ajout cartes des DOM sur Taginfo FR

[Marc M.]

Bonjour,

Le 04.06.20 à 11:40, Topographe Fou a écrit :
> Aux administrateurs du taginfo français : est-ce possible d'ajouter une
> carte par DOM en plus de celle de la métropole dans l'onglet "Carte" ?
> Example : https://taginfo.openstreetmap.fr/keys/drinking_water#map

j'ai l'impression qu'il n'est possible d'avoir qu'une carte par
instance, et si c'est possible, j'ignore comment :)

du coup soit on met une carte France "intégrale" mais elle deviendra
moins utile vu son étendue.
soit on met une instance métropolitaine + une/des instances dom/tom
un peu comme le fait géofabrik soit faut poser la question au mainteneur :)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Quelle est la solution la plus simple de remplacer une carte Google avec des POI.

[Marc M.]

Bonjour,

Le 04.06.20 à 08:47, Jean-Christophe Becquet a écrit :
> Je pense qu'on peut faire ça assez facilement avec uMap

avec l'avantage qu'une fois fait, cela tourne sans maintenance pour eux.
umap a aussi un cache overpass qui diminue l'impact en perfomance
que l'utilisation overpass constitue.

Cordialement,
Marc

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

[Marc M.]

osmose monte en effet une base osm en local pour ses analyses.
vu que l'étape 1 n'est à faire qu'une fois, une requête overpass
sur l'étendue du jeux de donnée opendata est aussi possible.

Le 02.06.20 à 09:57, Nicolas Bétheuil a écrit :
> Bonjour,
> 
> Effectivement on a pas la même définition de petit : je ne vois pas
> comment faire la 1ère étape sans monter une base OSM (ou ses données et
> comparer point par point). Conflation dans josm ? Analyse osmose, qui va
> devoir monter une base OSM ? Une telle analyse sur un département c'est
> en minutes voir dizaines de minutes sur mon poste (pour voir si ça
> tourne) du coup je trouve ça gros.
> Quand je parlais de petit c'était des changeset fait par un humain, du
> coup moins d'une dizaine de point par changeset au fur à mesure.
> 
> Salutations
> Nicolas
> 
> Le mar. 2 juin 2020 à 06:53, Marc M.  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Bonjour,
> 
> Le 31.05.20 à 15:27, Nicolas Bétheuil a écrit :
> > Diviser le travail en plus petit morceaux pour pouvoir avancer.
> 
> c'est justement ce que je proposais et qui apparemment est mal compris
> 1) intégrer tous points dont la position est connue dans osm
> pour rajouter les infos opendata (import à discuter)
> 2a) utiliser une image "rue" pour ajouter les points inexistant
> dans osm mais dont une photo permet de le voir (contribution classique)
> 2b) utiliser un éditeur sur le terrain pour ajouter les points
> inexistants dans osm dont on n'a pas de photo (contribution classique)
> 
> mais proposer une image sat parce que la localisation
> n'est pas bonne, c'est comme un tournevis pour un clou :
> si on ne voit pas la borne, on ne sait pas corriger la localisation,
> correction estimé nécessaire pour justifier la revue humaine.
> 
> Cordialement,
> Marc
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto: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