Re: [talk-au] foot/bicycle = yes/designated (was Re: TfNSW Cycleways use in OSM)

2020-02-17 Thread Andrew Harvey
On Tue, 18 Feb 2020 at 17:38, Andrew Davidson  wrote:

> On 18/02/2020 5:11 pm, Andrew Harvey wrote:
> > I hold the view that access=yes just means either physical or legal
> > access is allowed (or at least not forbidden), whereas access=designated
> > implies that it's signposted or otherwise explicitly designed/used
> > for/by that mode.
>
> I'm good with the concept of a sign (or a painted outline of a squashed
> cyclist).
>
> I am now curious about what you've described as "otherwise explicitly
> designed/used for/by that mode". What do you mean by explicitly
> designed? Do you mean I need to go and find the original plans and see
> if they state that the path is for use by pedestrians? Explicitly used?
> So if I clearly see a cyclist using it it's designated?
>

You're right that most of the time, designated will be marked or
signposted, but if there is a compelling case I'm open to that.

For example a disabled toilet, it'll have more space, railings next to the
toilet etc. usually it'll have a sign, but if the signage is missing, it's
still wheelchair=designated in my view.

For cycle paths, it'll probably be either green paint (if that's common for
the region), bicycle logo painted on the ground, or a sign with a bicycle.


> > This view is backed up by what
> > https://wiki.openstreetmap.org/wiki/Key:access says about designated
>
> which is then immediately contradicted by:
>
> https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated
>
> which says it's based on what the law says (which is then contradicted
> itself by the value description template to the right that says marked
> for a particular use.)
>

It says "Typically it is used on ways legally dedicated...", typically, not
always. An official sign is enough in my opinion to indicate legally
dedicated.


> > So in ACT the footpath would be bicycle=yes since bicycles are allowed
> > on the footpath, but it's not a designated path for bicycles.
>
> Yes and no. Under the it's the sign rule then yes, under the designated
> by law rule then designated.
>
> This is why I asked what the Australian use was. I want to know if we're
> comfortable with the sign post rule or not.
>

What do you think makes most sense on an ACT footpath that's just a stock
standard footpath with no bicycle markings or specific design for bicycles,
bicycle=yes or bicycle=designated?

I'm still open to hear out other view points, but so far the way I've been
mapping is bicycle=yes indicates legal/physical access and
bicycle=designated indicated signposted for bicycle use.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [Talk-de] foot=yes on highway=primary / StreetComplete

2020-02-17 Thread Ferdinand
Dieser Tag sollte eigentlich nur von street complete hinzugefügt werden
wenn es keinen Sidewalk giebt.

Florian Lohoff  schrieb am Mo., 17. Feb. 2020, 16:57:

>
> Hi,
>
> Ich bin gerade über einige Changeset gestolpert in denen StreetComplete
> foot=yes auf primarys gepackt hat.
>
> Mich wundert das so ein bisschen weil grundsätzlich war ich davon
> ausgegangen das alles ausser motorway als default foot=yes hat.
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [talk-au] foot/bicycle = yes/designated (was Re: TfNSW Cycleways use in OSM)

2020-02-17 Thread Andrew Davidson

On 18/02/2020 5:11 pm, Andrew Harvey wrote:
I hold the view that access=yes just means either physical or legal 
access is allowed (or at least not forbidden), whereas access=designated 
implies that it's signposted or otherwise explicitly designed/used 
for/by that mode.


I'm good with the concept of a sign (or a painted outline of a squashed 
cyclist).


I am now curious about what you've described as "otherwise explicitly 
designed/used for/by that mode". What do you mean by explicitly 
designed? Do you mean I need to go and find the original plans and see 
if they state that the path is for use by pedestrians? Explicitly used? 
So if I clearly see a cyclist using it it's designated?


This view is backed up by what 
https://wiki.openstreetmap.org/wiki/Key:access says about designated


which is then immediately contradicted by:

https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated

which says it's based on what the law says (which is then contradicted 
itself by the value description template to the right that says marked 
for a particular use.)


So in ACT the footpath would be bicycle=yes since bicycles are allowed 
on the footpath, but it's not a designated path for bicycles. 


Yes and no. Under the it's the sign rule then yes, under the designated 
by law rule then designated.


This is why I asked what the Australian use was. I want to know if we're 
comfortable with the sign post rule or not.


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


Re: [talk-au] foot/bicycle = yes/designated (was Re: TfNSW Cycleways use in OSM)

2020-02-17 Thread Luke Stewart
My understanding is as follows:

yes means that there is the legal right to use something e.g. you have the
right to walk by foot on a sidewalk.

designated means that there is a legal instrument (generally signage and/or
possibly road marking depending on your state) that *specifically* gives
you permission to use a given feature. For instance, a shared path is one
which bicycles and pedestrians can legally use together, and this is
designated by a shared path sign (AU:R8-2
https://en.m.wikipedia.org/wiki/File%3AAustralia_R8-2.svg?wprov=sfla1). In
this case it would be appropriate for a shared pathway to have both foot
and bicycle be set to designated in my opinion.

Theoretically you could add foot=yes to every sidewalk and/or footway
however my understanding is this key is implied, and will also throw and
error in osmose.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [talk-au] foot/bicycle = yes/designated (was Re: TfNSW Cycleways use in OSM)

2020-02-17 Thread Andrew Harvey
On Tue, 18 Feb 2020 at 15:59, Andrew Davidson  wrote:

> On 18/02/2020 3:44 pm, Ash Logan wrote:
> > In line with this, I've drafted an osmosis TagTransform file that can
> > turn the raw TfNSW dataset (after being run through JOSM's OpenData
> > plugin, for example) and turn it into the usual OSM tagging schema.
> > Check it out:
>
> Question: do we have a community view on what exactly the difference is
> between access yes and access designated?
>

I hold the view that access=yes just means either physical or legal access
is allowed (or at least not forbidden), whereas access=designated implies
that it's signposted or otherwise explicitly designed/used for/by that mode.

This view is backed up by what
https://wiki.openstreetmap.org/wiki/Key:access says about designated

So in ACT the footpath would be bicycle=yes since bicycles are allowed on
the footpath, but it's not a designated path for bicycles. A cyclepath
would be bicycle=designated since it's signposted/designed for that mode of
transport.

Same goes for wheelchair=yes/designated (okay for wheelchairs vs.
signposted for wheelchairs), or lanes:bus=yes/designated, one says the bus
can use the lane, the other says it's an explicit/signposted bus lane.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-17 Thread Joseph Eisenberg
> - for continents, oceans, poles, and seas bordering any state, I will
completely remove this marker.

I'm almost certain that this translation is wrong. It doesn't make sense.

Could you check the correct translation of "por kontinentoj, oceanoj,
polusoj kaj maroj kiuj apudas al neniu lando, tute forigi tiun ĉi
etikedon."

Does this mean "... NOT bordering any country"? That's what Google
translate suggests: " for continents, oceans, poles and seas that are
next to none country, completely remove this tag."

(Still wrong but at least I can understand it... That's the problem
with relying on automated translation software... it doesn't work
well.)

- Joseph Eisenberg

On 2/18/20, Joseph Eisenberg  wrote:
> Since this issue is somewhat controversial, it would be best to create
> a proposal page to suggest the proper way to tag continents, oceans
> and seas - these tags were never formally discussed, and have some
> problems.
>
> Also, the correct way to propose automatically changing a large number
> of features is to follow the "Automated Edits code of conduct":
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> This includes "systematic edits to the database by other means without
> consideration of each change. This policy also applies to substantial
> changes made using 'find and replace' or similar functions within
> standard editors such as JOSM" - so I believe this would be the case
> for editing all the seas and oceans.
>
> "You should normally document your proposed edit at an
> English-language wiki page named "Automated edits/username" (where
> username is the OSM user name of the account that you will be using to
> perform the edits - think about this now so that you don't have to
> rename the page later), and add it to Category:Automated edits log.
>
> Your documentation should state:
>
> Who is making the change (preferably your real name and how to contact
> you, ideally e-mail address)
> Your motivation for making the change and why it is important
> A detailed description of the algorithm you will use to decide which
> objects are changed how
> Information about any consultation that you have conducted, with links
> to mailing list/forum posts or Wiki discussion pages
> When the change was made, or how frequently it is going to be repeated
> Information on how to "opt out"
>
> Please read the rest of the information at
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> prior to proceeding.
>
> (FYI, I am personally in favor of removing the English name=* tags for
> continents and oceans, and perhaps for many of the seas, but it's
> important to get consensus about a major edit like this)
>
> - Joseph Eisenberg
>
> On 2/18/20, Tomek  wrote:
>> W dniu 20-02-15 o 19:17, Steve Doerr pisze:
>>> On 15/02/2020 17:35, Tomek wrote:
 - for continents, oceans, poles, and seas bordering any state, I will
 completely remove this marker.
>>>
>>> Don't do that. The golden rule should be: never remove another
>>> mapper's contribution unless it's incontrovertibly wrong.
>>>
>>> Steve
>>>
>> EO
>> Mi provas provi ke la etikedo “name” por tiuj objektoj estas erara.
>>
>> Objekto 1:
>> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
>> Benko kun neniu skribaĵo, mapigita en OSM kiel:
>> amenity=bench
>> name=Bench
>> Ĉu estas ĝuste forigi la etikedon “name” laŭ la regulo mi “mi mapigas
>> tion, kion estas sur la tero”?
>>
>> Objekto 2:
>> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
>> Akvo, certege neniu skribaĵo indikanta ĝian nomon.
>> Loka nomo: neniu, ĉar neniu loĝas tie.
>> Mapigita en OSM kiel:
>> place=ocean
>> name=Pacific Ocean
>> Sed poloj nomas ĝin “Ocean Spokojny”, franclingvanoj “Océan Pacifique”,
>> do estus ĝuste aldoni la etikedojn name:pl, name:fr, ktp.
>> Ĉu estas ĝuste forigi la etikedon “name” laŭ la sama regulo?
>>
>>
>> EN (machine translation)
>> I'm trying to prove that the tag "name" for those objects is wrong.
>>
>> Object 1:
>> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
>> Bench with no writing, mapped to OSM as:
>> amenity = bench
>> name = Bench
>> Is it right to remove the label "name" according to the "I'm mapping
>> what's on the ground" rule?
>>
>> Object 2:
>> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
>> Water, certainly no writing indicating its name.
>> Local name: nobody, because nobody lives there.
>> Mapped in OSM as:
>> place = ocean
>> name = Pacific Ocean
>> But Poles call it "Ocean Spokojny", French-speaking "Océan Pacifique",
>> so it would be fair to add the tags name:pl, name:fr, etc.
>> Is it OK to remove the "name" tag according to the same rule?
>>
>>
>>
>> W dniu 20-02-16 o 12:44, Florimond Berthoux pisze:
>>>
>>> - for continents, oceans, poles, and seas bordering any state, I
>>> will
>>> completely remove this marker.
>>>
>>>
>>> Warning, without giving my 

Re: [talk-au] LPI imagery date?

2020-02-17 Thread Andrew Davidson

On 18/02/2020 4:20 pm, Graeme Fitzpatrick wrote:
Still mapping away for bushfire areas, this time in Blue Mountains, & 
just wondering how up-to-date the LPI Imagery is? Could it be post-fires?


There is a overlay available in iD (and JOSM) that shows the LPI imagery 
dates. For your area it says 29 March 2009.


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


[talk-au] LPI imagery date?

2020-02-17 Thread Graeme Fitzpatrick
Still mapping away for bushfire areas, this time in Blue Mountains, & just
wondering how up-to-date the LPI Imagery is? Could it be post-fires?

Please have a look at

Re: [talk-au] Gravel pits?

2020-02-17 Thread Benjamin Ceravolo
would the same be used for a mulch dump/pile?

On Tue, 18 Feb 2020 at 09:09, Warin <61sundow...@gmail.com> wrote:

> On 18/2/20 5:42 am, Mateusz Konieczny via Talk-au wrote:
>
> I used landuse=industrial industrial=warehouse for something similar.
>
> Though I admit that I am now not sure whatever "warehouse" fits well for
> pile of coal,
> even one that has specialized equipment supporting it.
>
>
> Warehouse implies a building, these have no building. Not a good fit.
>
>
>
> I see also material= product = warehouse= tags used to tag what is stored
> there
> ( http://overpass-turbo.eu/s/QMP )
>
>
>
>
> Feb 17, 2020, 10:49 by j...@jonorossi.com:
>
> Do we have tags for big stockpiles of iron ore, coal, etc at mines or
> ports? These tend to be pretty permanent and with heaps of loading
> equipment around them.
>
> On Mon, Feb 17, 2020 at 7:30 PM Andrew Davidson 
> wrote:
>
> On 17/2/20 7:13 pm, Jonathon Rossi wrote:
> > What about a stockpile? And material=gravel/dirt/sand/...?
> >
>
> landuse=stockpile
> resource=aggregate ?
>
>
> I like landuse=stockpile. Says what it is.
>
>
> material: Describes the main material of a physical feature.
>
> product: The output or product that a feature produces.
>
> resource: Indicates the resource or mineral commodity related to a
> feature.
>
>
> The resource key is the match.
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


[talk-au] foot/bicycle = yes/designated (was Re: TfNSW Cycleways use in OSM)

2020-02-17 Thread Andrew Davidson

On 18/02/2020 3:44 pm, Ash Logan wrote:
In line with this, I've drafted an osmosis TagTransform file that can 
turn the raw TfNSW dataset (after being run through JOSM's OpenData 
plugin, for example) and turn it into the usual OSM tagging schema.

Check it out:


Question: do we have a community view on what exactly the difference is 
between access yes and access designated?



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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-17 Thread Joseph Eisenberg
Since this issue is somewhat controversial, it would be best to create
a proposal page to suggest the proper way to tag continents, oceans
and seas - these tags were never formally discussed, and have some
problems.

Also, the correct way to propose automatically changing a large number
of features is to follow the "Automated Edits code of conduct":
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

This includes "systematic edits to the database by other means without
consideration of each change. This policy also applies to substantial
changes made using 'find and replace' or similar functions within
standard editors such as JOSM" - so I believe this would be the case
for editing all the seas and oceans.

"You should normally document your proposed edit at an
English-language wiki page named "Automated edits/username" (where
username is the OSM user name of the account that you will be using to
perform the edits - think about this now so that you don't have to
rename the page later), and add it to Category:Automated edits log.

Your documentation should state:

Who is making the change (preferably your real name and how to contact
you, ideally e-mail address)
Your motivation for making the change and why it is important
A detailed description of the algorithm you will use to decide which
objects are changed how
Information about any consultation that you have conducted, with links
to mailing list/forum posts or Wiki discussion pages
When the change was made, or how frequently it is going to be repeated
Information on how to "opt out"

Please read the rest of the information at
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
prior to proceeding.

(FYI, I am personally in favor of removing the English name=* tags for
continents and oceans, and perhaps for many of the seas, but it's
important to get consensus about a major edit like this)

- Joseph Eisenberg

On 2/18/20, Tomek  wrote:
> W dniu 20-02-15 o 19:17, Steve Doerr pisze:
>> On 15/02/2020 17:35, Tomek wrote:
>>> - for continents, oceans, poles, and seas bordering any state, I will
>>> completely remove this marker.
>>
>> Don't do that. The golden rule should be: never remove another
>> mapper's contribution unless it's incontrovertibly wrong.
>>
>> Steve
>>
> EO
> Mi provas provi ke la etikedo “name” por tiuj objektoj estas erara.
>
> Objekto 1:
> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
> Benko kun neniu skribaĵo, mapigita en OSM kiel:
> amenity=bench
> name=Bench
> Ĉu estas ĝuste forigi la etikedon “name” laŭ la regulo mi “mi mapigas
> tion, kion estas sur la tero”?
>
> Objekto 2:
> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
> Akvo, certege neniu skribaĵo indikanta ĝian nomon.
> Loka nomo: neniu, ĉar neniu loĝas tie.
> Mapigita en OSM kiel:
> place=ocean
> name=Pacific Ocean
> Sed poloj nomas ĝin “Ocean Spokojny”, franclingvanoj “Océan Pacifique”,
> do estus ĝuste aldoni la etikedojn name:pl, name:fr, ktp.
> Ĉu estas ĝuste forigi la etikedon “name” laŭ la sama regulo?
>
>
> EN (machine translation)
> I'm trying to prove that the tag "name" for those objects is wrong.
>
> Object 1:
> https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
> Bench with no writing, mapped to OSM as:
> amenity = bench
> name = Bench
> Is it right to remove the label "name" according to the "I'm mapping
> what's on the ground" rule?
>
> Object 2:
> https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
> Water, certainly no writing indicating its name.
> Local name: nobody, because nobody lives there.
> Mapped in OSM as:
> place = ocean
> name = Pacific Ocean
> But Poles call it "Ocean Spokojny", French-speaking "Océan Pacifique",
> so it would be fair to add the tags name:pl, name:fr, etc.
> Is it OK to remove the "name" tag according to the same rule?
>
>
>
> W dniu 20-02-16 o 12:44, Florimond Berthoux pisze:
>>
>> - for continents, oceans, poles, and seas bordering any state, I will
>> completely remove this marker.
>>
>>
>> Warning, without giving my opinion, I don't know all involvements.
>> Data should not be lost!
> EO
> Neniuj datumoj perdiĝos, la angla nomo estos en la etikedo “name:en”!
> EN
> No data will be lost, the English name will be labeled "name:en"!
> FR
> Aucune donnée ne sera perdue, le nom anglais sera étiqueté "name:en"!
>

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


[talk-au] TfNSW Cycleways use in OSM

2020-02-17 Thread Ash Logan

Hey all!
TfNSW's recent waiver-signing gave us access to their Cycleways dataset 
( https://opendata.transport.nsw.gov.au/dataset/cycleway-data ) which 
includes shapefiles and information about cycle paths, shared paths, 
cycle lanes, and shared lanes. The data is quite detailed ( see 
https://opendata.transport.nsw.gov.au/system/files/resources/NSW%20Cycle%20Data%20Guide.pdf 
) covering everything from lit= to operator=.
There's been discussions about this dataset and its place in OSM on the 
OSM World Discord server ( https://discord.gg/q6HnfNZ #asia-pacific ) 
and we think we should present to you lot for discussion. Here's a 
summary of the consensus so far:


- The metadata about the ways is useful in OSM, but the shapefiles 
aren't accurate enough for an import. The data is also too old to be 
considered for a direct import (some ways date to 2009!)
- The metadata, however, is extremely useful to apply to existing ways. 
An editor could load up a separate layer, manually review the tags 
before selectively copying them over, or compare the data with OSM to 
highlight potentially unmapped ways.


In line with this, I've drafted an osmosis TagTransform file that can 
turn the raw TfNSW dataset (after being run through JOSM's OpenData 
plugin, for example) and turn it into the usual OSM tagging schema.

Check it out:
https://gist.github.com/QuarkTheAwesome/bcaddee7a5d0dae5191a2124960e24ea
There's some notes at the top of the file, please read them! After 
discussion on Discord, it's been changed to not output name, alt_name, 
or cycleway:difficulty:tfnsw (a new tag to describe TfNSW's low, medium, 
high ratings). ref:tfnsw - which is the OBJECTID inside the dataset - is 
also being considered for removal.


This is also being written up in a wiki page:
https://wiki.openstreetmap.org/wiki/TfNSW_Cycleways_Data
That page has the procedures we've been using to generate an .osm file 
to muck around with in JOSM.


Big thanks to aharvey and ortho_is_hot for helping out with this!
--
https://heyquark.com

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


[Talk-us] Tagging "Junior College" or "Community College"?

2020-02-17 Thread Joseph Eisenberg
How are people tagging places known as "junior colleges" or "community
colleges?" Usually these offer 1 or 2 year associates degrees and
diplomas in specific trades or work fields, or general higher
education courses which make it possible to transfer to a 4-year
University.

Is it proper to use amenity=college? That tag was originally developed
for insitutes of "Further Education" in the UK, which are a bit
different than North American junior/community colleges. Is anyone
using amenity=university instead?

- Joseph Eisenberg

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


Re: [Talk-de] foot=yes on highway=primary / StreetComplete

2020-02-17 Thread Simon Poole
und boat = no und motor_boat = no und und und und und und

Am 17.02.2020 um 23:11 schrieb Bernhard Weiskopf via Talk-de:
> Die Defaults betrachte ich als Vermutung, nicht als gesichert. (default
> = in Ermangelung von ...)
>
> Aus meiner Sicht ist eine nicht angegebene Eigenschaft unbekannt.
>
> Sicherlich ist es sinnvoll, dass Router Fußgänger auf primary highways
> routen, auch wenn "foot = yes" nicht angeben ist, weil diese Eigenschaft
> meistens zutrifft.
>
> Wenn jemand die Erlaubnis für Fußgänger vor Ort geprüft hat, halte ich
> es durchaus für sinnvoll, "foot = yes" bzw. "foot = no" zu ergänzen.
>
> Bernhard
>
>
> Am 2020-02-17 um 16:56 schrieb Florian Lohoff:
>> Hi,
>>
>> Ich bin gerade über einige Changeset gestolpert in denen StreetComplete
>> foot=yes auf primarys gepackt hat.
>>
>> Mich wundert das so ein bisschen weil grundsätzlich war ich davon
>> ausgegangen das alles ausser motorway als default foot=yes hat.
>>
>> Flo
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>
> -- 
> Bernhard Weiskopf
> Erfurter Weg 36a
> 68309 Mannheim
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Simon Poole

Am 17.02.2020 um 23:42 schrieb Yves:
> ..
> ... or worse, not using the brand at all on their maps for the same goal! 
> Yves 
>  

Actually no, and I'm fairly sure that is the "BIG MISUNDERSTANDING".

If somebody doesn't provide sufficient attribution that doesn't run
away, and we can, for all practical purposes be arbitrary in how and
when we enforce our licence. Very different with our marks and other IP.

For example it is -very- costly to impossible to stop somebody using a
domain name that is a play on OpenStreetMap once they have registered
the domain or acquired it from a former community project. Standard
example openweathermap, but there are numerous other well known examples.

Simon




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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Yves


Le 17 février 2020 23:10:55 GMT+01:00, Simon Poole  a écrit 
>misusing the OpenStreetMap brand and marks by so
>many other organisations with the goal of  profiting from OSMs
>popularity.

... or worse, not using the brand at all on their maps for the same goal! 
Yves 
 

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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Simon Poole
In no particular role, specifically no official OSMF one:

Can't we resolve this by moving the logo and potentially other ones to
an explicit category:

"Fun, parody and other, not totally serious, remixes of the OSM logo,
not endorsed by anybody"

With a different hat on: it would be really nice if the community was
equally upset about misusing the OpenStreetMap brand and marks by so
many other organisations with the goal of  profiting from OSMs popularity.

Simon

Am 17.02.2020 um 14:25 schrieb Rory McCann:
> In order to keep the peace, I'll voluntarily delete that image from
> the OSM Wiki (as best I can). But the file is out there in the wild,
> you can't stop the internet.
>
> I am only a random person at a keyboard, I'm too much of a wuss to
> throw stones at cops, I'm not a black block antifa protester! But
> (IMO) there is a problem today with the rise of xenophobia, of
> queerphobia, etc. I made this logo partially for fun, but also one way
> to oppose that hate. To me, it's more than just "for the lulz".
> Perhaps, in my original reply, I appeared too flippant. I make use of
> emoijis to convey tone, which is often lost in text.  means I want
> to be friendly.
>
> To me, it's obvious that an OSM based logo doesn't mean OSM is 100%
> the same as that thing. If I make an OSM mash up, I can still see you
> as a fellow OSMer even if you don't agree with what that logo
> represents. The existence of an OSM cycling logo doesn't mean all
> OSMers have to be cycling activists! But perhaps that was not
> communicated well. I hope the community can figure out how to make
> that clear.
>
> “Keep politics out of OSM” sounds nice, but I question what “politics”
> means here. It's often used only for feminism/pro-LGBTQ/anti-racism
> (and rarely mentioned when a copyright law changes). I think
> “politics” is too ambiguous to be useful when we talk to each other.
>
> For those who see this logo as an OSM/OSMF endorsement, I'd like to
> see an OSM logo remix which, to them, doesn't imply endorsement, so I
> (and others) can design future logo remixes without implying
> endorsement. I never intended, or what to, imply OSMF endorsement, and
> I would like to know how to avoid that.
>
>
> Let's get back to mapping the world.
>
>
> Rory
>
> On 13/02/2020 23:01, Rory McCann wrote:
>>
>> Hello fellow OSMers! 
>>
>> So this is from me. Last year I made some mashups of the OSM logo. There
>> is often a lot of big business presence at tech/FLOSS conferences now,
>> so I thought “What would be the opposite of that?” I am pretty lefty,
>> and I do like OSM's anarchistic/do-ocracy/flat/non-hierarchical
>> tradition anyway. So I ordered these stickers for a laugh, and they (&
>> the LGBTQ designs) were quite popular.
>>
>> I don't believe it breeches the OSMF Trademark policy. §3.5 allows
>> remixed logos for user group logos. §3.2 & §3.4 allow the use of
>> stickers. (There is plenty of other examples of OSM trademark use BTW
>> ) I thought it was clear that it didn't reflect OSMF policy, but I'm
>> sure I can communicate that better, to avoid all doubt. Mea Culpa. §2.2
>> of the Trademark policy does require a more explicit notice, which I've
>> now added to the wiki page. §2.3 says I shouldn't suggest OSMF
>> endorsement, and I don't want to suggest, or imply, OSMF affiliation or
>> endorsement!  I've added a message the wiki page for that image. Do
>> you think that suffices?
>>
>> Yes, by definition all democratic societies are "anti-fascist", but even
>> I know the logo is more than just "anti-fascist", and...
>> controversial. 
>>
>> _However_ I need to think on this. We have a lot of work to do. We have
>> a whole world to map. I don't want everyone to fight, or external people
>> to get mistaken ideas about OSM.  Someone might have a false idea of
>> one thing, and (falsely) think all of OSM is like that.
>>
>> That can go both ways: Right wing, bigoted, politicians sometimes claim
>> "antifa are violent terrorists" (cf. Trump after the Charlottesville
>> rally). “OSM doesn't have a Code of Conduct, and they just banned the
>> antifa logo saying it's a horrible violent organization!” could make
>> some marginalized groups (falsely) think OSM is full of a certain type
>> of hostile person!
>>
>> As well as OSM being inherently political, "No politics" can (in
>> practice) translate to "Don't act gay, and people are allowed be
>> homophobic to you and you can't complain" (etc). If you think it's OK
>> for people to act gay/etc in an OSM event, then a "no politics" rule
>> communicates quite the opposite (alas). IMO you should rephrase.
>>
>> Yes, the OSM community/OSMF should think about what kinds of (political)
>> issues we should (& shouldn't) get involved with, and what should be in
>> our spaces. (hey... maybe there should be some sort of code of how you
>> can conduct yourself in OSM spaces 樂)
>>
>> So I need to think. My email inbox is open if anyone wants to give
>> suggestions/(confidential?) 

Re: [Talk-de] foot=yes on highway=primary / StreetComplete

2020-02-17 Thread Bernhard Weiskopf via Talk-de

Die Defaults betrachte ich als Vermutung, nicht als gesichert. (default
= in Ermangelung von ...)

Aus meiner Sicht ist eine nicht angegebene Eigenschaft unbekannt.

Sicherlich ist es sinnvoll, dass Router Fußgänger auf primary highways
routen, auch wenn "foot = yes" nicht angeben ist, weil diese Eigenschaft
meistens zutrifft.

Wenn jemand die Erlaubnis für Fußgänger vor Ort geprüft hat, halte ich
es durchaus für sinnvoll, "foot = yes" bzw. "foot = no" zu ergänzen.

Bernhard


Am 2020-02-17 um 16:56 schrieb Florian Lohoff:

Hi,

Ich bin gerade über einige Changeset gestolpert in denen StreetComplete
foot=yes auf primarys gepackt hat.

Mich wundert das so ein bisschen weil grundsätzlich war ich davon
ausgegangen das alles ausser motorway als default foot=yes hat.

Flo

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


--
Bernhard Weiskopf
Erfurter Weg 36a
68309 Mannheim

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


Re: [talk-au] Gravel pits?

2020-02-17 Thread Warin

On 18/2/20 5:42 am, Mateusz Konieczny via Talk-au wrote:

I used landuse=industrial industrial=warehouse for something similar.

Though I admit that I am now not sure whatever "warehouse" fits well 
for pile of coal,

even one that has specialized equipment supporting it.



Warehouse implies a building, these have no building. Not a good fit.




I see also material= product = warehouse= tags used to tag what is 
stored there

( http://overpass-turbo.eu/s/QMP )






Feb 17, 2020, 10:49 by j...@jonorossi.com:

Do we have tags for big stockpiles of iron ore, coal, etc at mines
or ports? These tend to be pretty permanent and with heaps of
loading equipment around them.

On Mon, Feb 17, 2020 at 7:30 PM Andrew Davidson
mailto:thesw...@gmail.com>> wrote:

On 17/2/20 7:13 pm, Jonathon Rossi wrote:
> What about a stockpile? And material=gravel/dirt/sand/...?
>

landuse=stockpile
resource=aggregate ?



I like landuse=stockpile. Says what it is.


material: Describes the main material of a physical feature.

product: The output or product that a feature produces.

resource: Indicates the resource or mineral commodity related to a feature.


The resource key is the match.


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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread Arnaud Champollion

Le 17/02/2020 à 19:19, osm.sanspourr...@spamgourmet.com a écrit :


shelter_type=borie (voir la valeur plus standard un point-virgule et 
le nom). Pas fana non plus borie c'est du français, pas de l'anglais.




On a bien amenity=lavoir

Sinon je serais tenté quand même de mettre description=borie.


shelter_type=basic_hut
material=dry_stone

suffit pour décrire une cabane en pierre sèche.



Je résume donc où j'en suis :

amenity=shelter
material=dry_stone
shelter_type=basic_hut
description=borie

Ce fut un abri et c'en est toujours un, même si l'usage a changé (de 
cabane de berger, il reste plutôt la possibilité de s'y abriter en rando 
quand la voûte est intacte).
Je laisse tomber historic=shelter puisque c'est toujours un abri, même 
si sa fonction actuelle est aussi patrimoniale (sans être archéologique).



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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread dcapillae
Hi, Christoph.

There's some confusion here:


Christoph Hormann-2 wrote
> If you want the OSMF members to start an initiative to change the OSMF 
> trademark policy to forbid certain uses you should try to convince them 
> to do that, not Rory.

I do not wish to initiate anything or convice anyone. I have only commented
on where you can find information on how to delete a wiki page and I have
suggested an alternative to deletion. That's all.

Regards,
Daniel



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

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


Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

2020-02-17 Thread osm . sanspourriel

Le 17/02/2020 à 17:32, Christian Quest - cqu...@openstreetmap.fr a écrit :



Le 17/02/2020 à 11:55, osm.sanspourr...@spamgourmet.com a écrit :

Le 17/02/2020 à 09:37, Christian Quest - cqu...@openstreetmap.fr a
écrit :

Dans l'exemple donné, on a un lotissement qui pourrait très bien se
satisfaire d'un landuse=residential nommé.


Le problème c'est la juxtaposition et/ou l'empilement de landuse de même
type.

De plus tu vas avoir inévitablement des duplications de noms
landuse/place.

Non seulement on n'a pas d'information relative à l'importance (sauf la
surface), mais en plus il y a des scories d'affichage.



La surface est justement utilisée pour l'ordre de rendu.

On peut aussi mettre le lotissement en inner du residential plus
général qui est autour.


Dans les deux cas tu as des scories d'affichage : les landuse ont, outre
une couleur de fond, un bord.

Du coup ton landuse est coupé visuellement comme s'il y avait des
clôtures entre.


Le 17/02/2020 à 09:37, Christian Quest - cqu...@openstreetmap.fr a
écrit :

Dans le cas présent d'un quartier/lotissement définit en surfacique,
je ne vois pas ce qu'apporte le ponctuel arbitraire.


L'affichage puisque le place= n'est rendu que sur le ponctuel. Sauf à le
modéliser en landuse qui ne me semble pas correct.

Un quartier n'est par exemple pas nécessairement constitué que d'une
zone résidentielle, il peut y avoir de la zone commerciale, de
l'industrie...


N. B. : le rôle label n'est pas indispensable il permet de faire le lien
entre les deux.

Si les rendus utilisaient les place= surfaciques, on pourrait supprimer
les place= ponctuels redondants.


Sur le polygone je mettrais:
landuse=residential
place=neighborhood
name=Lotissement Machinchose


C'est bien ça que j'ai supprimé car ni le rendu ni la modélisation ne me
semblaient bonnes.

Exemple : il y a avait un landuse  (déjà le nom pose problème,
ça duplique le nom et la commune n'est pas la zone agglomérée centrale)
et des landuse Lotissement Machinchose.

Ça découpait visuellement le bourg alors que les lotissements/résidences
sont intégrés au bourg.

Jean-Yvon



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


Re: [OSM-talk] talk Digest, Vol 186, Issue 37

2020-02-17 Thread marc marc
Le 17.02.20 à 21:44, talk-requ...@openstreetmap.org a écrit :
> Is it OK to remove the "name" tag according to the same rule?

why are you asking if you only allow your own view as the reply ?
name:xx is an additional name in this xx language.
so yes name=bench is not a name, but it's true to every translated
name:xx with the same word. so ALL name and name:xx should be deleted.
But if an object have a a valid name:xx it have a name (in the osm
meaning of this tag).
maybe you should make a rendering that hides all the names if
name=name:en but removing all name=name:en is wrong.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-17 Thread Marc Mongenet
Bonsoir,

Je cartographie depuis une bonne dizaine d'années le Grand Genève, et pour
les chemins agricoles et forestiers j'utilise toujours:
* track grade1 lorsque la chaussée est revêtue, ce qui donne généralement
des bords de chaussée distincts en photo aérienne;
* track grade2 lorsque toute la chaussée est en terre ou gravier, mais sans
herbe;
* track grade3 lorsque le centre de la chaussée est en herbe mais pas les
traces de pneus;
* track grade4 lorsque les traces de passage sont discernables mais
discontinues
* track grade5 lorsque la piste est indiscernable ou à peine (de l'herbe
partout)
En bref, je me fonde sur les photos du wiki, qui n'ont pas varié depuis
bien longtemps (toujours?)
Je passe parfois des chaussées au revêtement particulièrement dégradé, ou
recouvert de terre, en grade2.
Bien sûr ces critères dépendent du climat local.

Pour moi,
https://www.mapillary.com/app/?focus=photo=IKTSczR_C0BrDrSTYcyDPg=42.72720613999894=2.712138949997893=17
est
sans hésitation du track grade2.

Parmi les erreurs que je rencontre souvent, il y a:
highway=service au lieu de track grade1, probablement pour mapper en
fonction du joli rendu de highway=service.
highway=path au lieu de track grade3 à grade5, probablement par erreur ou
manque d'information (mapping de traces GPS prises à pied/vélo).

Marc Mongenet


Le lun. 17 févr. 2020 à 07:34, rainerU  a écrit :

> Bonjour,
>
> Dans les départements 11 et 66, un utilisateur a récemment ajouté ou
> modifié un
> grand nombre de pistes de montagne. Les valeurs qu'il utilise pour
> tracktype
> sont généralement un ou deux niveaux supérieurs à celles que
> j'utiliserais,
> c'est à dire, là ou je mets grade3 ou grade2 il met grade1. J'ai laissé un
> commentaire sur un de ses changeset avec des liens vers des images
> Mapillary :
>
> https://www.openstreetmap.org/changeset/79978741
>
> J'ai déjà eu le même genre de discussion avec lui en 2013. En gros, sa
> règle est
> : ce qui est goudronné est unclassifed, lest track c'est tout ce qui n'est
> pas
> goudronné, donc le grade1 est pour les "chemins empierrées larges,
> roulables en
> voiture standard". Moi, je me tiens à la définition du wiki de grade1 :
> "revêtement dur de type asphalte ou composée de matériaux très compactés".
>
> Comme je ne suis pas entièrement sur d'avoir la bonne vision des règles
> d'utilisation de tracktype et avant d'entamer une guèrre d'édition, je
> vous
> demande votre avis sur ces modifications.
>
> Rainer
>
>
> ___
> 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] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread dcapillae
Hi, Mario.

Yes, something like that.

I think it is appropriate to keep the discussion in terms of
legitimate/abusive, authorized/unauthorized, etc., and to avoid talking
about offenses or feelings. (That's another evil path that I've also had the
misfortune to suffer)

If the OSMF considers it legitimate and authorizes the use of its trademarks
to create logos along with emblems of certain organizations or political
movements, there is nothing more to say. Being their brands, they decide.

Transferring the decision to the members of the Foundation avoids us having
to keep ideological discussions about political or social movements that, in
principle, are not directly related to what we do here.


Greetings from Spain.

Regards,
Daniel

P.S.: If anyone is looking for very controversial discussions related to
what we do here, please visit the Tagging list :D



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

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


Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-02-17 Thread Tomek
W dniu 20-02-15 o 19:17, Steve Doerr pisze:
> On 15/02/2020 17:35, Tomek wrote:
>> - for continents, oceans, poles, and seas bordering any state, I will
>> completely remove this marker.
>
> Don't do that. The golden rule should be: never remove another
> mapper's contribution unless it's incontrovertibly wrong.
>
> Steve
>
EO
Mi provas provi ke la etikedo “name” por tiuj objektoj estas erara.

Objekto 1:
https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
Benko kun neniu skribaĵo, mapigita en OSM kiel:
amenity=bench
name=Bench
Ĉu estas ĝuste forigi la etikedon “name” laŭ la regulo mi “mi mapigas
tion, kion estas sur la tero”?

Objekto 2:
https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
Akvo, certege neniu skribaĵo indikanta ĝian nomon.
Loka nomo: neniu, ĉar neniu loĝas tie.
Mapigita en OSM kiel:
place=ocean
name=Pacific Ocean
Sed poloj nomas ĝin “Ocean Spokojny”, franclingvanoj “Océan Pacifique”,
do estus ĝuste aldoni la etikedojn name:pl, name:fr, ktp.
Ĉu estas ĝuste forigi la etikedon “name” laŭ la sama regulo?


EN (machine translation)
I'm trying to prove that the tag "name" for those objects is wrong.

Object 1:
https://commons.wikimedia.org/wiki/File:Jardin_El_Capricho_Bench_at_Plaza_de_los_Emperadores.jpg
Bench with no writing, mapped to OSM as:
amenity = bench
name = Bench
Is it right to remove the label "name" according to the "I'm mapping
what's on the ground" rule?

Object 2:
https://commons.wikimedia.org/wiki/File:Turquoise_Water.jpg
Water, certainly no writing indicating its name.
Local name: nobody, because nobody lives there.
Mapped in OSM as:
place = ocean
name = Pacific Ocean
But Poles call it "Ocean Spokojny", French-speaking "Océan Pacifique",
so it would be fair to add the tags name:pl, name:fr, etc.
Is it OK to remove the "name" tag according to the same rule?



W dniu 20-02-16 o 12:44, Florimond Berthoux pisze:
>
> - for continents, oceans, poles, and seas bordering any state, I will
> completely remove this marker.
>
>  
> Warning, without giving my opinion, I don't know all involvements.
> Data should not be lost!
EO
Neniuj datumoj perdiĝos, la angla nomo estos en la etikedo “name:en”!
EN
No data will be lost, the English name will be labeled "name:en"!
FR
Aucune donnée ne sera perdue, le nom anglais sera étiqueté "name:en"!
<>

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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Christoph Hormann
On Monday 17 February 2020, dcapillae wrote:
>
> The logo will continue on the wiki until the page is deleted. The
> procedure for deleting wiki pages is describe on the wiki. [1]
>
> You don't have to accept the deletion if you don't agree. As I said
> in my first message, the rights holder is the OSM Foundation, and
> only they decide. It has been suggested that you consult with OSMF
> members. [2] It could be a good way to resolve the controversy.

If you want the OSMF members to start an initiative to change the OSMF 
trademark policy to forbid certain uses you should try to convince them 
to do that, not Rory.  Why should Rory - who does not share that 
sentiment and who has unselfishly offered to remove the logo to avoid 
people possibly feeling offended none the less - do that?

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

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


Re: [OSM-talk-fr] Vandalisme utilisateur "PARIS SUD", le retour

2020-02-17 Thread osm . sanspourriel

En MP, Noémie et moi parlions de revitaliser le MapRoulette consacré à
RB94 :

https://maproulette.org/challenge/3443/task/7996740

Comme ça on se partage le boulot sans devoir se coordonner expressément.

Effectivement si quelqu'un est déjà intervenu entre temps, je ne sais si
la requête de Noémie le verra ou passera à travers.

Marc : tiens j'en ai pris un au hasard :

https://www.openstreetmap.org/node/5894483018/history

Et hop un que j'avais corrigé avec un commentaire qui était assez
clair... Ça donne plus envie de faire un revert sur les changesets en
question !

Jean-Yvon

Le 17/02/2020 à 21:26, marc marc - marc_marc_...@hotmail.com a écrit :

Bonsoir,

il est de retour, rebanni car revandalisé plein de noms
et autres erreurs comme les fois précédentes.
il serrait utile que chacun prenne un objet dans
http://osmose.openstreetmap.fr/fr/byuser/PARIS%20SUD?level=1
et analyse tout le changeset qui a créé l'anomalie,
en y laissant un mot pour que le contributeur suivant sache que ce
changeset a été traité

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



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


[OSM-talk-fr] Vandalisme utilisateur "PARIS SUD", le retour

2020-02-17 Thread marc marc
Bonsoir,

il est de retour, rebanni car revandalisé plein de noms
et autres erreurs comme les fois précédentes.
il serrait utile que chacun prenne un objet dans
http://osmose.openstreetmap.fr/fr/byuser/PARIS%20SUD?level=1
et analyse tout le changeset qui a créé l'anomalie,
en y laissant un mot pour que le contributeur suivant sache que ce
changeset a été traité

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


Re: [talk-au] Gravel pits?

2020-02-17 Thread Andrew Davidson

On 18/2/20 5:44 am, Mateusz Konieczny via Talk-au wrote:


I would use landuse=industrial industrial=* as it is in form easier to 
actually use


I can see the attraction of using a tag that will be rendered, however I 
don't think you can call a pile of rocks "industrial". Nothing happens 
to the rocks while they are stored there.



industrial=warehouse?


There's no warehouse.






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


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Mario Frasca

Hi Rory and Daniel,

I don't understand… someone (A) made something (B) that others (GGG) 
think it's inappropriate, and the authority involved is the OSMF, right?


now why do G, G, and G need to convince A that B was wrong after all, 
and that A needs to remove B?


wasn't it the OSMF, the authority involved and potentially offended?

I'm not offended at all, and I hope this mashup stays where it is.  but 
then again, let the board decide, and to be sure, I already saved it 
somewhere in my laptop.


(and about the point, I don't find it back, that developing countries 
may be scared of the association OSM-anti_fascist, I'm not able to take 
this seriously.  in my opinion and experience, developing countries are 
managed by people who are money driven, so you don't offer money, you're 
not interesting, and let's see how I can justify that.  it's a nice 
association, according to me.)


ciao,

Mario

On 17/02/2020 13:49, dcapillae wrote:

Hi, Rory.

The logo will continue on the wiki until the page is deleted. The procedure
for deleting wiki pages is describe on the wiki. [1]

You don't have to accept the deletion if you don't agree. As I said in my
first message, the rights holder is the OSM Foundation, and only they
decide. It has been suggested that you consult with OSMF members. [2] It
could be a good way to resolve the controversy.

Greetings from Spain.

Happy mapping.

Regards,
Daniel

[1] https://wiki.openstreetmap.org/wiki/Delete
[2]
https://wiki.openstreetmap.org/wiki/File_talk:2019_OSM_Anarchist_Antifa_logo.svg



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

___
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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread Stéphane Péneau

Le 17/02/2020 à 20:02, severin.menard via Talk-fr a écrit :


Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte 
ublock F9, que faut-il prévoir en plus côté accessoires ?





Un gros trépied ?


Oui


De quoi l'alimenter ?


Batterie fournie


Un boîtier étanche pour les intempéries ?


Le mieux est peut-être de leur demander



Et côté softs ?

Tu peux presque tout faire avec RTKLib qui est FOSS. Ce fork est 
recommandé : https://github.com/rtklibexplorer/RTKLIB



Si j’ai bien compris, l’idée n’est pas de créer une base GNSS comme le 
montrait Stéphane dans sa présentation, mais d’avoir deux récepteurs 
qui enregistrent leur position de manière Indépendante et du 
post-traitements une fois le terrain fini ?


L'idée c'est d'utiliser un récepteur en tant que base qui pourra être 
déplacée de temps en temps. Mais pour que les coordonnées de cette base 
soit correctes, il faudra tout de même la laisser assez longtemps 
(plusieurs heures) sur un endroit fixe.


Quelle surface tu souhaites couvrir ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un 
atelier pratique lors du SotM de Nantes sur toute la chaîne des deux 
approches Ublock en PPP et deux ublocs + ? Je pourrais amener un ou 
deux Drotek.



Pourquoi pas.

Stf


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


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread osm . sanspourriel

Dans tes choix, vérifie que le signal Galileo est capté car là tu as "en
brut" de la précision métrique.

Ce n'est pas ce que tu cherches, mais c'est déjà sans doute suffisant :

En général en France on utilise le cadastre et BDOrtho qui utilisent un
repère propre, tectoniquement stable et non le WGS84. Il y a
actuellement 80 cm de différence (de mémoire).

Jean-Yvon

Le 17/02/2020 à 20:02, severin.menard via Talk-fr -
talk-fr@openstreetmap.org a écrit :


Bonjour à tou-te-s,

Merci pour les nombreuses réponses et conseils sur ce fil !

Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte
ublock F9, que faut-il prévoir en plus côté accessoires ? Un gros
trépied ? De quoi l'alimenter ? Un boîtier étanche pour les
intempéries ? Et côté softs ? Je vais devoir faire établir un devis et
ne voudrais rien oublier.

Le seul intérêt du matériel que j’avais trouvé sur le net est qu’il
soit apparemment capable de recevoir les infos différentielles
Omnistar, le seul service (payant sous abonnement) qui semble couvrir
l’Afrique subsaharienne. Comme c’est malheureusement un machin
propriétaire qui exige que le récepteur soit compatible
(https://en.wikipedia.org/wiki/OmniSTAR), je pense que le Drotek ne
doit pas pouvoir l’utiliser. Mais pour éviter de rester des jours sur
un même point en mode PPP, il y a donc la méthode intéressante
proposée par Éric d’avoir un récepteur fixe et un autre mobile, ce qui
rend l’organisation du terrain plus facile. Si j’ai bien compris,
l’idée n’est pas de créer une base GNSS comme le montrait Stéphane
dans sa présentation, mais d’avoir deux récepteurs qui enregistrent
leur position de manière Indépendante et du post-traitements une fois
le terrain fini ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un
atelier pratique lors du SotM de Nantes sur toute la chaîne des deux
approches Ublock en PPP et deux ublocs + ? Je pourrais amener un ou
deux Drotek.


Séverin






___
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] Bon usage de tracktype

2020-02-17 Thread Sébastien Dinot
Bonjour,

rainerU a écrit :
> J'ai déjà eu le même genre de discussion avec lui en 2013. En gros, sa
> règle est : ce qui est goudronné est unclassifed, lest track c'est
> tout ce qui n'est pas goudronné, donc le grade1 est pour les "chemins
> empierrées larges, roulables en voiture standard".

Je fais de même. J'ai pris cette habitude en cartographiant une région
d'Italie (les Marches) dans laquelle je me rends souvent et qui compte
de nombreuses pistes non goudronnées, mais recouvertes d'un gravier
compact blanc (enfin, plutôt beige écru). Pour moi, sur une route
goudronnée, que je déclare « unclassified », il est possible de rouler
à bonne allure car le revêtement procure une bonne adhérence et on peut
avoir une relative confiance sur la continuité du revêtement. Pas de
doute, c'est une « route ». Sur une voie en gravier, non seulement
l'adhérence est faible, mais il arrive que le ravinement fasse de gros
dégâts. Il est hors de question de rouler à 50 km/h sur une telle voie
ou même de la privilégier à une route goudronnée à peine plus longue.
J'indique donc que cette voie non goudronnée est une « piste » et si sa
surface est plane et homogène, j'indique que son « tracktype » est
« grade1 ».

Il me semble notamment important de distinguer les deux pour le
routage : il faut privilégier les axes goudronnés. Je me souviens d'une
fois où mon GPS m'a fait prendre une route de 8 km pour accéder à un
plateau en montagne. La « route » s'est révélée être une piste couverte
de ce gravier écru et était très défoncée. J'ai du faire une bonne
partie du trajet au pas. Arrivé au sommet de la montagne, j'ai eu la
surprise de me retrouver face à une belle route, large, goudronnée et
lisse. Je me suis demandé pourquoi mon GPS m'avait fait prendre la piste
déglinguée. J'ai constaté que les deux voies étaient considérées comme
équivalentes dans la base de mon GPS, mais que la route goudronnée
faisait 9 km (soit 1 km de plus que la piste). Mon GPS m'a donc fait
prendre le chemin le plus court. De retour à la maison, j'ai constaté le
même problème dans OSM et je me suis empressé de rectifier le tir.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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


[OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread severin.menard via Talk-fr
Bonjour à tou-te-s,

Merci pour les nombreuses réponses et conseils sur ce fil !

Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte ublock 
F9, que faut-il prévoir en plus côté accessoires ? Un gros trépied ? De quoi 
l'alimenter ? Un boîtier étanche pour les intempéries ? Et côté softs ? Je vais 
devoir faire établir un devis et ne voudrais rien oublier.

Le seul intérêt du matériel que j’avais trouvé sur le net est qu’il soit 
apparemment capable de recevoir les infos différentielles Omnistar, le seul 
service (payant sous abonnement) qui semble couvrir l’Afrique subsaharienne. 
Comme c’est malheureusement un machin propriétaire qui exige que le récepteur 
soit compatible (https://en.wikipedia.org/wiki/OmniSTAR), je pense que le 
Drotek ne doit pas pouvoir l’utiliser. Mais pour éviter de rester des jours sur 
un même point en mode PPP, il y a donc la méthode intéressante proposée par 
Éric d’avoir un récepteur fixe et un autre mobile, ce qui rend l’organisation 
du terrain plus facile. Si j’ai bien compris, l’idée n’est pas de créer une 
base GNSS comme le montrait Stéphane dans sa présentation, mais d’avoir deux 
récepteurs qui enregistrent leur position de manière Indépendante et du 
post-traitements une fois le terrain fini ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un atelier 
pratique lors du SotM de Nantes sur toute la chaîne des deux approches Ublock 
en PPP et deux ublocs + ? Je pourrais amener un ou deux Drotek.

Séverin___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread dcapillae
Hi, Rory.

The logo will continue on the wiki until the page is deleted. The procedure
for deleting wiki pages is describe on the wiki. [1]

You don't have to accept the deletion if you don't agree. As I said in my
first message, the rights holder is the OSM Foundation, and only they
decide. It has been suggested that you consult with OSMF members. [2] It
could be a good way to resolve the controversy. 

Greetings from Spain.

Happy mapping.

Regards,
Daniel

[1] https://wiki.openstreetmap.org/wiki/Delete
[2]
https://wiki.openstreetmap.org/wiki/File_talk:2019_OSM_Anarchist_Antifa_logo.svg



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

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


[Talk-de] Einladung Berliner OSM Hackweekend 28./29.3.2020

2020-02-17 Thread lars lingner
Hallo,

für das kommende OpenStreetMap Hackweekend am 28./29.03.2020 möchte ich
wieder alle Neugierigen und an OSM Interessierten einladen.

Das Hackweekend wird in den Räumen bei Wikimedia stattfinden. Der
Wikimedia e.V. unterstützt die FOSSGIS/OpenStreetMap-Community durch die
Bereitstellung der Räume und IT-Infrastruktur.
Außerdem ist eine Reisekostenerstattung möglich: Für die Teilnahme an
dieser Veranstaltung kann eine Reisekostenübernahme bei Wikimedia
Deutschland beantragt werden. Alle Informationen dazu sind auf dieser
Seite [1] zu finden.

Wie gewohnt findet die Planung im OSM-Wiki [2] statt. Bitte tragt Euch
dort in die Liste ein wenn ihr kommen möchtet und ob ihr an den social
Events teilnehmen werdet. Im Wiki findet ihr auch weitere Infos und ggf.
Updates für die Planung.
Es gibt auch ein Event bei Meetup [3], wem das lieber ist.

Das Hackweekend ist gut geeignet für Einsteiger und Erfahrene. In
gemütlicher Atmosphäre lassen sich hier Erfahrungen und Tipps austauschen.



Viele Grüße aus Berlin

Lars

[1]
https://de.wikipedia.org/wiki/Wikipedia:F%C3%B6rderung/Reisekostenerstattungen
[2] https://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_M%C3%A4rz_2020
[3] https://www.meetup.com/de-DE/OSM-Berlin-Brandenburg/events/268198964/
[4] http://wiki.openstreetmap.org/wiki/Berlin/Stammtisch


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


Re: [talk-au] Gravel pits?

2020-02-17 Thread Mateusz Konieczny via Talk-au



Feb 17, 2020, 10:29 by thesw...@gmail.com:

> On 17/2/20 7:13 pm, Jonathon Rossi wrote:
>
>> What about a stockpile? And material=gravel/dirt/sand/...?
>>
>
> landuse=stockpile
> resource=aggregate ?
>
I would use landuse=industrial industrial=* as it is in form easier to actually 
use

industrial=warehouse?
industrial=stockpile?

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


Re: [talk-au] Gravel pits?

2020-02-17 Thread Mateusz Konieczny via Talk-au
I used landuse=industrial industrial=warehouse for something similar.

Though I admit that I am now not sure whatever "warehouse" fits well for pile 
of coal,
even one that has specialized equipment supporting it.

I see also material= product = warehouse= tags used to tag what is stored there
( http://overpass-turbo.eu/s/QMP )
Feb 17, 2020, 10:49 by j...@jonorossi.com:

> Do we have tags for big stockpiles of iron ore, coal, etc at mines or ports? 
> These tend to be pretty permanent and with heaps of loading equipment around 
> them.
>
> On Mon, Feb 17, 2020 at 7:30 PM Andrew Davidson <> thesw...@gmail.com> > 
> wrote:
>
>> On 17/2/20 7:13 pm, Jonathon Rossi wrote:
>>  > What about a stockpile? And material=gravel/dirt/sand/...?
>>  > 
>>  
>>  landuse=stockpile
>>  resource=aggregate ?
>>  
>>  ___
>>  Talk-au mailing list
>>  >> Talk-au@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-au
>>
>
>
> -- 
> Jono
>

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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread osm . sanspourriel

Le 17/02/2020 à 18:26, Arnaud Champollion -
arnaud.champoll...@linux-alpes.org a écrit :


Du coup est-ce que ça veut dire qu'on peut cumuler :

building=shelter pour dire que *c'est* un abri
historic=shelter pour dire que *ce fut* un abri
amenity=shelter pour dire que ça peut être *utilisé* comme abri


Non, dans OSM on met essentiellement ce qui est.
Tu ne peux avoir historic=shelter et amenity=shelter.
Soit ce fut un abri et ça ne l'est plus historic=shelter
Soit ce fut un abri et ça l'est toujours amenity=shelter

Tu peux ajouter start_date=1848 si tu veux dire que c'est un abri depuis
1848.

Ou end_date=1970 pour dire que ce n'est plus un abri depuis 1970.

Si c'est juste du petit patrimoine ordinaire, à la place de historic,
peut-être was:amenity=shelter.

> building:loc=borie (si building=shelter, mais du coup où mettre borie
dans le cas où on n'utilise pas building ?)

Non, building:loc c'est la création ex abrupto d'un contributeur isolé.

Éventuellement building=borie ou shelter_type=borie (voir la valeur plus
standard un point-virgule et le nom). Pas fana non plus borie c'est du
français, pas de l'anglais.

shelter_type:FR=borie pour faire réagir Marc^^.

Quand je vois https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che

Je me dis que :

shelter_type=basic_hut

material=dry_stone

suffit pour décrire une cabane en pierre sèche. KISS, que les gens en
Provence ou ailleurs aient un terme spécifique, ça ne me dérange pas
mais la base est mondiale.

description et wikipedia : non, ça doit être spécifique à l'objet, là
c'est de la tautologie autour des tags.

Je réponds ainsi à tes questions :

> building=shelter (si le bâtiment est toujours debout, sinon ruins ?)
OK, mais il faut quand même qu'il reste plus qu'un tas de cailloux !

> building:loc=borie (si building=shelter, mais du coup où mettre borie
dans le cas où on n'utilise pas building ?)
Dans tous les cas tu oublies borie, ce n'est pas de l'anglais britannique.

> building:material=dry_stone (même question, où mettre dry_stone si on
n'utilise pas building ?)
material est plus général.

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


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread Stéphane Péneau

Le 17/02/2020 à 17:28, osm.sanspourr...@spamgourmet.com a écrit :

Le 17/02/2020 à 17:20, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :


alors que pour ceux qui ont déjà un smartphone...


RTKGPS ?



RTKGPS n'est que RTKLIB pour Android. Il faut tout de même un récepteur 
qui propose les données "RAW", ce qui est plutôt rare sur les 
smartphones, et les résultats sont ... moyens ... pour cause d'antenne 
pas terrible.



Stf


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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread Arnaud Champollion
J'ai bien lu ton message, essayé de bien comprendre et synthétiser une 
méthode (ci-dessous, avec mes questionnements encore)

Merci,



Le 17/02/2020 à 12:03, marc marc a écrit :

building:* sans building=* et building:loc spécialité franco-francaise
(voir même ultra local) font mal aux yeux.
si ce n'est plus un bâtiment mais des vestiges historic + description=*
me semble + adapté
si c'est encore un bâtiment ou building=capitelle ou building=shelter
shelter=capitelle



le tag historic décrit ce que c'était jadis.
le tag amenity décrit l'utilisation actuelle.
l'un est sans rapport avec l'autre (il existe des vestiges d'abris qui
ne sont plus utilisable, il existe des abris actuel qui n'ont rien de
vestiges historiques, il existe des abris qui sont les 2).



Du coup est-ce que ça veut dire qu'on peut cumuler :

building=shelter pour dire que *c'est* un abri
historic=shelter pour dire que *ce fut* un abri
amenity=shelter pour dire que ça peut être *utilisé* comme abri


Au final j'imagine :

historic=shelter   (dans tous les cas car ce sont bien tous d'anciens abris de 
bergers)

building=shelter   (si le bâtiment est toujours debout, sinon ruins ?)

amenity=shelter(si on peut toujours l'utiliser)

shelter_type=basic_hut   (possible car il y a au moins un shelter)

building:loc=borie   (si building=shelter, mais du coup où mettre borie dans le 
cas où on n'utilise pas building ?)

building:material=dry_stone (même question, où mettre dry_stone si on n'utilise 
pas building ?)

description=abri de berger en pierres sèches

wikipedia=fr:Cabane_en_pierre_sèche






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


Re: [Talk-it] [evento] FOSS4G Italia 2020

2020-02-17 Thread stefano campus
buongiorno a tutti,
questo è l'URL [1] da cui sarà trasmesso lo streaming delle sessioni di
FOSS4G Italia 2020 [2], da mercoledì 19 pomeriggio a venerdì 21 mattina.

[1] https://www.mediastream.polito.it/

[2] https://foss4g-it2020.gfoss.it/

s.



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

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


[OSM-talk] missing maps? no: missing GPS traces.

2020-02-17 Thread Mario Frasca

Hi everyone.

mapping Santa Fé, Veraguas, Panamá.  allegedly, a "strategic tourist 
attraction" for this country, but what's the strategy, I'm at odds 
understanding that.  anyhow.  I'm trying to convince the municipality to 
help me helping them, and my plan is to: (step 1) collect traces, (step 
2) process them together with local input and bing aerial pictures and 
integrate the information into OSM, (optional step 3) produce a nice 
large format map that makes the effort visible to people not using osm.org.


the "collect traces" step is where I'm most perplexed.  I've been 
walking around, travelling by local transport, uploaded the traces to 
OSM and my perplexity is how come aren't there any but really truly any 
other traces than what I've uploaded the last few weeks, and one by some 
German guy in 2009.


no, wait, I'm not just complaining for the sake of it, I'm looking for 
opportunities.


you see, we are in 2020, and people still do not know OSM even exists.  
just count them: we have 1.35 billion people walking with a handheld 
device, most of which with a GPS, and only 10 thousand installations of 
OSM Tracker for Android.  that's a really negligible percentage, 
homeopathic almost.


I opened an issue on the osmtracker-android github project, and I invite 
you to contribute ideas there.


https://github.com/labexp/osmtracker-android/issues/234

my ideal scenery would be: one arrives at an airport, or a bus terminal, 
and notices a poster advertising a 'minimal controls' osm tracker, with 
a QR code to download it.  installation is followed by opening it, and 
the program suggests creating an OSM account, and some default options 
for uploading traces.  then the process would be automatic: you start 
recording, you stop recording and at that moment the program asks "do 
you want to upload this to OSM?"  (now this option is hidden behind a 
long-press, and is followed by the not-yet-solved need to register on 
OSM.  let me tell you: casual users stop here.)


Mario


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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-17 Thread David Crochet

Bonjour

Le 17/02/2020 à 12:14, Florimond Berthoux a écrit :
puis je me suis dit qu’en fait peu importe que ça soit de la pierre 
artificielle ou non, l’important c’est de préciser la surface du terrain.



Oui c'est vrai    , de tout façon "gravel" est toujours plus précis de 
"ground"


Cordialement

--
David Crochet


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


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread osm . sanspourriel

Le 17/02/2020 à 17:20, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :


alors que pour ceux qui ont déjà un smartphone...


RTKGPS ?

Jean-Yvon



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


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread Eric SIBERT via Talk-fr

Le 2020-02-17 13:55, marc marc a écrit :

Merci pour les précieuses réponses précédentes.

Le 17.02.20 à 13:27, Eric SIBERT via Talk-fr a écrit :

ma recommandation première pour caler les photos satellites est
d'enregistrer un maximum de trace GPS sur les zones de travail.


je suis mitigé par cette solution.

[...]

Là, je parle surtout de l'Afrique, la question initiale du fil de 
discussion. À Madagascar, j'ai l'impression d'être presque le seul 
contributeur à téléverser des traces GPS. La seule ville où il y a trop 
de traces, c'est celle de ma belle-famille. Sur les grands axes, ça 
devient illisible mais on peut aussi caler l'imagerie avec les axes 
secondaires.



Ou alors tu as un outil pour trouver la valeur médiane d'un ensemble de
traces ?


Non. À un moment donné, il y avait un outil comme ça avec les données 
strava. J'ai essayé avec les traces GPS des cyclistes en montagne mais 
ce n'était pas très concluant. Les cyclistes enregistrent beaucoup plus 
de points à la montée qu'à la descente, ce qui tirait latéralement les 
traces côté montée. Ensuite, l'algorithme coupait un oeu sauvagement les 
virages.





comparativement, laisser un enregistreur gps quelque part pour obtenir
une position précise me plaît beaucoup.
en déduire ensuite par différentiel la position précise d'un point bien
identifiable sur imagerie me semble le top. au final un seul point dans
osm et surtout une grande facilité à faire l'alignement, tant pour moi


Oui mais beaucoup plus cher, un facteur limitant dans certains coins 
d'Afrique.


La solution avec deux F9P va couter 800 € (pour une portée de 35 km). On 
pourrait imaginer de travailler en mono-fréquence avec une puce Neo-M8M 
pour une centaine d'euros par récepteur et une portée limitée à 10 km.


Alors que pour ceux qui ont déjà un smartphone...

Eric


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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread osm . sanspourriel

Si je résume la discussion on peut se mettre d'accord sur :
- le fait que le numéro de sortie doit être dans et uniquement dans le
champ ref.
- le fait que le pseudo-nom de la sortie (en général le nom de la rue
dans laquelle débouche la sortie, quelques fois un grand équipement) est
stocké dans name et que c'est la seule information qui y figure.
(éventuellement utiliser les alt_name, old_name...).
- le fait que le nom de la station correspondante se retrouve via la
(une ?) relation stop_area dans laquelle figure la station et donc son nom.

Si tu ne vois pas d'objection, tu peux y aller.

Pour les stations à sortie unique met-on aucun nom ou le nom de la
station ? Je ne mettrais pas de nom. On peut les laisser de côté le
temps de se mettre d'accord.

Jean-Yvon

Le 17/02/2020 à 16:17, Sébastien Hinderer -
sebastien.hinde...@ens-lyon.org a écrit :

Re,

Juste pour être ^sur sur un point:

marc marc (2020/02/17 15:07 +):

je donnais 2 dans mon email précédent (à voir si quelqu'un émet
une objection)
- un chiffre n'est pas une nom mais une ref (name=Sortie 1 -> ref=1)

OK. Et est-ce que du ocup je peux enlever le chiffre de name?


- le nom de la station n'est pas le nom de l'arrêt

Aussi OK et du coup, même question, est-ce que je peux enlever le nom de
la station du name associé à la bouche?

Sébastien.

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



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


Re: [Talk-de] foot=yes on highway=primary / StreetComplete

2020-02-17 Thread Martin Scholtes
Das macht SC, wenn die Frage kommt, ob Fußgänger die Straße benutzen dürfen.

Am 17.02.2020 um 16:56 schrieb Florian Lohoff:
> Hi,
>
> Ich bin gerade über einige Changeset gestolpert in denen StreetComplete
> foot=yes auf primarys gepackt hat. 
>
> Mich wundert das so ein bisschen weil grundsätzlich war ich davon
> ausgegangen das alles ausser motorway als default foot=yes hat. 
>
> Flo
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

-- 
Mit freundlichen Grüßen


Martin Scholtes

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


[Talk-de] foot=yes on highway=primary / StreetComplete

2020-02-17 Thread Florian Lohoff

Hi,

Ich bin gerade über einige Changeset gestolpert in denen StreetComplete
foot=yes auf primarys gepackt hat. 

Mich wundert das so ein bisschen weil grundsätzlich war ich davon
ausgegangen das alles ausser motorway als default foot=yes hat. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Talk-GB] Saltash/Plymouth

2020-02-17 Thread ael
On Mon, Feb 17, 2020 at 01:53:50PM +, Devonshire wrote:
> I might have some traces for the straight through Devon to Cornwall route so 
> probably the same as what you already have. It would be better if someone 
> more local took a look.

I have many pretty accurate traces and fairly good geotagged dashcam
video of maybe a dozen or so of passes through the new layout. But just 
on the main road straight through, so of limited use for the surrounding
area & roads.

But I had a reply off list from another mapper who knows the area,
although he has now moved away. He has already done some updating, but I
have only just now had a quick glance at what he has done. He has
cleaned up the A388 to the NW which is now dual carriageway.

> It's a shame that the state of aerial photography for the SW that is 
> available to mappers is now so poor.

The Esir photography looks as if it was taken while the work was still
underway, but it is not bad. But I always prefer my own gps & video when
I have it.

As far as I can tell, there are no more than 4 or 5 people including
you, of course, who map in East Cornwall, and noone seems to be regular.
Although I do spend several months each year in the area so I am getting
close to being regular.

ael/messpert


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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Sébastien Hinderer
Re,

Juste pour être ^sur sur un point:

marc marc (2020/02/17 15:07 +):
> je donnais 2 dans mon email précédent (à voir si quelqu'un émet
> une objection)
> - un chiffre n'est pas une nom mais une ref (name=Sortie 1 -> ref=1)

OK. Et est-ce que du ocup je peux enlever le chiffre de name?

> - le nom de la station n'est pas le nom de l'arrêt

Aussi OK et du coup, même question, est-ce que je peux enlever le nom de
la station du name associé à la bouche?

Sébastien.

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread marc marc
Le 17.02.20 à 15:56, Sébastien Hinderer a écrit :
> marc marc (2020/02/17 14:42 +):
>> Le 17.02.20 à 15:13, Sébastien Hinderer a écrit :
 trois stop_area :

  * Place d'Italie (6) (7731239)

  * Place d'Italie (5) (7731238)

  * Place d'Italie (7) (7731237)


 partageant les mêmes sorties mais pas les mêmes stop_position.
>>> Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
>>> être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
>>> n'est-ce pas?
>>
>> hélas non, le métro des lignes 5 6 et 7 ne s'arrête pas au même
>> endroit.
> 
> Mais, ce n'est pas de ça qu'on parle, ici, si je ne m'abuse.
> Là où le métro s'arrête, ce sont les quais, qui sont effectivement
> différents pour chaque ligne et chaque direction. Mais il y a bien une
> entité abstraite, non géographiquement localisée, qui s'appelle Place
> d'Italie et qui est représentée par la relation, je pense. Enfin c'est
> ma compréhension de novice, je ne voudrais pas devenir trop affirmatif.

comme tu parlais de NOEUDS et pas de relation,
je pensais que tu parlais des 3 noeuds stop_position de ces relations
https://www.openstreetmap.org/node/4317624962
https://www.openstreetmap.org/node/4317624965
https://www.openstreetmap.org/node/4317624973

>> par contre, on peux se demander si on a besoin d'un stop_area par ligne
>> ou par station (et un contributeur avait créer encore une nouvelle
>> version de modélisation qui regroupe des stop_area...).
> 
> J'avais peut-être mal compris mais je pensais que stop_area c'était déjà
> les stations, non?

non, la station "logique" est
https://www.openstreetmap.org/node/235371392 (qui a une erreur de tag
par ailleurs)

les relations stop_position sont ambiguës :
pour certains c'est un lien intermodal (pour utiliser cet arrêt,
tu vas à pied à jusqu'à la plateforme d'attente, de là le véhicule te
prendra en charge). c'est en ce sens que le gars a créé 3 relations.

pour d'autres c'est un groupement d'arrêt proches (l'arrêt de la ligne
5 est proche de l’arrêt de la ligne 6 et proche de l’arrêt de la ligne 7
et proche de l’arrêt de bus en surface, donc une relation pour le tout).

> Je suis d'accord. J'ai juste du mal à voir, pour le moemnt, ce qui fait
> unanimité justement et donc ce sur quoi je pourrais avancer.

je donnais 2 dans mon email précédent (à voir si quelqu'un émet
une objection)
- un chiffre n'est pas une nom mais une ref (name=Sortie 1 -> ref=1)
- le nom de la station n'est pas le nom de l'arrêt
et un 3ieme : créer au moins une relation si aucune n'existe
pour cette bouche

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Sébastien Hinderer
Rebonjour,

marc marc (2020/02/17 14:42 +):
> Le 17.02.20 à 15:13, Sébastien Hinderer a écrit :
> >> trois stop_area :
> >>
> >>  * Place d'Italie (6) (7731239)
> >>
> >>  * Place d'Italie (5) (7731238)
> >>
> >>  * Place d'Italie (7) (7731237)
> >>
> >>
> >> partageant les mêmes sorties mais pas les mêmes stop_position.
> > Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
> > être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
> > n'est-ce pas?
> 
> hélas non, le métro des lignes 5 6 et 7 ne s'arrête pas au même
> endroit.

Mais, ce n'est pas de ça qu'on parle, ici, si je ne m'abuse.
Là où le métro s'arrête, ce sont les quais, qui sont effectivement
différents pour chaque ligne et chaque direction. Mais il y a bien une
entité abstraite, non géographiquement localisée, qui s'appelle Place
d'Italie et qui est représentée par la relation, je pense. Enfin c'est
ma compréhension de novice, je ne voudrais pas devenir trop affirmatif.

> par contre, on peux se demander si on a besoin d'un stop_area par ligne
> ou par station (et un contributeur avait créer encore une nouvelle
> version de modélisation qui regroupe des stop_area...).

J'avais peut-être mal compris mais je pensais que stop_area c'était déjà
les stations, non?

> a mon avis, on ne sait pas tout faire en même temps.

Certes et ce n'set sans doute pas un problème.

> se concentrer sur ce qui a une quasi unanimité permet d'avancer,
> plutôt que d'attendre la fin d'une modélisation qui n'est pas unique.

Je suis d'accord. J'ai juste du mal à voir, pour le moemnt, ce qui fait
unanimité justement et donc ce sur quoi je pourrais avancer.

Sébastien.

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread marc marc
Le 17.02.20 à 15:13, Sébastien Hinderer a écrit :
>> trois stop_area :
>>
>>  * Place d'Italie (6) (7731239)
>>
>>  * Place d'Italie (5) (7731238)
>>
>>  * Place d'Italie (7) (7731237)
>>
>>
>> partageant les mêmes sorties mais pas les mêmes stop_position.
> Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
> être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
> n'est-ce pas?

hélas non, le métro des lignes 5 6 et 7 ne s'arrête pas au même endroit.

par contre, on peux se demander si on a besoin d'un stop_area par ligne
ou par station (et un contributeur avait créer encore une nouvelle
version de modélisation qui regroupe des stop_area...).
en surface une par arrêt à l'avantage de la simplicité et d'éviter
l'arbitraire de "je décide que cet arrêt là est tellement proche de
celui-là que c'est lié". c'est arbitraire puisque le choix entre
distance à pied et temps de correspondance est variable selon la personne
En souterrain sans les highway=* d'interconnexion des différents zones
d'arrêt, c'est compliqué.

a mon avis, on ne sait pas tout faire en même temps.
se concentrer sur ce qui a une quasi unanimité permet d'avancer,
plutôt que d'attendre la fin d'une modélisation qui n'est pas unique.
hélas..
donc pour ma part je ne change pas l'un envers l'autre.
par contre je crée volontier une relation quand il n'en existe aucune
car je trouve le lien intermodal pratique
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Richard Fairhurst
Rory McCann wrote:
> The existence of an OSM cycling logo doesn't mean all 
> OSMers have to be cycling activists!

Wait, what?

cheers
Richard



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

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


Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread deuzeffe

<3

Le 17/02/2020 à 13:21, Vincent Bergeot a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png 



Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir 
pj) pour voir.


à voir mais sinon favorable à la version que tu proposes pour en avoir 
au sotm-fr effectivement


à plus



___
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] Données sur les bouches de métro franciliennes

2020-02-17 Thread Sébastien Hinderer
Bonjour Jean-Yvon et merci beaucoup pour ton message!

osm.sanspourr...@spamgourmet.com (2020/02/17 15:02 +0100):
> Par contre certaines bouches ont des "name" qui sont ceux de la
> station. :-(

Je peux éventuellement le concevoir si une station n'a qu'une seule
bouche de sortie comme Dugommier par exemple. Je ne dis pas que c'est
idéal, mais je peux imaginer donner du sens à ça.

> Sur Nuremberg, name c'est le nom de la destination (la rue sur laquelle
> on débouche).

C'est ce que je voudrais.

> N. B.  : j'ai regardé les utilisations de destination, en fait c'est moi
> qui avais introduit ça pour virer le gloubiboulga de RB94 (maintenant
> PARIS SUD) et ne laisser que la rue de destination en name.

Je plussoie ça.

> Exemple d'historique :
> https://www.openstreetmap.org/node/321920997/history
> 
> Pierre met le nom de la station Place d'Italie
> Noémie met station, numéro et destination en un : Place d'Italie -
> sortie 1 - Boulevard Auguste Blanqui
> RB94 "change certaines choses" et remplace le nom de la station par les
> références des lignes de bus : Bus 27 47 57 67 83 N15 N22 Sortie 1
> Boulevard Auguste Blanqui
> Bibi fait le ménage et dégage les bus dans la clé destination et
> supprime les infos dupliquées, ça devient : Boulevard Auguste Blanqui

Exactement ce vers quoi j'aimerais tendre, oui. Je me propose pour faire
ce genre de travail de façon systématique, je voudrais juste un GO. :)

> Et revoici RB94, devenu PARIS SUD suite à son blocage définitif, qui
> remet le bordel : (Place d'Italie) Sortie 1 Boulevard Auguste Blanqui

Oh non :(

> Pourquoi faire compliqué quand on peut fait inextricable ? Ce nœud fait
> partie de trois stop_area :
> 
>  * Place d'Italie (6) (7731239)
>
>  * Place d'Italie (5) (7731238)
>
>  * Place d'Italie (7) (7731237)
>
> 
> partageant les mêmes sorties mais pas les mêmes stop_position.

Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
n'est-ce pas?

Sébastien.

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


Re: [OSM-talk-fr] [OFF-TOPIC?] Les bories, historic ou amenity

2020-02-17 Thread deuzeffe

Bonjour,

Je me permets d'abonder dans le sens d'Arnaud et de préciser à Marcx2 
que oui, "c'est un type précis d'abris en pierre sèches par ex 
architecture particulière différentes des autres"


Arnaud, est-ce que vous vous êtes déjà "attaqués" aux glacières (il y en 
avait plein plein plein dans les Basses^WAlpes-de-Haute-Provence) ?


--
deuzeffe, loin de son pays :/

Le 17/02/2020 à 13:27, Arnaud Champollion a écrit :

Le 17/02/2020 à 13:21, Jacques Lavignotte a écrit :

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence), 



Dans le cas présent, il s'agit sans aucune hésitation de cabanes de 
berger, et on est bien à l'est de la vallée du Rhône.




___
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] Données sur les bouches de métro franciliennes

2020-02-17 Thread osm . sanspourriel

Le 17/02/2020 à 12:19, Stéphane Péneau - stephane.pen...@wanadoo.fr a
écrit :


Le 17/02/2020 à 09:19, Christian Quest a écrit :


Le fait qu'elle soit reliée à la station (stop_area) donne la
première indication, et le fait qu'elle porte un
nom/numéro/destination donne la seconde.

C'est ce qui rend inutile le nom de la station dans l'entrée.


Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par
exemple.


Bah alors, elles ont un nom ou pas ?

Je me trompe peut-être, mais je pense que si on s'amuse a supprimer
les "name" sur les bouches de métro/rer/train, ça ne va pas plaire à
tout le monde.


Est-ce la question ?

Un contributeur (voir dessous), malgré l'avis unanime des contributeurs,
mettait tout dedans : nom de la station, numéro de la sortie,
destination de la sortie, lignes de bus à la sortie.

Bref un guide touristique dans le "nom".

Donc non ça ne va pas plaire à tout le monde.


Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13


"destination" sur un noeud, ça ne fonctionne pas. C'est fait pour être
utilisé sur un way.


C'est fait pour, on est d'accord.

Ça ne veut pas dire qu'on ne peut étendre le modèle (ou pas, je ne dis
pas que j'ai raison, c'est une base de discussion d’ailleurs jusqu'à
présent j'ai utilisé name - description aussi, mais pour autre chose,
voir ci-dessous).

Sur Berlin les numéros/lettres de sorties sont sur ref. Bien.

Par contre certaines bouches ont des "name" qui sont ceux de la station. :-(

Sur Nuremberg, name c'est le nom de la destination (la rue sur laquelle
on débouche).

N. B.  : j'ai regardé les utilisations de destination, en fait c'est moi
qui avais introduit ça pour virer le gloubiboulga de RB94 (maintenant
PARIS SUD) et ne laisser que la rue de destination en name.

Exemple d'historique :
https://www.openstreetmap.org/node/321920997/history

Pierre met le nom de la station Place d'Italie
Noémie met station, numéro et destination en un : Place d'Italie -
sortie 1 - Boulevard Auguste Blanqui
RB94 "change certaines choses" et remplace le nom de la station par les
références des lignes de bus : Bus 27 47 57 67 83 N15 N22 Sortie 1
Boulevard Auguste Blanqui
Bibi fait le ménage et dégage les bus dans la clé destination et
supprime les infos dupliquées, ça devient : Boulevard Auguste Blanqui
Et revoici RB94, devenu PARIS SUD suite à son blocage définitif, qui
remet le bordel : (Place d'Italie) Sortie 1 Boulevard Auguste Blanqui

Pourquoi faire compliqué quand on peut fait inextricable ? Ce nœud fait
partie de trois stop_area :

 * Place d'Italie (6) (7731239)
   
 * Place d'Italie (5) (7731238)
   
 * Place d'Italie (7) (7731237)
   

partageant les mêmes sorties mais pas les mêmes stop_position.

Jean-Yvon

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


Re: [Talk-GB] Saltash/Plymouth

2020-02-17 Thread Devonshire
I might have some traces for the straight through Devon to Cornwall route so 
probably the same as what you already have. It would be better if someone more 
local took a look.

It's a shame that the state of aerial photography for the SW that is available 
to mappers is now so poor.

Kevin

On Sun, Feb 16, 2020, at 9:48 PM, ael wrote:
> Are there any local mappers in Plymouth or Saltash? ...
> 
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread Vincent Bergeot

Le 17/02/2020 à 13:59, osm.sanspourr...@spamgourmet.com a écrit :


J' et le cœur ❤️ devrait être alignés.

nouvelle version / 
https://nextcloud.openstreetmap.fr/index.php/s/td3eRcoBp6bwJk8


J'aurais augmenté le contraste à l'intérieur de la loupe pour rendre 
les 011010 un peu plus lisibles.



cela dépasse mes compétences

le fichier gimp 
https://nextcloud.openstreetmap.fr/index.php/s/wxNqdLtP8ZZZ8Zp


c'est du bricolage, sans doute qu'il faudra le reprendre pour que cela 
soit vraiment utilisable !





Jean-Yvon

Le 17/02/2020 à 13:21, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png 



Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir 
pj) pour voir.


à voir mais sinon favorable à la version que tu proposes pour en 
avoir au sotm-fr effectivement


à plus



___
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



--
Vincent Bergeot

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


[OSM-talk] For the sake of peace | Re: Cease use of OpenStreetMap/Antifa logo

2020-02-17 Thread Rory McCann
In order to keep the peace, I'll voluntarily delete that image from the 
OSM Wiki (as best I can). But the file is out there in the wild, you 
can't stop the internet.


I am only a random person at a keyboard, I'm too much of a wuss to throw 
stones at cops, I'm not a black block antifa protester! But (IMO) there 
is a problem today with the rise of xenophobia, of queerphobia, etc. I 
made this logo partially for fun, but also one way to oppose that hate. 
To me, it's more than just "for the lulz". Perhaps, in my original 
reply, I appeared too flippant. I make use of emoijis to convey tone, 
which is often lost in text.  means I want to be friendly.


To me, it's obvious that an OSM based logo doesn't mean OSM is 100% the 
same as that thing. If I make an OSM mash up, I can still see you as a 
fellow OSMer even if you don't agree with what that logo represents. The 
existence of an OSM cycling logo doesn't mean all OSMers have to be 
cycling activists! But perhaps that was not communicated well. I hope 
the community can figure out how to make that clear.


“Keep politics out of OSM” sounds nice, but I question what “politics” 
means here. It's often used only for feminism/pro-LGBTQ/anti-racism (and 
rarely mentioned when a copyright law changes). I think “politics” is 
too ambiguous to be useful when we talk to each other.


For those who see this logo as an OSM/OSMF endorsement, I'd like to see 
an OSM logo remix which, to them, doesn't imply endorsement, so I (and 
others) can design future logo remixes without implying endorsement. I 
never intended, or what to, imply OSMF endorsement, and I would like to 
know how to avoid that.



Let's get back to mapping the world.


Rory

On 13/02/2020 23:01, Rory McCann wrote:


Hello fellow OSMers! 

So this is from me. Last year I made some mashups of the OSM logo. There
is often a lot of big business presence at tech/FLOSS conferences now,
so I thought “What would be the opposite of that?” I am pretty lefty,
and I do like OSM's anarchistic/do-ocracy/flat/non-hierarchical
tradition anyway. So I ordered these stickers for a laugh, and they (&
the LGBTQ designs) were quite popular.

I don't believe it breeches the OSMF Trademark policy. §3.5 allows
remixed logos for user group logos. §3.2 & §3.4 allow the use of
stickers. (There is plenty of other examples of OSM trademark use BTW
) I thought it was clear that it didn't reflect OSMF policy, but I'm
sure I can communicate that better, to avoid all doubt. Mea Culpa. §2.2
of the Trademark policy does require a more explicit notice, which I've
now added to the wiki page. §2.3 says I shouldn't suggest OSMF
endorsement, and I don't want to suggest, or imply, OSMF affiliation or
endorsement!  I've added a message the wiki page for that image. Do
you think that suffices?

Yes, by definition all democratic societies are "anti-fascist", but even
I know the logo is more than just "anti-fascist", and... controversial. 

_However_ I need to think on this. We have a lot of work to do. We have
a whole world to map. I don't want everyone to fight, or external people
to get mistaken ideas about OSM.  Someone might have a false idea of
one thing, and (falsely) think all of OSM is like that.

That can go both ways: Right wing, bigoted, politicians sometimes claim
"antifa are violent terrorists" (cf. Trump after the Charlottesville
rally). “OSM doesn't have a Code of Conduct, and they just banned the
antifa logo saying it's a horrible violent organization!” could make
some marginalized groups (falsely) think OSM is full of a certain type
of hostile person!

As well as OSM being inherently political, "No politics" can (in
practice) translate to "Don't act gay, and people are allowed be
homophobic to you and you can't complain" (etc). If you think it's OK
for people to act gay/etc in an OSM event, then a "no politics" rule
communicates quite the opposite (alas). IMO you should rephrase.

Yes, the OSM community/OSMF should think about what kinds of (political)
issues we should (& shouldn't) get involved with, and what should be in
our spaces. (hey... maybe there should be some sort of code of how you
can conduct yourself in OSM spaces 樂)

So I need to think. My email inbox is open if anyone wants to give
suggestions/(confidential?) advice/tell me to knock it off/tell me to
keep going. Just cause something is legal, or within the trademark
policy, doesn't mean it's always a good idea. 


Yours, in mapping,

Rory


P.S.: For the avoidance of doubt: I paid for all these myself. This
email (& the logo) represent my personal opinions, not those of the OSMF
board, the OSMF, the OSM project, etc. I paid for these myself. These
stickers are not part of the newly founded CWG's promotional material
programme. I designed & got them well before I thought about running
for the board.

On 10.02.20 16:57, Midgard wrote:

Hi,

Someone created a mashup[1] between the logos of OpenStreetMap and 
Antifa, a collective of militant
groups 

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread osm . sanspourriel

J' et le cœur ❤️ devrait être alignés.

J'aurais augmenté le contraste à l'intérieur de la loupe pour rendre les
011010 un peu plus lisibles.

Jean-Yvon

Le 17/02/2020 à 13:21, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png


Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir
pj) pour voir.

à voir mais sinon favorable à la version que tu proposes pour en avoir
au sotm-fr effectivement

à plus



___
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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread marc marc
Merci pour les précieuses réponses précédentes.

Le 17.02.20 à 13:27, Eric SIBERT via Talk-fr a écrit :
> ma recommandation première pour caler les photos satellites est
> d'enregistrer un maximum de trace GPS sur les zones de travail.

je suis mitigé par cette solution.
si je regarde une de mes zones de confort où les images sat ne sont pas
toutes bien alignées (voir toute désalignée), la zone est noyées de
traces mais la qualité de celle-ci étant très variable (y compris
variable au sein même d'une trace), visuellement il n'y a pas grand
chose à en tirer.
il faudrait pouvoir flager une trace en "trop mauvais", ce point là en
"parasité" pour au final garder le potable en vu d'en faire une moyenne.
bref on sauve des centaines de point pour un résultat que je trouve bof.
Ou alors tu as un outil pour trouver la valeur médiane d'un ensemble de
traces ?

comparativement, laisser un enregistreur gps quelque part pour obtenir
une position précise me plaît beaucoup.
en déduire ensuite par différentiel la position précise d'un point bien
identifiable sur imagerie me semble le top. au final un seul point dans
osm et surtout une grande facilité à faire l'alignement, tant pour moi
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread Eric SIBERT via Talk-fr

faut-il laisser tourner une appli utilisant
le gps en permanence ?


Oui. OSMTracker par exemple, surtout que ma recommandation première pour 
caler les photos satellites est d'enregistrer un maximum de trace GPS 
sur les zones de travail.




paramètres de la ionosphère...).


cela est-il pris en compte aussi quand l'appareil est allumé en
intérieur avant de sortir (voiture, veranda) ou cette mesure risque
d'être faussée ?


Plus il y a de satellites, plus on récupère les infos rapidement. Sinon, 
on risque de travailler avec des informations incomplètes, voir 
périmées. De plus, en captant bien les satellites, le récepteur va, pour 
chaque satellite, en plus de la mesure de distance, récupérer la phase 
(le nombre de cycles de l'onde porteuse entre deux mesures de distance 
successives). La phase est très précise car elle est mesurée à une 
fraction de longueur d'onde près (longueur d'onde du signal GPS=20 cm). 
Ça permet de lisser efficacement la position dans le temps. Si on coupe 
la réception, on repart plus ou moins à zéro. Dans la véranda, collée à 
la maison et avec une structure métallique, ça risque de ne pas être top 
car on ne voit pas tous les satellites. Pour la voiture, un parebrise 
athermique risque aussi de poser problème. C'est néanmoins ce que je 
fais. Dès que j'arrive à la voiture, je mets en route le GPS sur le 
tableau de bord, le plus loin possible sous le parebrise. Ensuite, je 
charge les enfants, les bagages et tout...


Eric


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


Re: [OSM-talk-fr] [OFF-TOPIC?] Les bories, historic ou amenity

2020-02-17 Thread Arnaud Champollion

Le 17/02/2020 à 13:21, Jacques Lavignotte a écrit :

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence), 



Dans le cas présent, il s'agit sans aucune hésitation de cabanes de 
berger, et on est bien à l'est de la vallée du Rhône.




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


Re: [OSM-talk-fr] [OFF-TOPIC?] Les bories, historic ou amenity

2020-02-17 Thread Jacques Lavignotte

Borie, bòria, borde

Si on lit un peu avant l'article WKP

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence),


- à l'ouest de la vallée du Rhône

	- une ferme disposant d'un territoire agricole conséquent (bòria dans 
l'Aude et le Gard)


	-une grange de dimension telle que l'on peut y entrer une charette de 
foin et stocker (borde dans la Gascogne)


Mettez quelques régionalistes sur le cas..


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Nettoyage Enedis / GRDF

2020-02-17 Thread Quentin Salles
Bonjour,
J'ai effectué la modification des clés ERDF et ENEDIS sur toute la région
Occitanie. N'étant pas sur de ma contribution, voici ce que j'ai fait :
- Les postes de transformation basculent vers Enedis après vérification sur
le site de l'agence ORE
- Les câbles électriques en surface sont divisés en 2 parties :
-- Les "minor_line" ont comme opérateur Enedis
-- Les autres (voltage=63000) ont comme opérateur RTE.
J'espère ne pas m'être trompé sur mes contributions.

Je n'ai pas réalisé de bascule EDF vers Enedis vu que je ne suis pas assez
calé pour réaliser ces modifications.

Bonne journée

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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread Zdeněk Pražák
nakonec jsem nakopíroval java.exe do adresáře SysWOW64 a spuštění JOSM
funguje

po 17. 2. 2020 v 11:50 odesílatel Marián Kyral  napsal:

> A stáhl jsi 64bit verzi? Případně jak přesně to spouštíš? Možná bude
> stačit jen změnit / přidat cestu v tom skriptu.
> Mám dojem, že v tom ovládacím panelu je i nějaké info o tom, kde je java
> nainstalovaná. Pokud ne, tak zkus na disku  najít "java.exe".
>
> Marián
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 17. 2. 2020 11:25:13
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> stáhl a nainstaloval jsem si nejnovější verzi Javy 1.8.0_241
> Josm jsem doposud spouštěl pomocí konzole a při jejím spuštění mi nyní
> napíše hlášku
> systém Windows nemůže najít položku C:\Windows\SysWOW64\java.exe ujistěte
> se zda je název napsán správně a akci zopakujte
>
> pokud JOSM spustím ze staženého java souboru, tak naběhne správně a
> tracer LPIS funguje
>
> Co mám aktualizovat, abych JOSM mohl spouštt jako doposud pomocí konzole
> Pražák
>
> po 17. 2. 2020 v 9:40 odesílatel Marián Kyral  napsal:
>
> Ahoj,
> v ovládacích panelech by měla být komponenta "java" (nebo něco takového),
> kde by ti měl nabídnout aktualizaci javy.
> Případně stáhnout a nainstalovat ručně. Ale tam pak ještě potřebuješ
> vědět, jakou verzi potřebuješ (32/64 bit)
>
> https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/
>
> Marián
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 17. 2. 2020 9:20:36
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> hláška přetrvává i při použití uvedené url adresy v JOSM verze 15871
> Používám zatím windows 7 a java Verze prostředí Java: 1.8.0_31
>
> jak se provede aktualizace prostředí Java?
> Pražák
>
> ne 16. 2. 2020 v 16:42 odesílatel Marián Kyral  napsal:
>
> Jakou verzi javy a jaké windows máš?
> Menu: Nápověda/O aplikaci
>
>
> Podle mě by možná mohlo pomoct aktualizovat javu, nebo certifikační
> autority v systému. Jen nevím, jak se to dělá ve windows.
>
> Můžeš zkusit v prohlížeči třeba tuhle url?
>
> https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:102067
>
> Jinak pluginy jsou uloženy v adresáři který obsahuje proměnná
> , ale nemyslím si, že by to nějak pomohlo. Plugin funguje,
> problém je s navázáním spojení se serverem, ale to je interní věc javy.
>
> Marián
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 16. 2. 2020 16:12:25
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> hláška zní
> Chyba při stahování LPIS dat (lat = xxx lot = yy)
> chyba:sun.security.validator.Validator exeption: PKIX path building faile:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
>
> jak se odinstaluje (smaže) tracer-testing plugin
> Pražák
>
> ne 16. 2. 2020 v 15:31 odesílatel Marián Kyral  napsal:
>
> Ahoj,
> můžeš poslat celý ten text? Tohle jsem ještě nikdy neviděl. Dle Google to
> je nějaký problém s certifikáty.
>
> Teď jsem zkoušel u sebe a normálně funguje. Taky jsem stáhl poslední verzi
> josm, smazal tracer-testing plugin a znova ho nainstaloval a vše OK.
>
> Marián
>
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 16. 2. 2020 15:10:08
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> stejná hláška se mi začla objevovat i po vrácení se na předchozí verzi JOSM
> Pražák
>
> ne 16. 2. 2020 v 14:59 odesílatel Zdeněk Pražák 
> napsal:
>
> stáhl jsem si poslední verzi JOSM 15859 a aktualizoval vrstvu LPIS
>  po kliknutí na polygon LPIS se mi objeví hláška
> chyba:sun.security.validator,Validator exeptiion: PKIX path building failed
> ..
> a trasování neproběhne
> Pražák
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread marc marc
Bonjour,

Le 17.02.20 à 12:23, Eric SIBERT via Talk-fr a écrit :
> smartphone
> 10-15 mn, histoire de bien capter un maximum de satellites et de
> récupérer les dernières informations du réseau (satellites en service,

j'avais deja appliqué ce conseil dans le passé pour des photos sur
smartphone.
cependant en prennant des photos de manière "isolée" (une photo
maintenant, une autre photo + tard), j'ai l'impression que les données
récupérées lors du premier long fix ne sont pas sauvegardées.
plus précisément, la 2ieme position met aussi un certains temps à se
stabiliser.
est-ce une impression ? faut-il laisser tourner une appli utilisant
le gps en permanence ? ou certaines applis et ou système sauvegardent
l'information entre 2 utilisations du gps ?

> paramètres de la ionosphère...).

cela est-il pris en compte aussi quand l'appareil est allumé en
intérieur avant de sortir (voiture, veranda) ou cette mesure risque
d'être faussée ?

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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread Václav Kroupar
V SysWOW64 byla 32 bitová verze (Neptejte se mě, proč 64 značí 32 bitové
věci) 64 bit bude jinde. Já jí mám v C:\Program Files\Java\jre1.8.0_141\bin
-- Původní e-mail --
Od: Marián Kyral 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 2. 2020 11:56:44
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"
A stáhl jsi 64bit verzi? Případně jak přesně to spouštíš? Možná bude stačit
jen změnit / přidat cestu v tom skriptu.


Mám dojem, že v tom ovládacím panelu je i nějaké info o tom, kde je java
nainstalovaná. Pokud ne, tak zkus na disku  najít "java.exe".




Marián




-- Původní e-mail --
Od: Zdeněk Pražák 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 2. 2020 11:25:13
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

stáhl a nainstaloval jsem si nejnovější verzi Javy 1.8.0_241

Josm jsem doposud spouštěl pomocí konzole a při jejím spuštění mi nyní
napíše hlášku

systém Windows nemůže najít položku C:\Windows\SysWOW64\java.exe ujistěte se
zda je název napsán správně a akci zopakujte




pokud JOSM spustím ze staženého java souboru, tak naběhne správně a  tracer
LPIS funguje




Co mám aktualizovat, abych JOSM mohl spouštt jako doposud pomocí konzole

Pražák





po 17. 2. 2020 v 9:40 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ahoj,

v ovládacích panelech by měla být komponenta "java" (nebo něco takového),
kde by ti měl nabídnout aktualizaci javy.

Případně stáhnout a nainstalovat ručně. Ale tam pak ještě potřebuješ vědět,
jakou verzi potřebuješ (32/64 bit)




https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/
(https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/)




Marián




-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 17. 2. 2020 9:20:36
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška přetrvává i při použití uvedené url adresy v JOSM verze 15871


Používám zatím windows 7 a java Verze prostředí Java: 1.8.0_31




jak se provede aktualizace prostředí Java?

Pražák





ne 16. 2. 2020 v 16:42 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Jakou verzi javy a jaké windows máš?

Menu: Nápověda/O aplikaci









Podle mě by možná mohlo pomoct aktualizovat javu, nebo certifikační autority
v systému. Jen nevím, jak se to dělá ve windows.




Můžeš zkusit v prohlížeči třeba tuhle url?

https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS;
REQUEST=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-
1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:
102067
(https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:102067)





Jinak pluginy jsou uloženy v adresáři který obsahuje proměnná , ale nemyslím si, že by to nějak pomohlo. Plugin funguje, problém je s
navázáním spojení se serverem, ale to je interní věc javy.







Marián



-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 16:12:25
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška zní

Chyba při stahování LPIS dat (lat = xxx lot = yy)

chyba:sun.security.validator.Validator exeption: PKIX path building faile:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target





jak se odinstaluje (smaže) tracer-testing plugin

Pražák





ne 16. 2. 2020 v 15:31 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ahoj,

můžeš poslat celý ten text? Tohle jsem ještě nikdy neviděl. Dle Google to je
nějaký problém s certifikáty.




Teď jsem zkoušel u sebe a normálně funguje. Taky jsem stáhl poslední verzi
josm, smazal tracer-testing plugin a znova ho nainstaloval a vše OK.




Marián







-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 15:10:08
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

stejná hláška se mi začla objevovat i po vrácení se na předchozí verzi JOSM

Pražák





ne 16. 2. 2020 v 14:59 odesílatel Zdeněk Pražák mailto:zpra...@seznam.cz)> napsal:

"

stáhl jsem si poslední verzi JOSM 15859 a aktualizoval vrstvu LPIS

 po kliknutí na polygon LPIS se mi objeví hláška chyba:sun.security.
validator,Validator exeptiion: PKIX path building failed ..

a trasování neproběhne

Pražák



"
"
"
"
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread marc marc
Bonjour,

Le 17.02.20 à 11:41, Sébastien Hinderer a écrit :
> où on met le "nom" de la bouche, plus précisément si on le met
> dans name ou dans destination.

> Est-ce que vous croyez que la question peut être tranchée rapidement /
> facilement, histoire de pouvoir avancer sur le sujet?

osm est spécialiste dans les questions pas totalement tranchée :)
si j'étais toi :
- pour la modif des données, je ne toucherais pas pour le moment
à ce point là.
- pour l'utilisation des données, coder un algo qui supporte les 2.

cela te permettrait d'avancer sur tout le reste, principalement :
- le nom de la station n'est pas le nom de la sortie
- un chiffre n'est pas un nom mais la ref
- la relation public_transport=stop_area

pour le cas des sorties escalier+ ascenseur,
je pense qu'il y a 2 façon de le modéliser :
- façon courte avec un objet :
railway=subway_entrance
elevator=yes
wheelchair=yes
- version longue avec 2 objets :
railway=subway_entrance (éventuelement elevator=separate)
highway=elevator

l'iéal étant évidement dans les 2 cas de connecter la bouche
aux highway=* les plus proches.

pour le fait que 2 bouches sont connectés par un réseau interne,
en première approximation, il me sembble pas irréaliste d'ajouter
un highway=* a 2 noeuds qui les connecte, location=underground
en attendant d'avoir une cartographie plus précise (et compliquée)
des réseaux souterrains.

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


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Thread Eric SIBERT via Talk-fr

Bonjour,

En complément de mon précédent message et de celui de Stéphane.

Pour l'utilisation d'un récepteur GPS autonome ou d'un smartphone, on le 
met en route à l'avance et on le laisse sur un point dégagé pendant 
10-15 mn, histoire de bien capter un maximum de satellites et de 
récupérer les dernières informations du réseau (satellites en service, 
paramètres de la ionosphère...).


Pour la future campagne à Madagascar, je prévois de partir avec deux 
enregistreurs F9P. Pour les périodes plus ou moins en fixe, une dans un 
Parc National, l'autre dans une ville, je prévois de laisser un 
récepteur en fixe pour la durée du séjour alors que l'autre servira aux 
relevés sur le terrain. De retour en France, un calcul PPP sur les 
stations fixes temporaires doit permettre de descendre à 10 cm de 
précision sur ces stations. Ensuite, on fait un calcul différentiel 
entre la station fixe et la station mobile qui se déplace à quelques 
kilomètres de là, avec une incertitude de 1 cm + (1 mm par kilomètre 
d'écart). L'usage de deux récepteurs/antennes identiques permet de 
limiter certains biais de calcul.


Eric


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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Stéphane Péneau

Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


N. B. : curieux une bouche de métro au niveau -2. Non accessible depuis
l'arrêt de bus ?

Il y a un escalier, et le rideau métallique qui permet de fermer 
l'entrée est en bas de cet escalier.


il y a des photos sur Mapillary : 
https://www.mapillary.com/map/im/SVmAQGYC3wBDC8l7rxBwtg



Stf



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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Stéphane Péneau

Le 17/02/2020 à 09:19, Christian Quest a écrit :


Le fait qu'elle soit reliée à la station (stop_area) donne la première 
indication, et le fait qu'elle porte un nom/numéro/destination donne 
la seconde.



Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par 
exemple.



Bah alors, elles ont un nom ou pas ?

Je me trompe peut-être, mais je pense que si on s'amuse a supprimer les 
"name" sur les bouches de métro/rer/train, ça ne va pas plaire à tout le 
monde.




Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13

"destination" sur un noeud, ça ne fonctionne pas. C'est fait pour être 
utilisé sur un way.



Le 17/02/2020 à 09:19, Christian Quest a écrit :



Faire intervenir un autre type de relation (destination_sign) ne 
simplifie pas la réutilisation et de moins en moins KISS ;)



Coquin ! :-)

Ce type de relation existe pour les cas complexes que ne peut pas 
décrire seul le tag "destination". Lorsqu'on mélange "grandes gares", 
"indoor" et représentation surfacique, on se retrouve rapidement obligé 
de les utiliser.



Stf


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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread Jacques Lavignotte



Le 17/02/2020 à 12:03, marc marc a écrit :

Bonjour,

Le 17.02.20 à 11:32, Arnaud Champollion a écrit :

J'aide une contributrice à répertorier les bories, qui sont une des
appellations, dans le Sud-Est de la France, de cabanes en pierres sèches
: https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che


quand tu dis "appellation", veux-tu dire que c'est le nom en langage
courant pour désigner n'importe quel cabane en pierres sèches ?
ou c'est un type précis d'abris en pierre sèches par ex architecture
particulière différentes des autres ? le wiki a l'air de dire que c'est
ce dernier cas.


Ici ça me parait clair (et conforme à mon souvenir, c'est dire la 
validité ;) :


https://fr.wikipedia.org/wiki/Borie#Borie_au_sens_de_%C2%AB_cabane_en_pierre_s%C3%A8che_%C2%BB

J.
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-17 Thread Florimond Berthoux
Je me suis fait la même réflexion, puis je me suis dit qu’en fait peu
importe que ça soit de la pierre artificielle ou non, l’important c’est de
préciser la surface du terrain.
D’ailleurs le wiki dit :
«surface ground : No special surface, the ground itself has marks of human
or animal usage. This value gives only a rough description; if possible,
use a more precise value such as grass, clay, sand, earth, gravel or
pebblestone.»

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

Le lun. 17 févr. 2020 à 12:01,  a écrit :

> Bonjour
>
> - Mail original -
> de même, par contre c’est un surface=gravel, ce n’est pas de la terre,
> c’est un chemin empierré.
> - Mail original -
>
> C'est là que c'est pas facile à déterminer.
> J'ai l'impression que la pierre que l'on voit est de l'affleurement, c'est
> a dire que la roche apparait à la surface du sol et qu'il n'y a pas eu
> d'ajout artificiel de pierre
> En parcourant le chemin, le ravinage a emmené toute la terre et à donc
> laissé apparent la pierre, d'où mon "ground"
>
> Cordialement
>
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread marc marc
Bonjour,

Le 17.02.20 à 11:32, Arnaud Champollion a écrit :
> J'aide une contributrice à répertorier les bories, qui sont une des
> appellations, dans le Sud-Est de la France, de cabanes en pierres sèches
> : https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che

quand tu dis "appellation", veux-tu dire que c'est le nom en langage
courant pour désigner n'importe quel cabane en pierres sèches ?
ou c'est un type précis d'abris en pierre sèches par ex architecture
particulière différentes des autres ? le wiki a l'air de dire que c'est
ce dernier cas.

> Sur le Wiki OSM, on trouve une page du projet "Garrigues" qui propose
> une méthode pour les capitelles, un modèle assez proche :
> 
> https://wiki.openstreetmap.org/wiki/Garrigues#Petit_patrimoine_b.C3.A2ti

building:* sans building=* et building:loc spécialité franco-francaise
(voir même ultra local) font mal aux yeux.
si ce n'est plus un bâtiment mais des vestiges historic + description=*
me semble + adapté
si c'est encore un bâtiment ou building=capitelle ou building=shelter
shelter=capitelle
le piège à lapin en building est amusant mais erroné :)

> Je me suis dit qu'on pouvait suivre ce modèle, en adaptant
> building:loc=capitelle-->borie , et en ajoutant description=borie

si c'est une description, pas besoin de la dupliquer dans une autre clef
:) si c'est décrit par une clef, pas besoin de la dupliquer en description.

> historic=shelter
> historic=yes

cela c'est pas possible sur le même objet.
historic=shelter est le plus précis des 2, cela suffit

> shelter_type=basic_hut

si c'est encore aujourd'hui un abris utilisable (par exemple pour
s'abriter d'un orage pendant une balade, alors AJOUT de amenity=shelter
si ce n'est plus actuellement utilisable comme abris, alors il
ce n'est pas cohérent de préciser le type d'abris qu'il n'est pas.
ou alors il faudrait étendre ce cas (que personne ne semble utiliser
hormis l'auteur de la page wiki)

> j'ai modifié historic=shelter en amenity=shelter.

que le résultat soie faux ou juste, ton raisonnement n'a pas de sens.
le tag historic décrit ce que c'était jadis.
le tag amenity décrit l'utilisation actuelle.
l'un est sans rapport avec l'autre (il existe des vestiges d'abris qui
ne sont plus utilisable, il existe des abris actuel qui n'ont rien de
vestiges historiques, il existe des abris qui sont les 2).
c'est pas josm qui doit te guider sur ce qu'est l’objet historiquement
et son utilisable actuelle.

> name=borie

ce n'est pas le nom du bâtiment dans le sens osm de nom.
c'est le mot utilisé pour désigner des milliers d'entre eux.

> soit des historic=archaeological_site

si c'est juste un abris, le décrire comme site archéologique me semble
un peu gros.

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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-17 Thread david . crochet
Bonjour

- Mail original -
de même, par contre c’est un surface=gravel, ce n’est pas de la terre, c’est un 
chemin empierré. 
- Mail original -

C'est là que c'est pas facile à déterminer.
J'ai l'impression que la pierre que l'on voit est de l'affleurement, c'est a 
dire que la roche apparait à la surface du sol et qu'il n'y a pas eu d'ajout 
artificiel de pierre
En parcourant le chemin, le ravinage a emmené toute la terre et à donc laissé 
apparent la pierre, d'où mon "ground"

Cordialement

-- 
David Crochet

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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread Marián Kyral

A stáhl jsi 64bit verzi? Případně jak přesně to spouštíš? Možná bude stačit
jen změnit / přidat cestu v tom skriptu.


Mám dojem, že v tom ovládacím panelu je i nějaké info o tom, kde je java
nainstalovaná. Pokud ne, tak zkus na disku  najít "java.exe".




Marián




-- Původní e-mail --
Od: Zdeněk Pražák 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 2. 2020 11:25:13
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

stáhl a nainstaloval jsem si nejnovější verzi Javy 1.8.0_241

Josm jsem doposud spouštěl pomocí konzole a při jejím spuštění mi nyní
napíše hlášku

systém Windows nemůže najít položku C:\Windows\SysWOW64\java.exe ujistěte se
zda je název napsán správně a akci zopakujte




pokud JOSM spustím ze staženého java souboru, tak naběhne správně a  tracer
LPIS funguje




Co mám aktualizovat, abych JOSM mohl spouštt jako doposud pomocí konzole

Pražák





po 17. 2. 2020 v 9:40 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ahoj,

v ovládacích panelech by měla být komponenta "java" (nebo něco takového),
kde by ti měl nabídnout aktualizaci javy.

Případně stáhnout a nainstalovat ručně. Ale tam pak ještě potřebuješ vědět,
jakou verzi potřebuješ (32/64 bit)




https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/
(https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/)




Marián




-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 17. 2. 2020 9:20:36
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška přetrvává i při použití uvedené url adresy v JOSM verze 15871


Používám zatím windows 7 a java Verze prostředí Java: 1.8.0_31




jak se provede aktualizace prostředí Java?

Pražák





ne 16. 2. 2020 v 16:42 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Jakou verzi javy a jaké windows máš?

Menu: Nápověda/O aplikaci









Podle mě by možná mohlo pomoct aktualizovat javu, nebo certifikační autority
v systému. Jen nevím, jak se to dělá ve windows.




Můžeš zkusit v prohlížeči třeba tuhle url?

https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS;
REQUEST=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-
1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:
102067
(https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:102067)





Jinak pluginy jsou uloženy v adresáři který obsahuje proměnná , ale nemyslím si, že by to nějak pomohlo. Plugin funguje, problém je s
navázáním spojení se serverem, ale to je interní věc javy.







Marián



-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 16:12:25
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška zní

Chyba při stahování LPIS dat (lat = xxx lot = yy)

chyba:sun.security.validator.Validator exeption: PKIX path building faile:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target





jak se odinstaluje (smaže) tracer-testing plugin

Pražák





ne 16. 2. 2020 v 15:31 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ahoj,

můžeš poslat celý ten text? Tohle jsem ještě nikdy neviděl. Dle Google to je
nějaký problém s certifikáty.




Teď jsem zkoušel u sebe a normálně funguje. Taky jsem stáhl poslední verzi
josm, smazal tracer-testing plugin a znova ho nainstaloval a vše OK.




Marián







-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 15:10:08
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

stejná hláška se mi začla objevovat i po vrácení se na předchozí verzi JOSM

Pražák





ne 16. 2. 2020 v 14:59 odesílatel Zdeněk Pražák mailto:zpra...@seznam.cz)> napsal:

"

stáhl jsem si poslední verzi JOSM 15859 a aktualizoval vrstvu LPIS

 po kliknutí na polygon LPIS se mi objeví hláška chyba:sun.security.
validator,Validator exeptiion: PKIX path building failed ..

a trasování neproběhne

Pražák



"
"
"
"
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Sébastien Hinderer
Bonjour à tous,

Tout d'abord un grand merci à chacun pour vos contributions, toutes
hyper intéressantes à lire. Je n'ai pas encore pris le temps d'y
répondre, non pas par manque d'intérêt, loin s'en faut, mais parce que
j'aimerais d'abord essayer de dépouiller et d'avancer, pour pouvoir
apporter des éléments concrets et précis et pas rester dans du blabla
vague et général.

L'une des choses qui ne semble pas complètement tranchée, c''est de
savoir où on met le "nom" de la bouche, plus précisément si on le met
dans name ou dans destination. J'ai vu les deux avis exprimés et, pour
ma part, je n'en ai pas vraiment, en tout cas pas d'opinion tranchée.
Tout ce qui m'importe est qu'une décision soit prise, afin que je puisse
commencer le travail d'homogénéisation des données qui sont dans les
noeuds (il y en a tout de même 1188 à vérifier, au moins!).

Je fais juste une observation: mettre le "nom" ou la "description", ou
la "destination", dans name semble être la solution la plus conservative
par rapport aux pratiques en vigueur actuellement. Je ne sais pas si
c'est un argument suffisant pour justifier que c'est ainsi qu'il faut
faire, mais j'imagine qu'on peut au moins le prendre en considération.
Si on devait mettre le contenu de name dans destination, d'une part ça
ferait beaucoup de noeuds à modifier, d'autre part il faudrait voir où
on met ce qui est dans destination actuellement.

Est-ce que vous croyez que la question peut être tranchée rapidement /
facilement, histoire de pouvoir avancer sur le sujet?

Une belle journée à tous et à bientôt pour d'autres éléments de réponse,

Sébastien.

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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread majkaz
Nemáš tu javu nově nainstalovanou jinde než se ti spouští z konzole?
 
Protože ta hláška je jednoznačná - tam co jí to hledá (ten vypsaný adresář) - 
není. Pokud ano, stačí jen přepsat startovací příkaz na konkrétní cestu.
Tedy ne java -jar ale celou cestou třeba C:/adresář/java -jar 
 
Majka

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


[OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Thread Arnaud Champollion

Bonjour,

La question est à la fin du message.

J'aide une contributrice à répertorier les bories, qui sont une des 
appellations, dans le Sud-Est de la France, de cabanes en pierres sèches 
: https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che


Sur le Wiki OSM, on trouve une page du projet "Garrigues" qui propose 
une méthode pour les capitelles, un modèle assez proche :


https://wiki.openstreetmap.org/wiki/Garrigues#Petit_patrimoine_b.C3.A2ti

C'est assez suivi semble-t-il, si l'on suit le lien overpass donné.


Je me suis dit qu'on pouvait suivre ce modèle, en adaptant 
building:loc=capitelle-->borie , et en ajoutant description=borie


historic=shelter
building:loc=borie
building:material=dry_stone
description=borie
historic=yes
shelter_type=basic_hut


Là JOSM me prévient que ce n'est pas norla d'avoir un shelter_type sans 
amenity=shelter.


Donc j'ai modifié historic=shelter en amenity=shelter.


Ce qui donne :


amenity=shelter
building:loc=borie
building:material=dry_stone
description=borie
historic=yes
shelter_type=basic_hut


Une poignée de bories ont ainsi été ajoutés par ses soins.

Donc la question : je voudrais savoir si on a bien fait de mettre 
amenity=shelter comme le préconise JOSM, ou s'il vaut mieux suivre 
l'exemple de Garrigues avec historic=shelter.


Par ailleurs d'autres bories ont visiblement déjà été cartographiés par 
des contributeurs, avec soit des simples noeuds (ou même polygones) en 
name=borie, soit des historic=archaeological_site + name=borie.





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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread Zdeněk Pražák
stáhl a nainstaloval jsem si nejnovější verzi Javy 1.8.0_241
Josm jsem doposud spouštěl pomocí konzole a při jejím spuštění mi nyní
napíše hlášku
systém Windows nemůže najít položku C:\Windows\SysWOW64\java.exe ujistěte
se zda je název napsán správně a akci zopakujte

pokud JOSM spustím ze staženého java souboru, tak naběhne správně a  tracer
LPIS funguje

Co mám aktualizovat, abych JOSM mohl spouštt jako doposud pomocí konzole
Pražák

po 17. 2. 2020 v 9:40 odesílatel Marián Kyral  napsal:

> Ahoj,
> v ovládacích panelech by měla být komponenta "java" (nebo něco takového),
> kde by ti měl nabídnout aktualizaci javy.
> Případně stáhnout a nainstalovat ručně. Ale tam pak ještě potřebuješ
> vědět, jakou verzi potřebuješ (32/64 bit)
>
> https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/
>
> Marián
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 17. 2. 2020 9:20:36
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> hláška přetrvává i při použití uvedené url adresy v JOSM verze 15871
> Používám zatím windows 7 a java Verze prostředí Java: 1.8.0_31
>
> jak se provede aktualizace prostředí Java?
> Pražák
>
> ne 16. 2. 2020 v 16:42 odesílatel Marián Kyral  napsal:
>
> Jakou verzi javy a jaké windows máš?
> Menu: Nápověda/O aplikaci
>
>
> Podle mě by možná mohlo pomoct aktualizovat javu, nebo certifikační
> autority v systému. Jen nevím, jak se to dělá ve windows.
>
> Můžeš zkusit v prohlížeči třeba tuhle url?
>
> https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:102067
>
> Jinak pluginy jsou uloženy v adresáři který obsahuje proměnná
> , ale nemyslím si, že by to nějak pomohlo. Plugin funguje,
> problém je s navázáním spojení se serverem, ale to je interní věc javy.
>
> Marián
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 16. 2. 2020 16:12:25
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> hláška zní
> Chyba při stahování LPIS dat (lat = xxx lot = yy)
> chyba:sun.security.validator.Validator exeption: PKIX path building faile:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
>
> jak se odinstaluje (smaže) tracer-testing plugin
> Pražák
>
> ne 16. 2. 2020 v 15:31 odesílatel Marián Kyral  napsal:
>
> Ahoj,
> můžeš poslat celý ten text? Tohle jsem ještě nikdy neviděl. Dle Google to
> je nějaký problém s certifikáty.
>
> Teď jsem zkoušel u sebe a normálně funguje. Taky jsem stáhl poslední verzi
> josm, smazal tracer-testing plugin a znova ho nainstaloval a vše OK.
>
> Marián
>
>
> -- Původní e-mail --
> Od: Zdeněk Pražák 
> Komu: OpenStreetMap Czech Republic 
> Datum: 16. 2. 2020 15:10:08
> Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
>
> stejná hláška se mi začla objevovat i po vrácení se na předchozí verzi JOSM
> Pražák
>
> ne 16. 2. 2020 v 14:59 odesílatel Zdeněk Pražák 
> napsal:
>
> stáhl jsem si poslední verzi JOSM 15859 a aktualizoval vrstvu LPIS
>  po kliknutí na polygon LPIS se mi objeví hláška
> chyba:sun.security.validator,Validator exeptiion: PKIX path building failed
> ..
> a trasování neproběhne
> Pražák
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread osm . sanspourriel

+1 avec Christian.

Surtout on parle de *sorties*, destination fait le boulot.

Quand on parle des *entrées*, la destination (ici le pseudo nom) c'est
la station.

Si sur une carte vous voyez des bouches de métro 1,2, 3 autour de la
station X, si vous entrez dans une de ces bouches, où allez-vous ?

Gare de Lyon n'est jamais le nom de la bouche.

D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par exemple.

Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13

N. B. : curieux une bouche de métro au niveau -2. Non accessible depuis
l'arrêt de bus ?

KISS

Le 17/02/2020 à 09:19, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 14/02/2020 à 15:56, Stéphane Péneau a écrit :

Une partie des bouches portent des indications différentes selon si
on entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones
intérieures en surfacique, on avait utilisé les relations
destination_sign.
Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de
l'extérieur, et "Sortie Rue Van Gogh" lorsqu'on sort.
Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf


C'est normal vu qu'une bouche de métro est un point de passage pour
soit aller vers la station et prendre le métro, soit pour sortir de la
station et aller vers l'extérieur si possible dans une direction
donnée et donc la différencier des autres pour faire un choix.

Le fait qu'elle soit reliée à la station (stop_area) donne la première
indication, et le fait qu'elle porte un nom/numéro/destination donne
la seconde.

Faire intervenir un autre type de relation (destination_sign) ne
simplifie pas la réutilisation et de moins en moins KISS ;)




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


Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

2020-02-17 Thread Quentin Salles
Bonjour François,

Merci pour cet ajout. Je retrouve les cas que j'ai rencontré dans ma
commune, notamment les postes de distribution privés
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [talk-au] Gravel pits?

2020-02-17 Thread Jonathon Rossi
Aggregate, that's the word I was after.

Do we have tags for big stockpiles of iron ore, coal, etc at mines or
ports? These tend to be pretty permanent and with heaps of loading
equipment around them.

On Mon, Feb 17, 2020 at 7:30 PM Andrew Davidson  wrote:

> On 17/2/20 7:13 pm, Jonathon Rossi wrote:
> > What about a stockpile? And material=gravel/dirt/sand/...?
> >
>
> landuse=stockpile
> resource=aggregate ?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>


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


Re: [OSM-talk-fr] Proposition de Hack Weekend à Toulouse, 4 et 5 avril

2020-02-17 Thread Frédéric Rodrigo

Bonjour,

La date pour ce hack weekend est donc fixé au weekend du 4 et 5 avril.


Inscrivez-vous sur la page du wiki si vous envisagez de venir :

https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020


Vous pouvez venir avec un sujet sur lequel vous souhaitez avancer, ou 
participer à des sujets proposés par d'autres. L'asso OSM-FR à aussi 
besoin de coups de mains sur des besoins techniques par exemple de la 
maintenance sur uMap.



Frédéric.




Le 11/02/2020 à 15:05, Frédéric Rodrigo a écrit :

J'ai créer un framadate pour trouver le weekend qui convient le mieux

https://framadate.org/lugSTfQkmgibtAL9

l'idée est d’arrêter une date assez vite.

Frédéric


Le 07/02/2020 à 22:29, Vincent Privat a écrit :

Très bon choix de ville, je viens ! :D

Le ven. 7 févr. 2020 à 16:38, Christine Karch > a écrit :


    Idée géniale :)

    On pourrait demander l'Asso de supporter le coût du transport ...


    Am 07.02.20 um 16:28 schrieb PanierAvide:
    > Bonjour,
    >
    > Ce serait sympa en effet, à voir selon la date et le coût du
    transport
    > car Rennes c'est pas à côté.
    >
    > Cordialement,
    >
    > Adrien P.
    >
    > Le 07/02/2020 à 15:36, Vincent de Château-Thierry a écrit :
    >> Bonjour,
    >>
    >>> De: "Frédéric Rodrigo" mailto:fred.rodr...@gmail.com>>
    >>>
    >>> Avec mon employeur, Makina Corpus, je propose d'organiser une 
Hack

    >>> Weekend à Toulouse, sur le modèle de ce que fait par exemple
    >>> Geofabrik.
    >>> Il n'y a pas encore de date, mais l'idée est de le faire vers
    avril.
    >>> J'ai commencé à préparer une page sur le wiki pour cela:
    >>>
https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020
    >>>
    >>> J'aurais aimé avoir vos retours sur cette proposition et 
notamment

    >>> pour
    >>> choisir une date.
    >> Bonne idée ça :)
    >>
    >> Tu lances un https://framadate.org/ pour trouver le bon WE ?
    >>
    >> vincent




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


Re: [talk-cz] obora - myslivci - kanci

2020-02-17 Thread Dalibor Jelínek
Ahoj,

asi bych použil tourism=zoo +   
zoo=  enclosure

 

Dalibor

 

From: Marek Janata  
Sent: Monday, February 17, 2020 10:24 AM
To: talk-cz@openstreetmap.org
Subject: [talk-cz] obora - myslivci - kanci

 

Ahoj,

 

Jak bych měl správně tagovat tohle? 
https://www.openstreetmap.org/changeset/81076711 - jedná se o malou oboru s 
rodinou divokých prasat, kam se jim chodí házet tvrdý chleba a koukat na ně. 
Asi nic oficiálního, mají to spíš myslivci pro sebe

 

Hezký den

 

M

 

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


Re: [talk-au] Gravel pits?

2020-02-17 Thread Andrew Davidson

On 17/2/20 7:13 pm, Jonathon Rossi wrote:

What about a stockpile? And material=gravel/dirt/sand/...?



landuse=stockpile
resource=aggregate ?

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


[talk-cz] obora - myslivci - kanci

2020-02-17 Thread Marek Janata
Ahoj,

Jak bych měl správně tagovat tohle? 
https://www.openstreetmap.org/changeset/81076711 - jedná se o malou oboru s 
rodinou divokých prasat, kam se jim chodí házet tvrdý chleba a koukat na ně. 
Asi nic oficiálního, mají to spíš myslivci pro sebe

Hezký den

M

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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-17 Thread Florimond Berthoux
Salut,

@rainerU ton interprétation est bonne un track c’est un chemin agricole ou
forestier peut importe sa qualité de revêtement.
Grade 1 = « Solid. Usually a paved or sealed surface. »

Le lun. 17 févr. 2020 à 09:11, David Crochet  a
écrit :

> Bonjour
>
> Le 17/02/2020 à 07:33, rainerU a écrit :
> >
> > https://www.openstreetmap.org/changeset/79978741
> >
> >
>
> Les 2 photo montre une piste en sol naturel pierreuse sans ajout de
> matière autre avec un passage de roue non végétabilité c'est :
>
> Highway=track + grade=2 + smoothness=bad + surface=ground
>

de même, par contre c’est un surface=gravel, ce n’est pas de la terre,
c’est un chemin empierré.


>
> Cordialement
>
> --
> David Crochet
>

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


Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread Jacques Lavignotte



Le 17/02/2020 à 09:53, Christian Quest a écrit :

J'aurai mis un coeur à la place du "love " ou "adore" ;)


+1

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread Cédric Frayssinet
Le 17/02/2020 à 09:53, Christian Quest a écrit :
> J'aurai mis un coeur à la place du "love " ou "adore" 

Je me suis fait exactement la même réflexion. Un cœur rouge pour donner
un peu de visuel et panache à l'ensemble :)

Cédric



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


Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

2020-02-17 Thread Christian Quest

J'aurai mis un coeur à la place du "love " ou "adore" ;)


Le 17/02/2020 à 08:40, PanierAvide a écrit :


Salut,

+1, on en imprime pour le Sotm et les distribuer aux groupes locaux ? :-)

Cordialement,

Adrien P.
Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png

Vous en pensez quoi ?

Vincent


--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

2020-02-17 Thread Christian Quest

Le 17/02/2020 à 01:37, Victor/tuxayo a écrit :

On 20-02-13 00:27, marc marc wrote:

perso je suis fan de l'extention de unsigned sous forme
de  unsigned=
exemple unsigned=addr:housenumber : la plaque du no est absente
sur le terrain (mais l'info est vérifiable en opendata par ex)
donc dans ton cas, quand tu auras trouvé comment renseigner le panneau,
tu auras le moyen de renseigner son absence :-D


Donc dans ce cas ça donnerait:
tourism=information
information=board
unsigned=board_type:surveillance
ou unsigned:board_type=surveillance ?



Pas pour moi, car ce n'est pas un panneau d'information touristique (ça 
a été dit ici) donc pas de tourism=information


Le wiki me semble clair sur le fait que tourism=information est destiné 
aux touristes... ce n'est pas le cas de ces panneaux.


La réutilisation de base s'appuie en général sur les tags de premier 
niveau et ne connaît pas forcément toutes les finesses et subtilité 
apportées par les autres tags.




Piste plus simple:

Après lecture du wiki de unsigned=*
https://wiki.openstreetmap.org/wiki/Key:unsigned

> This key is used to annotate the fact that there is no on-the-ground 
sign indicating this feature's name.


Ça semble assez approprié en cas de manque de panneau réglementaire 
qu'on puisse mettre "unsigned=yes", il suffit d'étendre un peu l'usage 
de unsigned a plus que des noms.
Donc ça donne bien envie de partir dessus, mais du coup pourquoi on 
mettrait pas directement "signed=no" ou "signed=yes" plutot? Ce serait 
plus direct, et ça éviterait les confusions et les doubles négations 
("unsigned=no" signifierait qu'il y a un panneau...).


Et ça éviterait la chaine:
tourism=information
information=board
board_type=surveillance


== Donc en résumé ==
Créer la page wiki pour documenter:
signed=yes
signed=no

qui indique qu'un objet porte un panneau sur lui.
Et dans la page wiki de man_made=surveillance préciser que c'est par 
rapport au panneau réglementaire dans les contextes où une telle 
réglementation existe.


Si ça vous semble pas trop mal, je peux ouvrir le sujet sur la liste 
tagging.


== alternative ==
Si signed=* est trop général et que c'est gênant:
camera:signed=yes
camera:signed=no


À++



Signaler sur l'objet camera que la surveillance est correctement 
signalée ou pas, me semble plus adapté, après pour le tag éviter la 
double négation est préférable.


--
Christian Quest - OpenStreetMap France


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


Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu

2020-02-17 Thread Marián Kyral

Ahoj,

v ovládacích panelech by měla být komponenta "java" (nebo něco takového),
kde by ti měl nabídnout aktualizaci javy.

Případně stáhnout a nainstalovat ručně. Ale tam pak ještě potřebuješ vědět,
jakou verzi potřebuješ (32/64 bit)




https://cs.soringpcrepair.com/how-to-update-java-on-windows-7/




Marián




-- Původní e-mail --
Od: Zdeněk Pražák 
Komu: OpenStreetMap Czech Republic 
Datum: 17. 2. 2020 9:20:36
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška přetrvává i při použití uvedené url adresy v JOSM verze 15871


Používám zatím windows 7 a java Verze prostředí Java: 1.8.0_31




jak se provede aktualizace prostředí Java?

Pražák





ne 16. 2. 2020 v 16:42 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Jakou verzi javy a jaké windows máš?

Menu: Nápověda/O aplikaci









Podle mě by možná mohlo pomoct aktualizovat javu, nebo certifikační autority
v systému. Jen nevím, jak se to dělá ve windows.




Můžeš zkusit v prohlížeči třeba tuhle url?

https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS;
REQUEST=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-
1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:
102067
(https://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0=WFS=GetFeature=LPIS_DPB_UCINNE_BBOX=-486743.1165654754,-1125480.4023344317,-486059.08638271067,-1126293.6785051096=EPSG:102067)





Jinak pluginy jsou uloženy v adresáři který obsahuje proměnná , ale nemyslím si, že by to nějak pomohlo. Plugin funguje, problém je s
navázáním spojení se serverem, ale to je interní věc javy.







Marián



-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 16:12:25
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

hláška zní

Chyba při stahování LPIS dat (lat = xxx lot = yy)

chyba:sun.security.validator.Validator exeption: PKIX path building faile:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target





jak se odinstaluje (smaže) tracer-testing plugin

Pražák





ne 16. 2. 2020 v 15:31 odesílatel Marián Kyral mailto:mky...@email.cz)> napsal:

"

Ahoj,

můžeš poslat celý ten text? Tohle jsem ještě nikdy neviděl. Dle Google to je
nějaký problém s certifikáty.




Teď jsem zkoušel u sebe a normálně funguje. Taky jsem stáhl poslední verzi
josm, smazal tracer-testing plugin a znova ho nainstaloval a vše OK.




Marián







-- Původní e-mail --
Od: Zdeněk Pražák mailto:zpra...@seznam.cz)>
Komu: OpenStreetMap Czech Republic mailto:talk-cz@openstreetmap.org)>
Datum: 16. 2. 2020 15:10:08
Předmět: Re: [talk-cz] Tracer LPIS - nová verze, změna url LPIS podkladu
"

stejná hláška se mi začla objevovat i po vrácení se na předchozí verzi JOSM

Pražák





ne 16. 2. 2020 v 14:59 odesílatel Zdeněk Pražák mailto:zpra...@seznam.cz)> napsal:

"

stáhl jsem si poslední verzi JOSM 15859 a aktualizoval vrstvu LPIS

 po kliknutí na polygon LPIS se mi objeví hláška chyba:sun.security.
validator,Validator exeptiion: PKIX path building failed ..

a trasování neproběhne

Pražák



"
"
"
"
___
talk-cz mailing list
talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

2020-02-17 Thread Christian Quest
Les rôles label ne sont pas pris en compte par le rendu .fr et c'est 
sûrement pareil pour .org


Pourquoi ?

Parce que la transformation des données OSM en données pour les rendus 
ne permet pas de faire cela simplement.


Donc pour le rendu, seul le noeud place est utilisé.


Une relation type=boundary ? Mais ce n'est pas une frontière ou alors 
cela revient à considérer toute limite de zone comme une frontière... la 
lisière d'une forêt serait tout autant une "frontière" !


Dans l'exemple donné, on a un lotissement qui pourrait très bien se 
satisfaire d'un landuse=residential nommé.


Pourquoi avoir besoin d'un élément ponctuel pour mettre arbitrairement 
le nom à un endroit précis sur une carte ?


Si il n'y a plus la place pour ce libellé à cet endroit, le rendu n'a 
pas le droit de le déplacer dans le polygone ?



KISS !


Le 16/02/2020 à 19:12, Stéphane Péneau a écrit :

Le 16/02/2020 à 18:02, osm.sanspourr...@spamgourmet.com a écrit :


> Je suis le seul à trouver ça un peu tordu ?
Peut-être pas.

Mais en tous cas, moi ça ne me choque pas.

Si tu veux mélanger une notion surfacique et une notion ponctuelle, 
dans OSM la réponse c'est la relation. Après si tu dérives la notion 
ponctuelle à partir du surfacique, tu peux t'en passer. Mais ici le 
rendu ne tenant compte que des place sur les nœuds, tu n'y coupes pas.


Sauf à manquer d'une information.



Donc c'est tagger pour le rendu, non ?

Stf



Jean-Yvon

Le 16/02/2020 à 13:09, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :
Une relation pour délimiter un ensemble de 8 maisons ? Je suis le 
seul à trouver ça un peu tordu ?


Stf


Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :


https://www.openstreetmap.org/relation/10060749#map=19/47.78699/-3.48688

Le Prat et Les Jardins de Vitalis sont deux lotissements jointifs. 
Et tu pourrais les englober dans des place de plus haut niveau.


Ils font partie du landuse=residential de la zone agglomérée du 
bourg de Guidel.


On ne mélange pas l'utilisation (landuse) des dénominations (ici Le 
Prat et Les Jardins de Vitalis) qui ont leur vie propre si j'ose dire.


Jean-Yvon

Le 05/02/2020 à 21:26, Arnaud Champollion - 
arnaud.champoll...@linux-alpes.org a écrit :

Le 05/02/2020 à 21:23, pepilepi...@ovh.fr a écrit :


Pourquoi tu veux faire ça ? Si c'est juste pour le nommer il y a 
place=neighbourhood 
...


Bonne soirée,



Justement je ne veux pas le faire.

Je suis tombé dessus car il y a plusieurs zones mappées ainsi à 
Digne les Bains.


Je me suis dit que ça n'avait pas l'air normal, mais je voulais 
m'en assurer avant de supprimer ou remplacer par un tag plus adapté.




___
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




--
Ce message a été vérifié par *MailScanner* 
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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


--
Christian Quest - OpenStreetMap France

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Thread Christian Quest

Le 14/02/2020 à 15:56, Stéphane Péneau a écrit :
Une partie des bouches portent des indications différentes selon si on 
entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones 
intérieures en surfacique, on avait utilisé les relations 
destination_sign.

Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de 
l'extérieur, et "Sortie Rue Van Gogh" lorsqu'on sort.

Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf

C'est normal vu qu'une bouche de métro est un point de passage pour soit 
aller vers la station et prendre le métro, soit pour sortir de la 
station et aller vers l'extérieur si possible dans une direction donnée 
et donc la différencier des autres pour faire un choix.


Le fait qu'elle soit reliée à la station (stop_area) donne la première 
indication, et le fait qu'elle porte un nom/numéro/destination donne la 
seconde.


Faire intervenir un autre type de relation (destination_sign) ne 
simplifie pas la réutilisation et de moins en moins KISS ;)


--
Christian Quest - OpenStreetMap France


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


  1   2   >