Re: [talk-ph] Satellite imagery

[Erwin Olario]

Hi Glen.

>From what I've seen the Maxar layers are often better than what was
available from DigitalGlobe. Of course, this may vary a lot from place to
place, so it might not be true in your case. Could your case be an issue of
bad imagery alignment from Maxar?

If you don't mind sharing your the location of the area you're interested
in, could you? I'm curious about how they look like.

Anyway,It might be worthwhile to check the Mapbox layer, too. Or the more
updated Maxar Premium.



- - - - - - - - - - - - - - - - - - -
» email: erwin@ *n**gnu**it**y**.xyz*
 | gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Sat, Jul 6, 2019 at 8:11 AM Glen Scott  wrote:

> Sorry guys, I've been busy and not paying any attention to OSM of late,
> but just has a look and see Digitalglobe layers have been replaced by Maxar
> (I'm using iD). Google tells me Maxar bought Digitalglobe some time back.
> I'm now seeing water where I stood in a car park in early 2018, and where
> Digitalglobe was showing a car park. A few of my buildings are now in the
> sea. I think the Maxar imagery is maybe 4 years older than Digitalglobe.
>
> Any tricks to see the newer imagery (that we had)? Or just hard luck?
> Sorry if this has been discussed before...
>
> Cheers
>
> Glen
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-ph] talk-ph Digest, Vol 132, Issue 2

[Pierre Edwin See Tiong]

Hi Arnalie,

Sure! We're going to create some after event reports which is also requirement 
in our university. I'll share it once we done creating the report.

Thank you for the suggestion.

Regards,
Pierre

From: Arnalie Faye Vicario via talk-ph 
Sent: Friday, 5 July 2019 1:42 PM
To: talk-ph@openstreetmap.org
Subject: Re: [talk-ph] talk-ph Digest, Vol 132, Issue 2

Re: FEU Alabang YouthMappers Training

I agree with Erwin.

Suggestion: For Day 2, you can focus on Field Papers, Mapillary and other field 
data gathering tools, then uploading and downloading the data you collected. 
Also, make sure you have time for synthesis and for participants to share their 
experience from what the activities. Medyo siksik na kung may JOSM sa Day2, 
better focus on iD Editor.

Please share the outcome/feedback din through your OSM Diary or any social 
media sites! :D Good luck!

=Arnalie





On Thursday, July 4, 2019, 08:04:14 PM GMT+8, talk-ph-requ...@openstreetmap.org 
 wrote:


Send talk-ph mailing list submissions to
talk-ph@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ph
or, via email, send a message with subject or body 'help' to
talk-ph-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ph-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk-ph digest..."


Today's Topics:

  1. FEU Alabang YouthMappers Training (Pierre Edwin See Tiong)
  2. Re: FEU Alabang YouthMappers Training (Erwin Olario)


--

Message: 1
Date: Thu, 4 Jul 2019 10:35:23 +
From: Pierre Edwin See Tiong 
mailto:plseeti...@outlook.com>>
To: "talk-ph@openstreetmap.org" 
mailto:talk-ph@openstreetmap.org>>
Subject: [talk-ph] FEU Alabang YouthMappers Training
Message-ID:

mailto:yqxpr01mb2600de50f6611b6d54c89885c8...@yqxpr01mb2600.canprd01.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

Good Day,

The FEUTech YouthMappers has been invited to conduct a training for the 
Association of Computing Machinery (ACM) in FEU Alabang, the new and  3rd 
chapter of YouthMappers network in the Philippines. The training will cover all 
the introduction and basic skills that they will be needing such as 
informations about OpenStreetMap (OSM) and Humanitarian OpenStreetMap Team 
(HOT). This training will also cover the introduction and basic skills in OSM 
ID Editor, JOSM, Mapillary and Field Papers.

This will be a 2-days training from July 10 - 11, 9am to 4pm for all officers 
of ACM, all interested students and faculty members. Where the 1st day will 
focus on fundamentals and workshop using ID Editor, while the 2nd day will 
focus on using Field Papers, Mapillary and JOSM for their field mapping 
experience.

We are going to use the Food Security task for the first day training while the 
participants will be deployed to their designated area around FEU Alabang and 
Festival Mall for Field Papers and Mapillary experience.

Here are the hashtags that we are going to use:
#FEUAlabangYM
#YouthMappers

For comments, suggestions, questions please contact me in this email.
Wiki page: FEUAlabang YouthMappers 
Training
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Thu, 4 Jul 2019 18:56:45 +0800
From: Erwin Olario mailto:gov...@gmail.com>>
To: Pierre Edwin See Tiong 
mailto:plseeti...@outlook.com>>
Cc: "talk-ph@openstreetmap.org" 
mailto:talk-ph@openstreetmap.org>>
Subject: Re: [talk-ph] FEU Alabang YouthMappers Training
Message-ID:

mailto:h...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

That's goods news from the YouthMappers FEU chapter.

I wonder though why you want to include JOSM, when you only have two days
to cover all the other topics + the field work activity. I would suggest
you just focus on iD for editing -- it's powerful enough for most tasks,
including those activities you already outlined.



- - - - - - - - - - - - - - - - - - -
» email: erwin@ 
mailto:er...@ngnuity.net>>*n**gnu**it**y**.xyz*
 | gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Thu, Jul 4, 2019 at 6:36 PM Pierre Edwin See Tiong <
plseeti...@outlook.com> wrote:

> Good Day,
>
> The FEUTech YouthMappers has been 

Re: [talk-ph] FEU Alabang YouthMappers Training

[Pierre Edwin See Tiong]

Hi Sir Erwin,

This is noted, we're just thinking if it's going to be feasible for the 
schedule, but we're currently planning remove the JOSM and have it in separate 
dates once they become familiar in ID Editor and other tools.

Regards,
Pierre

From: Erwin Olario 
Sent: Thursday, 4 July 2019 6:56 PM
To: Pierre Edwin See Tiong
Cc: talk-ph@openstreetmap.org
Subject: Re: [talk-ph] FEU Alabang YouthMappers Training

That's goods news from the YouthMappers FEU chapter.

I wonder though why you want to include JOSM, when you only have two days to 
cover all the other topics + the field work activity. I would suggest you just 
focus on iD for editing -- it's powerful enough for most tasks, including those 
activities you already outlined.



- - - - - - - - - - - - - - - - - - -
» email: erwin@ngnuity.xyz | 
gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Thu, Jul 4, 2019 at 6:36 PM Pierre Edwin See Tiong 
mailto:plseeti...@outlook.com>> wrote:

Good Day,

The FEUTech YouthMappers has been invited to conduct a training for the 
Association of Computing Machinery (ACM) in FEU Alabang, the new and  3rd 
chapter of YouthMappers network in the Philippines. The training will cover all 
the introduction and basic skills that they will be needing such as 
informations about OpenStreetMap (OSM) and Humanitarian OpenStreetMap Team 
(HOT). This training will also cover the introduction and basic skills in OSM 
ID Editor, JOSM, Mapillary and Field Papers.

This will be a 2-days training from July 10 – 11, 9am to 4pm for all officers 
of ACM, all interested students and faculty members. Where the 1st day will 
focus on fundamentals and workshop using ID Editor, while the 2nd day will 
focus on using Field Papers, Mapillary and JOSM for their field mapping 
experience.

We are going to use the Food Security task for the first day training while the 
participants will be deployed to their designated area around FEU Alabang and 
Festival Mall for Field Papers and Mapillary experience.

Here are the hashtags that we are going to use:
#FEUAlabangYM
#YouthMappers

For comments, suggestions, questions please contact me in this email.

Wiki page: FEUAlabang YouthMappers 
Training

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

[talk-ph] Satellite imagery

[Glen Scott]

Sorry guys, I've been busy and not paying any attention to OSM of late, but
just has a look and see Digitalglobe layers have been replaced by Maxar
(I'm using iD). Google tells me Maxar bought Digitalglobe some time back.
I'm now seeing water where I stood in a car park in early 2018, and where
Digitalglobe was showing a car park. A few of my buildings are now in the
sea. I think the Maxar imagery is maybe 4 years older than Digitalglobe.

Any tricks to see the newer imagery (that we had)? Or just hard luck? Sorry
if this has been discussed before...

Cheers

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

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Tom Hummel via legal-talk]

> I am quite ignorant about the EU directive and it is beyond my ability to
> understand what is stated in it.

The problem is, I don’t have the slightest idea how this all plays out
in Japan. The only thing I would imagine is that there are some
similiar protection laws because Japan signed the TRIPS agreement. Art.
10 par. II of TRIPS requires some protection. That is probably as
close as I can get about your situation.

I think there may be some provisions found in ACTA, which Japan seems
to have signed. So for OSM hosters in Japan, there could be
implications. Does anybody know?

Most servers are however located within the EU (for now), so EU law
should remain our focus.

> someone publishing data about their OWN shops (or other types of objects) →
> not passing barrier of protection
> 
> someone publishing data about shops where there was "substantial" effort into 
> making database →
> protected

That would be my line of argument, because compiling information about
_your own shop_ will be trivial most of the time. There are, of course,
other situations. However opening hours is such an ordinary
piece of data, it will seem ridiculous someone claiming any sort
of effort while compiling it for his/her own business. Within the few
cases I have found, the parties claim hundreds of thousands of € in
costs for creating databases.

The distinction is not 100% safe, but in my opinion this
constitutes an acceptable guideline. Any effort of a third party
gathering information about others should for safety be considered
substantial.

At last – what’s the difference in reading a printed sign on the street
and a shops website stating the opening hours for our purpose?

Opinions?

About these TESCO claims… some seem quite outlandish indeed.

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

Re: [OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[Mateusz Konieczny]

5 Jul 2019, 22:16 by muramototom...@gmail.com:

> Thanks everyone.
>
> I ask a simple question. May I copy the information of the TESCO Boston 
> Superstore to OSM?
> https://www.tesco.com/store-locator/uk/?bid=2108 
> 
>
> This website contains information such as
> - addr=*
> - phone=*
> - opening_hours=*
> - branch=*
>
> The OSM data for this store does not yet contain `phone=*` nor 
> `opening_hours=*`. Can I copy them to OSM?
> https://www.openstreetmap.org/way/61998754 
> 
>
I am pretty sure that it is OK (but again I am not a lawyer, not 100% sure etc)

> Note: TESCO claims that the information on the website is protected.
> https://www.tesco.com/help/terms-and-conditions/#Intellectual 
> 
>
And here I am quite certain that this is attempt of Tesco to maliciously 
mislead users.

Many of this claims are misleading and/or absurd.
The most absurd is
"print one copy of such content for your own personal, non-commercial use"

Printing ten or ten million copies of such content for personal use is 
perfectly fine
in a typical civilized country. In fact, by
posting this quote to mailing list I am violating other ridiculous restriction
("but not any server or other storage device connected to a network").

At most Tesco may ban my account on their online shop (not sure whatever even 
that 
would be legal in EU). Plenty of things that are described there as restricted 
are in fact 
completely OK and not violating copyright.

For example of other misleading part
"The content of the Site is protected by copyright, trade marks, database 
and other intellectual property rights."
the same can be said about any other website and many other things, including 
posts on 
this mailing list. But they write in way that suggests that this laws means 
that they are allowedto make restriction listed there.

Note that typically there are some laws allowing limited use of copyrighted 
materials,
with severe differences depending on location

- https://en.wikipedia.org/wiki/Fair_dealing 

- https://en.wikipedia.org/wiki/Fair_use 

- in Japan such rule is supposedly called something like "private use 
exceptions",
supposed to be described at
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%82%A2%E3%83%A6%E3%83%BC%E3%82%B9#.E6.97.A5.E6.9C.AC
 


But generally you may use materials for wider than Tesco presents here.

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

[OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[tomoya muramoto]

Thanks everyone.

I ask a simple question. May I copy the information of the TESCO Boston
Superstore to OSM?
https://www.tesco.com/store-locator/uk/?bid=2108

This website contains information such as
- addr=*
- phone=*
- opening_hours=*
- branch=*

The OSM data for this store does not yet contain `phone=*` nor
`opening_hours=*`. Can I copy them to OSM?
https://www.openstreetmap.org/way/61998754

If I can use them, remote mapping of TESCO stores may be possible using
address data and satellite imagery. (Boston Superstore has already been
mapped on OSM, so remote mapping is not necessary in this case)

Note: TESCO claims that the information on the website is protected.
https://www.tesco.com/help/terms-and-conditions/#Intellectual

I do not know if these data are legally available or not, but I think it is
safe not to use these data for OSM.

Thanks.

muramoto tomoya
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] Nome linea elettrica che cambia

[Martin Koppenhoefer]

sent from a phone

> On 5. Jul 2019, at 20:58, demon_box  wrote:
> 
> che dici?


si

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

Re: [Talk-it] Nome linea elettrica che cambia

[demon_box]

dieterdreist wrote
> ma non sai se la ref è quella di Terna spa
> potresti mettere ref:ASM=* e sperare che a qualcuno risulterà utile ;-)

hai ragione, sai cosa ti dico, alla fine della fiera visto che in OSM si
mappa quello che c'è penso che mapperò esattamente ciò che leggo sulla
targhetta del traliccio, pur sapendo che almeno l'operator è di sicuro
variato ma altrimenti non se ne esce più...
che dici?

--enrico





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

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

Re: [OSRM-talk] Visualising the hierarchy

[Florian Lohoff]

On Fri, Jul 05, 2019 at 01:08:12PM +0100, Richard Fairhurst wrote:
> Hi all,
> 
> Is it in theory possible to take OSRM's CH graph and visualise, say, the
> "top 10%" of routes?
> 
> In other words, I'm interested in creating a map which shows the highest
> order of contractions - the routes which are most likely to be followed.
> Obviously I'll have to write some code, but would appreciate a few general
> pointers.

I'd be interested too. Currently i am selecting nodes on the routeable
grid manually to do long term route stability monitoring for
QA reasons. So i get mails when routes change around me. (Every 2 hours
i process routes) 

Selecting these grid nodes automatically by "importance" would be
helpful to do this kind of monitoring on a wider range.

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


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

Re: [Talk-it] Nome linea elettrica che cambia

[Martin Koppenhoefer]

sent from a phone

> On 5. Jul 2019, at 18:48, demon_box  wrote:
> 
> perchè ora sò che il vero operator è Terna S.p.a.?


ma non sai se la ref è quella di Terna spa
potresti mettere ref:ASM=* e sperare che a qualcuno risulterà utile ;-)

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

Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

[Topographe Fou]

 Merci. Le site me renoi encore une belle page avec une erreur de timeout... G...Selon https://josm.openstreetmap.de/wiki/Translations il faudrait doubler le guillemet simple. Ou alors utiliser un vrai caractère apostrophe ;o) . Essai et cela devrait marcher.LeTopographeFou   De: lenny.li...@orange.frEnvoyé: 5 juillet 2019 9:24 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin  
Le 05/07/2019 à 08:10, Topographe Fou a
  écrit :

  
  
  
  
 J'ai encore un soucis de timeout...
  J'avais réussi à y accéder entre temps. Peux-tu mettre sur la
  liste la phrase originale en anglais stp, celle avec les {x} ?
  Normalement si tu as les mêmes accolades entre l'original et
  le traduit cela devrait passer.
  
original anglais  : 
Which way segment should reuse the history of {0}?ma traduction :Quel segment de chemin doit réutiliser l'historique de {0} ?J'ai utilisé le bouton copie (la petite flèche à côté de
  English:) donc, ce sont les mêmes accolades (il me semble) et ce
  matin même message d'erreur
Leni

  
 


  LeTopographeFou

  
  


  De: lenny.li...@orange.fr
  Envoyé: 4 juillet 2019 12:08 PM
  À: talk-fr@openstreetmap.org
  Répondre à:
talk-fr@openstreetmap.org
  Objet: Re: [OSM-talk-fr] Josm
- traduction du logiciel - couper le chemin

  

  
  
  

  
  
  Le 24/06/2019 à 22:35,
LeTopographeFou a écrit :
  
  Pour Launchpad, la liste des phrases
non traduits (14 à ce jour pour le français) est accessible
là :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated
. Sauf que actuellement j'ai une erreur de Timeout :-( . 

LeTopographeFou 
  
  Comme je ne l'ai pas trouvée dans les éléments à traduire,
j'ai recherché le texte et j'ai trouvé :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=which+way
Elle était indiquée comme traduite, avec le texte anglais.
  J'ai essayé de mettre une nouvelle traduction "Quel segment
de chemin doit réutiliser l'historique de {0} ?" ; mais j'ai
le message d'erreur "There is an
  error in a translation you provided. Please correct it
  before continuing."
  Où ais-je fait
l'erreur ?
  Leni



  
  
  ___
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-it] Etichette con valori in lingua italiana

[Volker Schmidt]

No, almeno per quelle che ho scoperto per caso. Sono tutti dei valori
descrittivi non-standard.
Come detto sono pochi, ma il mio sospetto è che questi utenti abbiano
utilizzati valori "inventati" in Italiano anche per altre chiavi.
La mia domanda forse dovrebbe essere stata: sono l'unico ad avere
incontrato questo fenomeno, o ci sono altri casi. Per avere un idea se è un
problema diffuso o no.

On Fri, 5 Jul 2019 at 17:46, liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu> wrote:

> Il 05/07/19 11:57, Volker Schmidt ha scritto:
> > Per caso mi sono accorto che c'è un numero (limitato) di oggetti in OSM
> con
> > etichette cui valore è espresso in lingua Italiana.
> > Per esempio: surface=terra-erba (con varianti), surface=terra e fango
> > Numericamente sembra non essere un problema, ma volevo sollevarlo, in
> caso
> > qualcuno vorrebbe fare qualcosa sistematicamente.
> >
> > Volker
> >
>
> Che sia qualche bug di preimpostazioni di Josm o ID?
>
>
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nome linea elettrica che cambia

[demon_box]

dieterdreist wrote
> direi se manca quel riferimento lo potresti mettere tranquillamente, se
> invece ci fosse un altro numero presente in OpenStreetMap potresti
> chiedere a chi lo ha messo, invece di cambiare i dati subito.

ok ma nel concreto:

su OSM c'è soltanto power=tower
sul traliccio c'è questo

 

diventa 

power=tower
ref=1845
operator=ASM

oppure

power=tower
ref=1845
operator=Terna S.p.a.

perchè ora sò che il vero operator è Terna S.p.a.?

grazie

--enrico






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

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

Re: [Talk-it] Nome linea elettrica che cambia

[Martin Koppenhoefer]

sent from a phone

> On 5. Jul 2019, at 17:00, demon_box  wrote:
> 
> inoltre se oggi trovo una targhetta con scritto "ASM Palo 1847 Linea Nord
> 22" con tutti i passaggi societari chissà cosa è rimasto di vero voglio
> dire se ora quella linea e quel traliccio sono passati sotto Terna chi mi
> dice quei riferimenti del traliccio (1847) e della linea (22) Terna li abbia
> mantenuti tali e quali??
> che casino.
> 
> voi che dite?
> cosa è meglio fare?


direi se manca quel riferimento lo potresti mettere tranquillamente, se invece 
ci fosse un altro numero presente in OpenStreetMap potresti chiedere a chi lo 
ha messo, invece di cambiare i dati subito.

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

Re: [Talk-it] Etichette con valori in lingua italiana

[liste DOT girarsi AT posteo DOT eu]

Il 05/07/19 11:57, Volker Schmidt ha scritto:
> Per caso mi sono accorto che c'è un numero (limitato) di oggetti in OSM con
> etichette cui valore è espresso in lingua Italiana.
> Per esempio: surface=terra-erba (con varianti), surface=terra e fango
> Numericamente sembra non essere un problema, ma volevo sollevarlo, in caso
> qualcuno vorrebbe fare qualcosa sistematicamente.
> 
> Volker
> 

Che sia qualche bug di preimpostazioni di Josm o ID?



-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Mateusz Konieczny]

5 Jul 2019, 16:21 by yumean1...@gmail.com:

> Both of you are saying that factual data such as opening_hours, phone numbers 
> or addresses require no investiment 
> and thus they are not protected by the database rights. Am I right?
>
it seems to me that (I am no a lawyer etc) that it depends:

someone publishing data about their OWN shops (or other types of objects):
not passing barrier of protection

someone publishing data about shops where there was "substantial" effort into 
making database:
protected


For example making on  my own database of opening hours of Tesco shops in my 
country
would require visiting every single shop, I think that this data would be 
probably protected

---

in short: 
- we can copy from websites maintained by businesses both small and large as 
far as
copyright is concerned (other limitations may apply like concerns about data 
quality)
that give information about their own business
- we must not copy from other sources like phonebooks/Google Maps that 
aggregate results
about other businesses (except cases where we are really sure that database 
protection laws do not apply)

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

Re: [Talk-it] Nome linea elettrica che cambia

[demon_box]

tra l'altro ora mi viene in mente che in alta Valle Camonica mi sono
imbattuto in tralicci dell'alta tensione dove la targhetta riporta AEM
da AEM e ASM è nata A2A che poi ha ceduto l'alta tensione a Terna...
qui si entra nel campo delle fusioni societarie...!

inoltre se oggi trovo una targhetta con scritto "ASM Palo 1847 Linea Nord
22" con tutti i passaggi societari chissà cosa è rimasto di vero voglio
dire se ora quella linea e quel traliccio sono passati sotto Terna chi mi
dice quei riferimenti del traliccio (1847) e della linea (22) Terna li abbia
mantenuti tali e quali??
che casino.

voi che dite?
cosa è meglio fare?

grazie

--enrico




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

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

Re: [OSM-ja] 農水省の筆ポリゴンのインポート許可がおりました

[Nobusuke Iwasaki]

いいださん、みなさん

いわさきです。

> 岩崎さん＞こちらのアカウントをInviteさせてください https://github.com/wata909

承知しました。よろしくお願いしますm(__)m


2019年7月5日(金) 16:51 Satoshi IIDA :

>
> いいだです。
> 先程、農水省から、IDつきデータのダウンロードページが公開されました。
> 国土数値情報のように、アンケートを答えた後にDLすることができます。
> （利用規約はほぼ変わっていませんので、再配布など可能です）
>
> https://www.contactus.maff.go.jp/j/form/tokei/seiryu/hudeporianke-to.html
>
> 僕はちょうどDLおわったところで、これから内容を検分します。
>
> また、特に作業に対する反対意見はないようですので、前に進めたいと思います。（ありがとうございます！）
> そして、ライセンスに関しては長期的に揉めるところだと思いますので、
> Imports MLのほうにも早めに一報する予定です。
>
> > 浅野さん、岩崎さん（Tomさんも？）
> Githubのページで、進め方を検討しようと思っています。
> ついては、ProjectのTeamへの追加を行いたいです。
>
> 浅野さん＞Githubのアカウントはお持ちですか？ また、無い場合作成は可能でしょうか
> 岩崎さん＞こちらのアカウントをInviteさせてください https://github.com/wata909
>
> まぁ実際のところ、Issueに書き込むこととかはTeamに参加していなくてもできるので、
> なんかこう、チームとして顔が見えてるといいよね、というくらいの感覚です。
> 無理強いするものではありませんです。
>
> > 作業ワークフローについて
> 2つほど、意見を聞きたいです。
>
> 質問1. ファイルの単位について
> 基本的にファイルは、市町村の単位で作成されています。
> ただ、実際の作業にあたって、1つの市町村を1つの変更セットで作業することは、非常に手間が大きいと思っています。
>
> なので、いくつかのファイルに分割したほうがよいのではないかと思っています。
> どれがよいでしょう？
>
> 1. 町丁目単位（あるいはestatの小区域単位）で分割
> 2. 地域メッシュなど、なにかしらのメッシュ単位で分割
> 3. もとのファイルどおり、市町村単位で作業
>
> なお、複数人で作業になるので、Tasking Managerを使ってインポート＆確認作業をすることを考えていたのですが、
> タスク選択後、対象地域の.osmファイルを適切に拾ってくることができるのかなぁ、というのが課題です。
> いくつかのインポート作業の際に、どうしていたのか、諸外国のインポート作業Wikiをあさっています。
> うまいやりかたをご存知のかたがいたら教えてください。
>
> 質問2. 対象地域の選定
> まずはいくつかの地域で、テスト的に作業を実施できる市町村を探しています。
> 「うちの地域でやってみませんか」というところがありましたら、お声がけください。
> 古橋さんのゼミの方からお手伝いしたい、という申し出をいただいていて、
> 埼玉県横瀬町、神奈川県大和市、東京都調布市、あたりはどうでしょう？という話があります。
> 合計で2−3くらいあるといいな、と思っています。
>
> 農地があまり多くない都市圏、かつ既存データの位置精度が高めだと、作業しやすい印象です。
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
岩崎 亘典
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 8:04 AM Silent Spike 
wrote:

> Using the following established tags:
>

After all discussion so far I would update the list of tags to import as
follows:

   - `highway=bus_stop`
   - `public_transport=platform`
   - `bus=yes`
   - `name` [Imported - defer to existing tagging during conflation]
   - `naptan:AtcoCode` [Imported]
   - `naptan:NaptanCode` [Imported]
   - `naptan:CommonName` [Imported - should match `name` but may differ, is
   what the indicator is relative to]
   - `naptan:Indicator` [Imported - useful to distinguish stops and
   sometimes can be `loc_ref` data]
   - `naptan:verified=no` [Gets deleted upon verification according to the
   wiki]


I've checked and none of the stops here have Gaelic names (`name:gd`) -
though my script now supports them for import anyway. I also feel like
`source=naptan` is unnecessary since `naptan:verified` is basically the
same thing and the changeset(s) can have a source tag.

I'm trying to keep the amount of data somewhat minimal in line with the
following quote from the imports guidelines wiki page:

> However, don't go overboard with metadata. OSM is only interested in what
> is verifiable . This
> doesn't include (for example) foreign keys from another database, unless
> those are absolutely necessary for maintaining the data in future. Your
> data source may have many many fields, but OSM data elements with many many
> tags can be difficult to work with. Strike a balance. Figure out (discuss!)
> what fields the OSM community are interested in.
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[石野貴之]

Thank you, Mateusz and Tom.

I am quite ignorant about the EU directive and it is beyond my ability to
understand what is stated in it.
However, there is one thing I could barely find in your messages.

Both of you are saying that factual data such as opening_hours, phone
numbers or addresses require no investiment
and thus they are not protected by the database rights. Am I right?

Takayuki Ishino
yumean1...@gmail.com
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-it] Mapping campi rom

[Martin Koppenhoefer]

sent from a phone

> On 5. Jul 2019, at 10:10, Andrea Albani  wrote:
> 
> Quoto Andrea M.
> Stiamo parlando infatti di un'area di terreno, a volte attrezzata, a volte 
> no, e l'uso di residential=halting_site mi sembra una buona generalizzazione 
> per evitare la frammentazione del dato.
> Il tag è già usato 695 volte,


io sono d‘accordo con la tua analisi sul tagging proposto, ma non mi piace 
“landuse” per descrivere un feature.

Cosa diresti di place=halting_site
oppure amenity?

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

Re: [OSM-talk] Ways divided by paint?

[Mike N]

On 7/4/2019 10:33 AM, Jack Armstrong dan...@sprynet.com wrote:

In the given example, turns were already permitted prior to the additional 
superfluous lanes being added. This creates confusion and unnecessary clutter 
and should not be encouraged. The intersection was fine before the addition of 
the highway links. The new links add nothing to the map other than clutter.

https://www.openstreetmap.org/edit?changeset=70997250#map=20/39.57344/-104.98491


  The links do improve turn-by-turn instructions, in the case of 
following a large vehicle and not being sure where to leave the main 
lane of traffic to make a left turn.But it's also possible that 
adding turn lanes and/or change:lanes could work (but I'm not familiar 
with change:lanes enough to know for sure).


   I think some areas are more likely to add a physical divider based 
on history of traffic flow and available funds.


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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[marc marc]

Le 05.07.19 à 15:06, Tony Emery via Talk-fr a écrit :
> marc marc wrote
>> solution 2 : teste avec un extract qui contient bien les meta :)
>> genre un petit pays sur osm-fr
> 
> je vais où exactement ?

le plus petit extract d'osm-fr est dispo sous
http://download.openstreetmap.fr/extracts/africa/bouvet_island.osm.pbf
<20k en pbf :) 200K si tu convertis en .som
il contient les timestamp uid user etc
tu as (heureusement) évidement plein d'autres extraits
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Jean-Marc Liotier]

On Fri, July 5, 2019 2:40 pm, Christoph Hormann wrote:
>
> One warning:  All global population data sets that exist are rough
> estimates with usually significant systematic biases and errors.  For
> example in Switzerland the data set you used sees high population
> density in mountain areas with no basis in reality.

Same in rural Senegal. Low-resolution population data I guess.


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

Re: [Talk-it] Flame su old_name

[Martin Koppenhoefer]

sent from a phone

> On 5. Jul 2019, at 07:07, solitone  wrote:
> 
> Io ho citato la definizione di alt_name che viene data sulla wiki. E’ lì che 
> si parla espressamente di un “altro nome ufficiale” o di un "nome locale ma 
> preferito” [1]. Se la definizione non è precisa, allora andrebbe corretta.
> 
> [1] https://wiki.openstreetmap.org/wiki/IT:Key:alt_name


si, dovrebbe essere corretto, purtroppo c’è un errore di traduzione in questo 
paragrafo, l’originale dice il contrario sul nome ufficiale:
https://wiki.openstreetmap.org/wiki/Key:alt_name


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

Re: [Talk-it] Nome linea elettrica che cambia

[demon_box]

scratera wrote
> ..dubito che unireti si interessi di distribuzione a 130.000 kv...si
> fermna
> alla rete 20KV per il resto è terna ad occuparsi del 130.000 sul
> territorio
> nazionale

in effetti ho trovato questo articolo

https://www.a2a.eu/it/a2a-terna-accordo-cessione-rete-alta-tensione

nel quale si dice che A2A (prima ancora si chiamava ASM) cede la gestione
della rete alta tensione a Terna

grazie

--enrico





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

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

marc marc wrote
> solution 1 (non testée)
> avec un navigateur tu vas sur http://download.geofabrik.de 
> identification Oauth en bas à droite
> tu sauvegardes le cookie de ton navigateur que tu refiles à wget
> --load-cookies cookies.txt

Bon, j'ai vu ça sur Github :
https://github.com/geofabrik/sendfile_osm_oauth_protector/blob/master/doc/setup.md
Mais je suis bloqué à ce niveau :
Create a key store and the keys by executing the following command. Select
any key name you like. You will have to enter the name of the key and the
location of the key store in the configuration (see next step).
/srv/osm-internal-auth/generate_nacl_keys.py firstCookieKey
/var/lib/osm-internal-auth/keys/


marc marc wrote
> solution 2 : teste avec un extract qui contient bien les meta :)
> genre un petit pays sur osm-fr

Du coup, je veux bien me rabattre sur la solution 2 mais quand tu dis
osm-fr, je vais où exactement ?



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:41 PM Andy Townsend  wrote:

> The most interesting bit would be the "Manually conflate and review the
> data before upload using JOSM" - any JOSM CSS style that you end up using
> to highlight duplicates would be really useful, as would a basic OSM diary
> entry describing the process and the end result.
>

Would be happy to write an entry about my process if it comes to fruition.
I suspect it won't be as interesting as you might imagine since there's
really not a huge existing coverage of stops in the area. However, anything
to help future mappers also interested in this available data.

By downloading only bus stops in JOSM from the overpass API can easily see
where duplicates exist just by proximity to the NaPTAN stops. Have
considered expanding my script to also assist in conflation (marking
possible duplicates for manual review before upload), but for the Aberdeen
area it's probably not worth it.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

If you wanted to conflate indicator and common name into the OSM “name” field, 
then I can provide a list of what we call “prefix indicators” as opposed to 
“suffix indicators”. It’s fairly self-explanatory, as prefix indicators are 
generally those that are positional e.g. o/s, opp, adj, nr etc. For example, 
Stuart Close / opp -> “opp Stuart Close", whereas the suffix ones are not e.g. 
Bus Station / Bay 8 -> "Bus Station (Bay 8)”

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 13:40, Andy Townsend 
mailto:ajt1...@gmail.com>> wrote:

On 05/07/2019 13:19, Silent Spike wrote:
On Fri, Jul 5, 2019 at 1:02 PM Gareth L 
mailto:o...@live.co.uk>> wrote:
Forgive me if this is silly question/statement, but the adj/alt names etc are 
in the naptan dataset. Wouldn’t it be better to have the link made between the 
stop in OSM and the record in naptan (using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using that. 
Merging the extra data values again might potentially develop discrepancies 
over time.

I’d think the atco code is unique and (hopefully) not reused, but the alt names 
etc could be modified over time.

A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data consumer 
unless they know what it represents as per the NaPTAN schema - so perhaps it's 
best left out of the OSM data?

FWIW I did actually append that to name when displaying those because it 
"looked useful" (to append to the name and distinguish between other 
identically named stops):

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L5010

As to the original question "Would there be any objections to an import of the 
following scope" - certainly not from me.  I wouldn't personally use the PTv2 
"platform" tag but its presence doesn't break anything.

The most interesting bit would be the "Manually conflate and review the data 
before upload using JOSM" - any JOSM CSS style that you end up using to 
highlight duplicates would be really useful, as would a basic OSM diary entry 
describing the process and the end result.

Best Regards,

Andy



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

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:33 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> what did you have in mind? To the end-user of the data (i.e. someone
> wanting to know about where to catch the bus) this is absolutely critical.
>
> For example, in my previous post I face a suggestion of “Stuart Close”
> with an indicator of “adj”. There would usually be a second stop of the
> same common name, Stuart Close, perhaps with the indicator “opp”. Without
> understanding the NaPTAN schema, “app Stuart Close” and “adj Stuart Close”
> are understandable and are service direction dependent.
>

Well I was just thinking they're often descriptive abbreviations (and
admittedly aren't hard to deduce) with limited possible values as per the
NaPTAN schema. However, if it's just following the NaPTAN schema is there a
point in including it in OSM if that data is available and more up to date
there? While tags such as the stop name have corresponding tags in OSM
which have use to consumers who are not strictly following the NaPTAN
schema.

I'm certainly not against it's inclusion and would defer to your opinion
that it's useful data.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Tom Hummel via legal-talk]

> because it would be unfair if websites of small business are allowed
> and those of large comanies are not.

I don’t seem to be able to follow the problem here, hope you can help
me: how can a collection of opening hours be a protectable database
under directive 96/9/EG (speaking for the EU)?

> Maybe it can be argued that company has no substantial investment
> here? In neither obtaining nor verification nor presentation?
> 
> Presentation is simple one - there is clearly no substantial
> investment here. Not sure about what is understood as "substantial"
> for obtaining or verification.

You’re on the right path here.

First, only investments pertaining to obtaining or verification are
understood as investments under art. 7 par. I directive 96/9/EG. The
expenditure that incurred in the process of generating that data does
not.

Par. 46 of the court (EuGH, 09.11.2004 - C-203/02) adopted opinion of
the advocate general states:

« All the language versions thus allow of an interpretation according
to which, although ‘obtaining’ within the meaning of Article 7(1) of
the Directive does not cover the mere production of data, that is to
say, the generation of data, (10) and thus not the preparatory phase,
(11) where the creation of data coincides with its collection and
screening, the protection of the Directive kicks in. »¹

My question would be: how can a chain-business or even a franchise
business claim any investment in obtaining the opening hours of their
associated places of operation? In many cases they even dictate these
things, or simply ask the franchisee, or even demand the operators to
enter them into a list themselves.

I agree that the term ”substantial” rises some dificulty and I have
some trouble finding good guidelines.

¹
http://curia.europa.eu/juris/document/document.jsf?text==48761=0=EN=req==first=1

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Ed Loach]

Stuart wrote:

> Even more so in bus stations. The name Derby Bus Station (actually 
> just "Bus Station” in the locality of Derby) applies equally to all 29 
> bays in the bus station. “Bay 1” through “Bay 29” are the indicators.

Agreed this is useful when adding the stops for the mapper, but unless we are 
going to keep updating the naptan information fields as well as the OSM fields, 
isn't the naptancode (or atcocode) sufficient to check the latest information? 
Take for example this bus stop, imported ages ago:
https://www.openstreetmap.org/node/474893182#map=19/51.88949/0.89687=T
It has "naptan:Indicator"="Stop T" but "local_ref"="Fa" which might well be in 
the naptan indicator field now, but for a local mapper they are more likely to 
update local_ref to what is signposted when it changes than look at the naptan 
fields. And I don't think "opp" or "adj" belong in local ref.

What has been useful when adding routes is stop bearing, but again I can check 
this in NaPTAN data from the reference - it should be obvious in OSM from 
looking at the map. However I did find a few sections of very roughly traced 
roads that were the wrong side of the stops when I was creating the route 
relations, which I used the stop bearing and aerial imagery to sort out. 

Also, I suspect some latitudes and longitudes have been refined in NaPTAN since 
stops were first imported. I was creating one route where the stops showed as 
in the middle, or behind, the buildings fronting the road.

Ed


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


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

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Christoph Hormann]

On Friday 05 July 2019, Darafei "Komяpa" Praliaskouski wrote:
>
> http://disaster.ninja/live/
> 65046,bivariate_class;id=GDACS_EQ_1183112_1265046;layer=default-style;
>position=-13.88712117940031,30.076044779387132;zoom=2.4760319802318693
>>
>
> What do you think?

Are your densities in people/object per ground square kilometers or per 
mercator square kilometers? (just to be sure - this is the number one 
mistake of any kind of density analysis in the OSM context)

One warning:  All global population data sets that exist are rough 
estimates with usually significant systematic biases and errors.  For 
example in Switzerland the data set you used sees high population 
density in mountain areas with no basis in reality.

And i am not a fan of deliberately pixelated visualizations where the 
data is shown in a pixel grid at a coarser resolution than what the 
display offers.

Apart from that this is an interesting analysis.  It would be kind of 
nice to also do it separately for density of features that actually 
correlate with population density in reality (buildings, roads, 
addresses, shops etc.) and physical geography, which can be mapped just 
as densely in areas with no population as in densely populated areas.

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

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Andy Townsend]

On 05/07/2019 13:19, Silent Spike wrote:
On Fri, Jul 5, 2019 at 1:02 PM Gareth L > wrote:


Forgive me if this is silly question/statement, but the adj/alt
names etc are in the naptan dataset. Wouldn’t it be better to have
the link made between the stop in OSM and the record in naptan
(using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using
that. Merging the extra data values again might potentially
develop discrepancies over time.

I’d think the atco code is unique and (hopefully) not reused, but
the alt names etc could be modified over time.


A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data 
consumer unless they know what it represents as per the NaPTAN schema 
- so perhaps it's best left out of the OSM data?


FWIW I did actually append that to name when displaying those because it 
"looked useful" (to append to the name and distinguish between other 
identically named stops):


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L5010

As to the original question "Would there be any objections to an import 
of the following scope" - certainly not from me.  I wouldn't personally 
use the PTv2 "platform" tag but its presence doesn't break anything.


The most interesting bit would be the "Manually conflate and review the 
data before upload using JOSM" - any JOSM CSS style that you end up 
using to highlight duplicates would be really useful, as would a basic 
OSM diary entry describing the process and the end result.


Best Regards,

Andy




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

Re: [Talk-ca] English and French translation required for some road names

[James]

That way seems to be "tagged for the renderer".

1e Avenue is Première Avenue phonetically, but is probably 1e Avenue on the
sign.

As john has said it also depends on municipality, for example in
Orleans(french suburb of Ottawa) you can have street names like this
street(Maskinongé Crescent) https://www.openstreetmap.org/way/515701964 but
the french name is croissant du Maskinongé

On Fri., Jul. 5, 2019, 7:42 a.m. Steven Abrams,  wrote:

> Hi all, I am working with Microsoft Research and we have an app called
> Microsoft Soundscape (on iPhone only currently) for the Visually Impaired
> and Blind communities. The app provides a 3D map experience and calls out
> to the user several points of interest and road names, all based on OSM
> data.
> In Canada we have noticed that in the French speaking cities and areas of
> Quebec, that roads may be named "1e Avenue" or "1er Avenue".
> I am assuming that this should be called out as "Première Avenue" in
> French and "First Avenue" in English. Is this correct?
> But I have noticed that there is no translation for both languages.
> Is it possible for some local OSM mappers to consider providing these
> translations so that apps can callout the names of roads accurately? i.e. a
> user using the French Language & Voice settings would hear "Première" and
> users using the English Language & Voice settings would hear "First"?
> I have included a link to such a road where I have added the English
> translation.
> https://www.openstreetmap.org/way/20443208
> What are the thoughts here?
> Thanks
> Steven
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] English and French translation required for some road names

[Jarek Piórkowski]

I would expect this to be the same as the many "1st Street", "Twenty
Second Street", "16A Street", or "96 Avenue" we have in English
Canada: we go by what is signed and the software adapts. Hardcoding a
special case mapping "1e Avenue" within Québec to pronunciation
"Première Avenue" would be quite a lot simpler than changing Québec's
every way with that name in OSM.

And while Montréal is quite bilingual (-ish), outside Montréal I don't
think many people will be expecting to hear street names called out in
English as well as French.

--Jarek

On Fri, 5 Jul 2019 at 07:41, Steven Abrams  wrote:
>
> Hi all, I am working with Microsoft Research and we have an app called 
> Microsoft Soundscape (on iPhone only currently) for the Visually Impaired and 
> Blind communities. The app provides a 3D map experience and calls out to the 
> user several points of interest and road names, all based on OSM data.
> In Canada we have noticed that in the French speaking cities and areas of 
> Quebec, that roads may be named "1e Avenue" or "1er Avenue".
> I am assuming that this should be called out as "Première Avenue" in French 
> and "First Avenue" in English. Is this correct?
> But I have noticed that there is no translation for both languages.
> Is it possible for some local OSM mappers to consider providing these 
> translations so that apps can callout the names of roads accurately? i.e. a 
> user using the French Language & Voice settings would hear "Première" and 
> users using the English Language & Voice settings would hear "First"?
> I have included a link to such a road where I have added the English 
> translation.
> https://www.openstreetmap.org/way/20443208
> What are the thoughts here?
> Thanks
> Steven
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] English and French translation required for some road names

[Pierre Béland via Talk-ca]

Bonjour Steven
Au Québec, nous suivons les conventions de noms établies par la Commission de 
toponymie http://www.toponymie.gouv.qc.ca

Soit abbreviation 1re pour Première, 2e pour Deuxième, etc.

Votre projet est intéressant mais je pense qu'il y a des solutions qui 
éviterait de modifier la base OSM pour l'adapter à votre application Microsoft 
Soundscape. 

Vous pourriez créer une table de conversion qui indiquerait comment convertir 
les nos de rue avec de telles spécificités

code     fr     en1re     Premère avenue First avenue2e 
   Deuxième avenue    Second avenue
 
Pierre 
 

Le vendredi 5 juillet 2019 07 h 41 min 21 s UTC−4, Steven Abrams 
 a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  Hi all, I am working with Microsoft Research and we have an app called 
Microsoft Soundscape (on iPhone only currently) for the Visually Impaired and 
Blind communities. The app provides a 3D map experience and calls out to the 
user several points of interest and road names, all based on OSM data.In Canada 
we have noticed that in the French speaking cities and areas of Quebec, that 
roads may be named "1e Avenue" or "1er Avenue".I am assuming that this should 
be called out as "Première Avenue" in French and "First Avenue" in English. Is 
this correct?But I have noticed that there is no translation for both 
languages. Is it possible for some local OSM mappers to consider providing 
these translations so that apps can callout the names of roads accurately? i.e. 
a user using the French Language & Voice settings would hear "Première" and 
users using the English Language & Voice settings would hear "First"?I have 
included a link to such a road where I have added the English translation. 
https://www.openstreetmap.org/way/20443208What are the thoughts here?
Thanks
Steven___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

When you say that

the indicator field is somewhat meaningless to a data consumer

what did you have in mind? To the end-user of the data (i.e. someone wanting to 
know about where to catch the bus) this is absolutely critical.

For example, in my previous post I face a suggestion of “Stuart Close” with an 
indicator of “adj”. There would usually be a second stop of the same common 
name, Stuart Close, perhaps with the indicator “opp”. Without understanding the 
NaPTAN schema, “app Stuart Close” and “adj Stuart Close” are understandable and 
are service direction dependent.

Even more so in bus stations. The name Derby Bus Station (actually just "Bus 
Station” in the locality of Derby) applies equally to all 29 bays in the bus 
station. “Bay 1” through “Bay 29” are the indicators.

Regards,
Stuart Reynolds
for traveline south east and anglia

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

Re: [Talk-ca] English and French translation required for some road names

[John Whelan]

In Ottawa highway names for the most part have both English and French.  
name:fr rue Sparks, name:en Sparks street.  If only name is present it 
is the English version.


Just to add confusion to your life.  There has also been a discussion 
about street names in Canada and I think the municipality is the 
authority so adding an English version in Quebec might cause problems. 
Could CNIB assist?


Cheerio John

Steven Abrams wrote on 2019-07-05 7:40 AM:
Hi all, I am working with Microsoft Research and we have an app called 
Microsoft Soundscape (on iPhone only currently) for the Visually 
Impaired and Blind communities. The app provides a 3D map experience 
and calls out to the user several points of interest and road names, 
all based on OSM data.
In Canada we have noticed that in the French speaking cities and areas 
of Quebec, that roads may be named "1e Avenue" or "1er Avenue".
I am assuming that this should be called out as "Première Avenue" in 
French and "First Avenue" in English. Is this correct?

But I have noticed that there is no translation for both languages.
Is it possible for some local OSM mappers to consider providing these 
translations so that apps can callout the names of roads accurately? 
i.e. a user using the French Language & Voice settings would hear 
"Première" and users using the English Language & Voice settings would 
hear "First"?
I have included a link to such a road where I have added the English 
translation.

https://www.openstreetmap.org/way/20443208
What are the thoughts here?
Thanks
Steven


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


--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:02 PM Gareth L  wrote:

> Forgive me if this is silly question/statement, but the adj/alt names etc
> are in the naptan dataset. Wouldn’t it be better to have the link made
> between the stop in OSM and the record in naptan (using the codes prior
> mentioned).
> My thinking is data consumers could link and retrieve values using that.
> Merging the extra data values again might potentially develop discrepancies
> over time.
>
> I’d think the atco code is unique and (hopefully) not reused, but the alt
> names etc could be modified over time.
>

A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data consumer
unless they know what it represents as per the NaPTAN schema - so perhaps
it's best left out of the OSM data?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Vincent de Château-Thierry]

Bonjour,

> De: "Tony Emery via Talk-fr" 
> 
> Frédéric Rodrigo-2 wrote
> >> Et là, je suis sûr que tu vas me dire que je peux faire les 2
> >> premières étape en une seule ligne de commande...
> > 
> > Oui , même les trois ;-)
> 
> Et bien vas-y, dis-nous comment on fait ça...
> Pas besoin du 3ème car il va disparaître.

Tu utilises osmosis pour fusionner des pbf puis pour les clipper. Ce sont 2 
choses que permet osm2pgsql directement :
- pour la fusion, tu as juste à donner en entrée d'osm2pgsql non pas 1 pbf 
(celui sorti d'osmosis) mais les 3 récupérés sur Geofabrik
- pour le clip, tu as l'option d'osm2pgsql --bbox (ou -b) qui prend une liste 
de coordonnées dans l'ordre minlon,minlat,maxlon,maxlat
Ce que je ne sais pas dire c'est comment la fusion des 3 pbfs gère les objets 
communs à plusieurs datastes (genre frontière de région).

> Je crois que le problème était que je n'avais même pas réussi à installer 
> imposm3.

Ca ne s'installe pas vraiment, c'est juste une archive à telecharger et 
dezipper, en préservant l'arborescence interne des fichiers. Les zips sont ici 
: 
https://github.com/omniscale/imposm3/releases avec notamment la dernière 
release : 
https://github.com/omniscale/imposm3/releases/download/v0.8.1/imposm-0.8.1-linux-x86-64.tar.gz

vincent

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

[OSRM-talk] Visualising the hierarchy

[Richard Fairhurst]

Hi all,

Is it in theory possible to take OSRM's CH graph and visualise, say, the 
"top 10%" of routes?


In other words, I'm interested in creating a map which shows the highest 
order of contractions - the routes which are most likely to be followed. 
Obviously I'll have to write some code, but would appreciate a few 
general pointers.


cheers
Richard

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Gareth L]

Forgive me if this is silly question/statement, but the adj/alt names etc are 
in the naptan dataset. Wouldn’t it be better to have the link made between the 
stop in OSM and the record in naptan (using the codes prior mentioned).
My thinking is data consumers could link and retrieve values using that. 
Merging the extra data values again might potentially develop discrepancies 
over time.

I’d think the atco code is unique and (hopefully) not reused, but the alt names 
etc could be modified over time.


Gareth

On 5 Jul 2019, at 12:34, Silent Spike 
mailto:silentspike...@gmail.com>> wrote:

On Fri, Jul 5, 2019 at 11:35 AM Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:
-snip-

Hope that helps.

Pretty much the perfect response, thank you!

Good point about alternate names, will add support for those to my script now 
(maybe unnecessary for my area, but I'd like to share it in future). I see that 
many of the English alternate names are nearby landmarks or features (e.g. "The 
Crossroads"). Should I include these too as `loc_name` or similar (open 
question to all)?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

Hi,

In HOT mailing list I was advised to bring a part of a thing we did to
wider audience :)

We've correlated global population datasets with plain OpenStreetMap
objects count. The main use case is to quickly determine how much is there
to map in case of natural disaster in a smaller region, but the map itself
is global - it's interesting to see what's around you and find the spots to
map next, even outside of the disaster.

http://disaster.ninja/live/


What do you think?

(The HOT list thread if you are interested in disaster.ninja tool itself:
https://lists.openstreetmap.org/pipermail/hot/2019-June/014908.html)

Darafei Praliaskouski
kontur.io
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Leroy Olivier]

>
> si le but est de proposer qu'osm-fr suive geofabrik


Geofabrik indique qu'il sépare les données des metadonnées pour cause de
RGPB.

Aucune idée si c'est vrai, si c'est leur interprétation ou quoi ce soit
d’où la formulation de mon post. Si c'est bien la loi qui l'oblige tout un
tas de réponse peuvent êtres envisagées.

D'où ma question question du "Que faut-il faire ?"

Les réponses à cette question de Frédéric ("C'est beaucoup de complications
pour peu de choses.") ou Marc ("99% serrait sans doute inutilisé") me
conviennent parfaitement.

Olivier








Le ven. 5 juil. 2019 à 12:59, Frédéric Rodrigo  a
écrit :

>
>
> Le ven. 5 juil. 2019 à 12:16, marc marc  a
> écrit :
>
>> Le 05.07.19 à 11:25, Leroy Olivier a écrit :
>> > Du coup j'ai ouvert un rapide post sur le forum :
>> > https://forum.openstreetmap.fr/viewtopic.php?f=5=7221
>>
>> je n'ai pas compris ta question ni à qui elle s'adresse
>> c'est 2 visions différentes lié à 2 utilisations "par défaut":
>> géofabrik propose par défaut des fichiers sans meta puisque
>> la majorité des utilisations n'ont pas besoin de meta et force
>> une identification si tu veux les meta nécessaire par ex
>> pour au final éditer un objet
>> osm-fr produit des fichiers utilisé massivement par osmose
>> qui utilise ces metas. donc dupliquer tout sans meta sera
>> théoriquement mieux mais 99% serrait sans doute inutilisé.
>> osmose ne supporte pas (ou pas encore) les Oauth.
>>
>> si le but est de proposer qu'osm-fr suive geofabrik,
>> le forum n'est sûrement pas le bon lieu, la ml tech
>> ou asso est + adapté.
>> mais le soucis principal est probablement les bras.
>>
>
> On a déjà étudié ces questions et abandonné l'affaire.
>
> C'est beaucoup de complications pour peu de choses.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ca] English and French translation required for some road names

[Steven Abrams]

Hi all, I am working with Microsoft Research and we have an app called 
Microsoft Soundscape (on iPhone only currently) for the Visually Impaired and 
Blind communities. The app provides a 3D map experience and calls out to the 
user several points of interest and road names, all based on OSM data.
In Canada we have noticed that in the French speaking cities and areas of 
Quebec, that roads may be named "1e Avenue" or "1er Avenue".
I am assuming that this should be called out as "Première Avenue" in French and 
"First Avenue" in English. Is this correct?
But I have noticed that there is no translation for both languages. 
Is it possible for some local OSM mappers to consider providing these 
translations so that apps can callout the names of roads accurately? i.e. a 
user using the French Language & Voice settings would hear "Première" and users 
using the English Language & Voice settings would hear "First"?
I have included a link to such a road where I have added the English 
translation. 
https://www.openstreetmap.org/way/20443208 

What are the thoughts here?
Thanks
Steven___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 11:35 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> -snip-
>
> Hope that helps.
>

Pretty much the perfect response, thank you!

Good point about alternate names, will add support for those to my script
now (maybe unnecessary for my area, but I'd like to share it in future). I
see that many of the English alternate names are nearby landmarks or
features (e.g. "The Crossroads"). Should I include these too as `loc_name`
or similar (open question to all)?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Frédéric Rodrigo]

Le ven. 5 juil. 2019 à 12:16, marc marc  a
écrit :

> Le 05.07.19 à 11:25, Leroy Olivier a écrit :
> > Du coup j'ai ouvert un rapide post sur le forum :
> > https://forum.openstreetmap.fr/viewtopic.php?f=5=7221
>
> je n'ai pas compris ta question ni à qui elle s'adresse
> c'est 2 visions différentes lié à 2 utilisations "par défaut":
> géofabrik propose par défaut des fichiers sans meta puisque
> la majorité des utilisations n'ont pas besoin de meta et force
> une identification si tu veux les meta nécessaire par ex
> pour au final éditer un objet
> osm-fr produit des fichiers utilisé massivement par osmose
> qui utilise ces metas. donc dupliquer tout sans meta sera
> théoriquement mieux mais 99% serrait sans doute inutilisé.
> osmose ne supporte pas (ou pas encore) les Oauth.
>
> si le but est de proposer qu'osm-fr suive geofabrik,
> le forum n'est sûrement pas le bon lieu, la ml tech
> ou asso est + adapté.
> mais le soucis principal est probablement les bras.
>

On a déjà étudié ces questions et abandonné l'affaire.

C'est beaucoup de complications pour peu de choses.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Importing NaPTAN Data

[Ed Loach]

Silent Spike wrote:
> Would be curious to learn more about your route maintenance process. 
> I have a list of local bus route relations I've been meaning to update, but 
> it's hard to do so without all of the stops mapped (hence my desire to 
> import the available data).

The application I wrote and use is available on github and has some (perhaps 
now a bit dated) notes on use available there:
https://github.com/EdLoach/CheckPublicTransportRelations/tree/develop
The develop branch (above link) is what I'm currently using - I've not created 
a recent release to incorporate bug fixes, so should probably do so when I get 
a moment. I think there might be a current bug relating to adding new areas 
that aren't added in the default locations file on first run, so should 
probably fix that first.

I've avoided the recent tagging discussions emails. The app is written to 
validate against the adopted PT v2 schema as documented in the wiki, with 
additions to handle tagging noted in either the wiki or on this list dating 
from the time of the previous naptan stop import, and that I completely don't 
care about public_transport=stop_position. E.g. I have a "surveyed" property 
based on the various tags discussed previously: physically_present, flag, kerb, 
timetable_case and shelter (which I've taken as signs the imported stop has 
been physically surveyed, though typing this now I wonder if I should exclude 
shelter like I do layby as it can possibly be determined from aerial imagery - 
I just know I haven't locally):
https://github.com/EdLoach/CheckPublicTransportRelations/blob/master/CheckPublicTransportRelations/MainForm.cs#L365
(this is in the method that takes the OSM XML and converts it into one of by 
BusStop objects).

Basically it compares the OSM data with the Opendata and I try and fix 
discrepancies manually, either tweaking the route relations that have changed 
or by adding new route variants if required. I have occasionally been rate 
limited by overpass since I added a hyperlink column to zoom to a stop, rather 
than doing click on naptancode cell, ctrl-c, switch to JOSM, ctrl-f, ctrl-v, 
enter, check whether more than one node has been selected (as for example 
1500IM111 might match all these without adding extra bits after ctrl-v: 
1500IM111, 1500IM1110, 1500IM, 1500IM1112, 1500IM1112Y, 1500IM1114, 
1500IM1114Y, 1500IM1115, 1500IM1116, 1500IM1117, 1500IM1117Y, 1500IM1117YB, 
1500IM1117YC, 1500IM1119) - if I get limited I just take a break for a while.

The application isn't clever enough to know when a particular route variant 
runs, so if you run it at an unfortunate time you might find you add all the 
current route variants and all the ones that replace them starting soon so are 
also in the file, and next time you run the application have to delete half of 
what you added the previous time. A recent route change did give me forewarning 
of when a new roundabout on the A120 was about to open when a new route variant 
appeared, changing from the old route as it passed through a village near the 
new roundabout, to head northwest towards the roundabout instead of north to 
the gap in the dual carriageway that was due to close when the roundabout 
opened.

Ed



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


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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

From your original post, I didn’t think so, especially.

However, the fields in NaPTAN are designed to be granular, and while many may 
seem to be irrelevant to OSM (e.g. why have a street name when the street is 
named on the map) different local authorities will have different approaches to 
using that granularity for flag display. So the stop in NaPTAN might have a 
common name of “Stuart Close” with an indicator of “adj”, showing that the stop 
was adjacent to Stuart Close. However, street name becomes relevant if the 
local authority shows e.g. "High Street / Stuart Close” on the flag (with High 
Street being the street that the stop is physically located on).

So it is a bit of a “suck it and see”, but in general I would suggest that, of 
the descriptive fields, you definitely want Common Name and Indicator, and you 
should consider including Streetname, Crossing and Landmark. In Wales and 
Gaelic-speaking parts of Scotland (including Ayr, apparently, where they are 
now erecting dual language signage) you should also include any non-English 
alternative names too. I’m less fussed about Locality, because the context of 
the map should give it, but sometimes child (lowest level) localities are not 
named on the map, or are named differently to the map.

I certainly wouldn’t include the short names (which are usually just the 
abbreviations on on-street real time displays or fronts of buses) or the plate 
/ cleardown etc codes.

Note in passing that NaPTAN status often gets mis-used. Some authorities have a 
tendency to mark a stop as deleted when it no longer has services at it, even 
thought the infrastructure is still in place on the ground. These are supposed 
to be ACT but unused in NaPTAN, not deleted. If they are covered up, or 
physically removed, then they can be deleted. But not otherwise. You may come 
across some of these (or you may not).

Hope that helps.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 10:57, Silent Spike 
mailto:silentspike...@gmail.com>> wrote:

On Fri, Jul 5, 2019 at 10:52 AM Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:
Yes, both are still in use

-snip-

Regards,
Stuart Reynolds
for traveline south east and anglia

As someone more in the know, are there any fields of the NaPTAN data which you 
think should be imported which I haven't included?

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

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

Re: [OSM-ja] Proposal for a revision of JA:Available Data

[tomoya muramoto]

石野様

legal-talkへ投稿いただきありがとうございます。
私もまだ購読していないので、これから登録します。

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[marc marc]

Le 05.07.19 à 11:25, Leroy Olivier a écrit :
> Du coup j'ai ouvert un rapide post sur le forum : 
> https://forum.openstreetmap.fr/viewtopic.php?f=5=7221

je n'ai pas compris ta question ni à qui elle s'adresse
c'est 2 visions différentes lié à 2 utilisations "par défaut":
géofabrik propose par défaut des fichiers sans meta puisque
la majorité des utilisations n'ont pas besoin de meta et force
une identification si tu veux les meta nécessaire par ex
pour au final éditer un objet
osm-fr produit des fichiers utilisé massivement par osmose
qui utilise ces metas. donc dupliquer tout sans meta sera
théoriquement mieux mais 99% serrait sans doute inutilisé.
osmose ne supporte pas (ou pas encore) les Oauth.

si le but est de proposer qu'osm-fr suive geofabrik,
le forum n'est sûrement pas le bon lieu, la ml tech
ou asso est + adapté.
mais le soucis principal est probablement les bras.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

[Romain MEHUT]

Bonjour,

Petite digression, quel est l'intérêt des relation type=route avec
route=road pour représenter les routes départementales... cela ressemble
plus à une collection qu'à quelque chose d'utile, non ?

Merci.

Romain

Le ven. 5 juil. 2019 à 01:55, Jérôme Amagat  a
écrit :

>
> Mon opinion c'est qu'il faut rien changé, pas de ref sur les rond point
> par contre on n'interdit pas les relations type=route route=road pour
> représenter les routes départementales (ou nationale ou ...) qui existent
> un peu partout en France et qui il me semble comprennent la plupart du
> temps les ronds points.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[marc marc]

Le 05.07.19 à 11:13, Tony Emery via Talk-fr a écrit :
> je ne sais pas comment faire pour passer par l'extraction privée 
> dans mon script.

solution 1 (non testée)
avec un navigateur tu vas sur http://download.geofabrik.de 
identification Oauth en bas à droite
tu sauvegardes le cookie de ton navigateur que tu refiles à wget
--load-cookies cookies.txt
solution 2 : teste avec un extract qui contient bien les meta :)
genre un petit pays sur osm-fr

> pourquoi je n'ai même plus le timestamp ?

il avait parlé d'aussi le virer, vérifie si c'était le cas ou non.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Etichette con valori in lingua italiana

[Volker Schmidt]

Per caso mi sono accorto che c'è un numero (limitato) di oggetti in OSM con
etichette cui valore è espresso in lingua Italiana.
Per esempio: surface=terra-erba (con varianti), surface=terra e fango
Numericamente sembra non essere un problema, ma volevo sollevarlo, in caso
qualcuno vorrebbe fare qualcosa sistematicamente.

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:52 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> Yes, both are still in use
>
> -snip-
>
> Regards,
> Stuart Reynolds
> for traveline south east and anglia
>

As someone more in the know, are there any fields of the NaPTAN data which
you think should be imported which I haven't included?

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

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Mateusz Konieczny]

5 Jul 2019, 11:39 by yumean1...@gmail.com:

> because it would be unfair if websites of small business are allowed and 
> those of large comanies are not. 
>

I am guessing that it is also OK for large companies - but this is based on 
common sense
that often fails for copyright.

Though I would not care that for once something is unfair against large 
companies 
(to limit to OSM examples - name-suggestion-index[1] is useful and helps during 
mapping
but is biased against small companies and helps only in mapping chain POIs)

[1] https://github.com/osmlab/name-suggestion-index/ 




warning: I am digging into it as I am curious what is the answer, please 
remember
that I am not a lawyer and may be hilariously mistaken


https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:31996L0009=EN
 


"Whereas the term ‘database’ should be understood to include literary, 
artistic, musical or
other collections of works or collections of other material such as texts, 
sound, images,
numbers, facts, and data; whereas it should cover collections of independent 
works, data
or other materials which are systematically or methodically arranged and can be 
individually
accessed; whereas this means that a recording or an audiovisual, 
cinematographic, literary
or musical work as such does not fall within the scope of this Directive;"

"Whereas the protection provided for in this Directive relates to databases in 
which works,
data or other materials have been arranged systematically or methodically; 
whereas it is not
necessary for those materials to have been physically stored in an organized 
manner,"

I really would like to say that "here is list of opening hours for our 1250 
shops" is clearly
not a database but it seems to qualify (warning: I am not a lawyer).


https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31996L0009#d1e757-20-1
 

has

"Member States shall provide for a right for the maker of a database which 
shows that there 
has been qualitatively and/or quantitatively a substantial investment in either 
the obtaining, 
verification or presentation of the contents to prevent extraction and/or 
re-utilization of the 
whole or of a substantial part, evaluated qualitatively and/or quantitatively, 
of the contents 
of that database."

Maybe it can be argued that company has no substantial investment here?
In neither obtaining nor verification nor presentation?

Presentation is simple one - there is clearly no substantial investment here.
Not sure about what is understood as "substantial" for obtaining or 
verification.


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

Re: [Talk-it] Flame su old_name

[Andreas Lattmann]

Scusate, ma per l'uso locale non lo si mette in loc_name? 

Il 5 luglio 2019 07:07:10 CEST, solitone  ha scritto:
>
>> On 4 Jul 2019, at 14:28, Martin Koppenhoefer 
>wrote:
>> 
>> alt_name è semplicemente un nome alternativo. Non ha implicazioni di
>ufficialità o uso locale.
>
>Io ho citato la definizione di alt_name che viene data sulla wiki. E’
>lì che si parla espressamente di un “altro nome ufficiale” o di un
>"nome locale ma preferito” [1]. Se la definizione non è precisa, allora
>andrebbe corretta.
>
>[1] https://wiki.openstreetmap.org/wiki/IT:Key:alt_name 
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

--
I❤️ Software Libero.

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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:17 AM Mateusz Konieczny 
wrote:

> I reformatted
> https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
> https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
> (added templates making them machine readable, descriptions will appear
> for example at Taginfo)
>

Thank you, documentation of the tags imported previously has definitely
been lacking


> Is it useful to use both? What is the difference between them?
> Is NaptanCode actually used as planned ("referring to the stop in public
> facing systems")?
>

Of this I'm personally unsure, however there's not much harm in it and it
seems standard enough practise


> It may help to include example (of full) .osm data file to make easy for
> mappers
> to judge data quality in their area.
>

Here is a single file with all stops which I would be importing for the
Aberdeen area (
https://drive.google.com/open?id=1_QWn02Gi0YG8GCza0CeNQXtIKM_J82Y0), if
split into subdivisions there are 63 areas in total within this.


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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Stuart Reynolds]

Yes, both are still in use

AtcoCode is the unique “ID” of the bus stop and is the key that is used in 
databases to identify the stop. It is therefore also the key that gets used in 
an AnnotatedStopRef within the TransXChange (timetable) data.

NaptanCode is, in my view, unhelpfully named because in a NaPTAN database you 
would tend to think of it as the key. But it isn’t. It is certainly unique, but 
it has some constraints around which characters can follow other characters so 
that on (very old style, now) phones you didn’t have to push the same button 
twice in succession (and actually using a combination of letters that use the 
same key sequence also works). By and large it is text (except in Scotland, if 
I recall, where it is numeric) and is the code that you would send to the 
(charged for) 84628 “next departures” SMS service (Nextbuses). You can also use 
it online at nextbuses.mobi for free, although there you can also use the 
AtcoCode, confusingly.

For example, Southend Travel Centre stop A has the AtcoCode 15800720 (158 is 
the Southend prefix) and the NaptanCode soadjdaw (where soa is the Southend 
prefix). The next departures can be seen using  
http://nextbuses.mobi/WebView/BusStopSearch/BusStopSearchResults/soadjdaw

Both the SMS and Nexbuses services are still active, and not planned to be 
turned off any time soon.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 5 Jul 2019, at 10:27, Gareth L mailto:o...@live.co.uk>> 
wrote:

I’m certain I’ve seen “text this bus stop code to see next departures” use the 
naptan code. Whether or not that service is still live, I dunno.

On 5 Jul 2019, at 10:17, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


5 Jul 2019, 09:04 by silentspike...@gmail.com:

 *   `naptan:AtcoCode=*` [Imported]
 *   `naptan:NaptanCode=*` [Imported]

I reformatted
https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
(added templates making them machine readable, descriptions will appear
for example at Taginfo)

Is it useful to use both? What is the difference between them?
Is NaptanCode actually used as planned ("referring to the stop in public facing 
systems")?

Alternatively, if you support the proposal then it's also useful to know 

It may help to include example (of full) .osm data file to make easy for mappers
to judge data quality in their area.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

Frédéric Rodrigo-2 wrote
>> Et là, je suis sûr que tu vas me dire que je peux faire les 2 premières
>> étape en une seule ligne de commande...
> 
> Oui , même les trois ;-)

Et bien vas-y, dis-nous comment on fait ça...
Pas besoin du 3ème car il va disparaître.


Frédéric Rodrigo-2 wrote
>> Après j'ai testé les 3 outils et osm2pgsql est l'outil qui se rapproche
>> le
>> plus de mes besoins.
> 
> Mais la question est plutôt là. Osmosis et imposm peuvent aussi charger 
> en base de données. Avec des schémas différents.
> 
> osm2pgsql et imposm sont plus orientés rendu de carte et osmosis donnés 
> brutes. Mais tu peux aussi reconstruire les linestring et relations avec 
> Osmosis.

Je crois que le problème était que je n'avais même pas réussi à installer
imposm3.



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[石野貴之]

Thank you for the responce.

To Joseph:
> Survey would still be needed, because website information can be wrong
> or out-of-date. Even if website data is allowed, in-person survey is
> the "gold standard", best practice.

I totally agree. Mapping without survey is regarded as an "import" and
should be followed by the import guideline.

To Mateusz:

- facts are not copyrightable and from copyright view it does not matter
> whatever
> one copied information from opening hours sign or from website
> - collections of facts may have copyright or copyright like restrictions,
> copying
> phone book or all branches of $CORPORATION may be not OK
> - copying collections of facts is not OK also when distributed among many
> people
> (that is why Wikidata is problematic - copying database one fact at time
> is not removing
> sui generis database rights)
>

That's right.  I understand copying collections of facts is a problematic
action over sui generis database right.
https://en.wikipedia.org/wiki/Sui_generis_database_right

I am sure that mapping opening hours, name etc from signs is OK.
>

We all agree with this. However, some of us don't like the idea

I am sure that mapping opening hours, name etc from website of individual
> business is OK.
>

because it would be unfair if websites of small business are allowed and
those of large comanies are not.

I am sure that "we would able to map POIs without surveying on the ground
> at all" does not
> matter as far as copyright status of such data is concerned.
>

Yeah, it's not a violation of laws or licences " as far as copyright
status" is concerned. But it may cause a problem
when it comes to database rights and other rights. Thus we need a new
guideline not to violate these rights.

Thank you.

Takayuki Ishino (user: yumean1119)
yumean1...@gmail.com

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Frédéric Rodrigo]

Le 05/07/2019 à 11:13, Tony Emery via Talk-fr a écrit :

Alors, je vais essayer de n'oublier personne.

=> marc marc : je suppose que j'utilise l'extraction publique puisque dans
mon script, j'ai mis :
wget
http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf
-O $OSM_DEST_FOLDER/paca.osm.pbf
Mais je ne sais pas comment faire pour passer par l'extraction privée dans
mon script.
Je comprends pour user et uid, mais du coup, pourquoi je n'ai même plus le
timestamp ?

=> Olivier : Je récupère la colonne hstore via l'option -j|--hstore-all :
"Add all tags to an additional hstore (key/value) column in PostgreSQL
tables"

=> Frédéric : j'utilise osmosis pour 3 choses :
1- Fusionner mes 3 régions géofabrik (paca, languedoc-roussillon et
rhône-alpes) :
/usr/bin/osmosis --rb $OSM_DEST_FOLDER/paca.osm.pbf --rb
$OSM_DEST_FOLDER/lr.osm.pbf --rb $OSM_DEST_FOLDER/ra.osm.pbf --merge --merge
--wb $OSM_DEST_FOLDER/regions.osm.pbf
2- Extraire de cette fusion une emprise qui sera plus facilement gérable :
/usr/bin/osmosis --rb $OSM_DEST_FOLDER/regions.osm.pbf --bounding-box
top=44.3 left=4.6 bottom=43.9 right=5.0 completeWays=yes
completeRelations=yes --wb $OSM_DEST_FOLDER/ccpro.osm.pbf
3- Pour avoir une version du fichier précédent au format .osm afin qu'il
soit exploité par une autre application : /usr/bin/osmosis --rb
$OSM_DEST_FOLDER/ccpro.osm.pbf --wx $OSM_PUBLIC_FOLDER/ccpro.osm
Ce point 3 est temporaire et dès que ma chaine fonctionnera correctement, je
n'en aurait plus besoin.

Et là, je suis sûr que tu vas me dire que je peux faire les 2 premières
étape en une seule ligne de commande...


Oui , même les trois ;-)



Après j'ai testé les 3 outils et osm2pgsql est l'outil qui se rapproche le
plus de mes besoins.


Mais la question est plutôt là. Osmosis et imposm peuvent aussi charger 
en base de données. Avec des schémas différents.


osm2pgsql et imposm sont plus orientés rendu de carte et osmosis donnés 
brutes. Mais tu peux aussi reconstruire les linestring et relations avec 
Osmosis.




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

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Gareth L]

I’m certain I’ve seen “text this bus stop code to see next departures” use the 
naptan code. Whether or not that service is still live, I dunno.

On 5 Jul 2019, at 10:17, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


5 Jul 2019, 09:04 by silentspike...@gmail.com:

 *   `naptan:AtcoCode=*` [Imported]
 *   `naptan:NaptanCode=*` [Imported]

I reformatted
https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
(added templates making them machine readable, descriptions will appear
for example at Taginfo)

Is it useful to use both? What is the difference between them?
Is NaptanCode actually used as planned ("referring to the stop in public facing 
systems")?

Alternatively, if you support the proposal then it's also useful to know 

It may help to include example (of full) .osm data file to make easy for mappers
to judge data quality in their area.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Leroy Olivier]

Si tu passes par OSM France tu as les métadonnées (je viens de vérifier,
sur un wget  datant de  dimanche dernier).

Du coup j'ai ouvert un rapide post sur le forum :
https://forum.openstreetmap.fr/viewtopic.php?f=5=7221

Mais je ne sais pas comment faire pour passer par l'extraction privée dans
> mon script.
>

Moi non plus et cela m'intéresse.

J'avais aussi regarder osmosis mais n'avait pas assez bien capter pour
utiliser.

Je récupère la colonne hstore via l'option -j|--hstore-all
>

Ah pardon je l'avais pas vu avant.

Olivier

Le ven. 5 juil. 2019 à 11:14, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Alors, je vais essayer de n'oublier personne.
>
> => marc marc : je suppose que j'utilise l'extraction publique puisque dans
> mon script, j'ai mis :
> wget
>
> http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf
> -O
> 
> $OSM_DEST_FOLDER/paca.osm.pbf
> Mais je ne sais pas comment faire pour passer par l'extraction privée dans
> mon script.
> Je comprends pour user et uid, mais du coup, pourquoi je n'ai même plus le
> timestamp ?
>
> => Olivier : Je récupère la colonne hstore via l'option -j|--hstore-all :
> "Add all tags to an additional hstore (key/value) column in PostgreSQL
> tables"
>
> => Frédéric : j'utilise osmosis pour 3 choses :
> 1- Fusionner mes 3 régions géofabrik (paca, languedoc-roussillon et
> rhône-alpes) :
> /usr/bin/osmosis --rb $OSM_DEST_FOLDER/paca.osm.pbf --rb
> $OSM_DEST_FOLDER/lr.osm.pbf --rb $OSM_DEST_FOLDER/ra.osm.pbf --merge
> --merge
> --wb $OSM_DEST_FOLDER/regions.osm.pbf
> 2- Extraire de cette fusion une emprise qui sera plus facilement gérable :
> /usr/bin/osmosis --rb $OSM_DEST_FOLDER/regions.osm.pbf --bounding-box
> top=44.3 left=4.6 bottom=43.9 right=5.0 completeWays=yes
> completeRelations=yes --wb $OSM_DEST_FOLDER/ccpro.osm.pbf
> 3- Pour avoir une version du fichier précédent au format .osm afin qu'il
> soit exploité par une autre application : /usr/bin/osmosis --rb
> $OSM_DEST_FOLDER/ccpro.osm.pbf --wx $OSM_PUBLIC_FOLDER/ccpro.osm
> Ce point 3 est temporaire et dès que ma chaine fonctionnera correctement,
> je
> n'en aurait plus besoin.
>
> Et là, je suis sûr que tu vas me dire que je peux faire les 2 premières
> étape en une seule ligne de commande...
>
> Après j'ai testé les 3 outils et osm2pgsql est l'outil qui se rapproche le
> plus de mes besoins.
>
>
>
>
>
> -
> Tony EMERY
> OpenStreetMap.fr
> Ingénieur SIG
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

Alors, je vais essayer de n'oublier personne.

=> marc marc : je suppose que j'utilise l'extraction publique puisque dans
mon script, j'ai mis :
wget
http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf
-O $OSM_DEST_FOLDER/paca.osm.pbf
Mais je ne sais pas comment faire pour passer par l'extraction privée dans
mon script.
Je comprends pour user et uid, mais du coup, pourquoi je n'ai même plus le
timestamp ?

=> Olivier : Je récupère la colonne hstore via l'option -j|--hstore-all :
"Add all tags to an additional hstore (key/value) column in PostgreSQL
tables"

=> Frédéric : j'utilise osmosis pour 3 choses :
1- Fusionner mes 3 régions géofabrik (paca, languedoc-roussillon et
rhône-alpes) :
/usr/bin/osmosis --rb $OSM_DEST_FOLDER/paca.osm.pbf --rb
$OSM_DEST_FOLDER/lr.osm.pbf --rb $OSM_DEST_FOLDER/ra.osm.pbf --merge --merge
--wb $OSM_DEST_FOLDER/regions.osm.pbf
2- Extraire de cette fusion une emprise qui sera plus facilement gérable :
/usr/bin/osmosis --rb $OSM_DEST_FOLDER/regions.osm.pbf --bounding-box
top=44.3 left=4.6 bottom=43.9 right=5.0 completeWays=yes
completeRelations=yes --wb $OSM_DEST_FOLDER/ccpro.osm.pbf
3- Pour avoir une version du fichier précédent au format .osm afin qu'il
soit exploité par une autre application : /usr/bin/osmosis --rb
$OSM_DEST_FOLDER/ccpro.osm.pbf --wx $OSM_PUBLIC_FOLDER/ccpro.osm
Ce point 3 est temporaire et dès que ma chaine fonctionnera correctement, je
n'en aurait plus besoin.

Et là, je suis sûr que tu vas me dire que je peux faire les 2 premières
étape en une seule ligne de commande...

Après j'ai testé les 3 outils et osm2pgsql est l'outil qui se rapproche le
plus de mes besoins.





-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-ja] 農水省の筆ポリゴンのインポート許可がおりました

[Ryosuke Amano]

横浜のあまのです。

〉作業ワークフローについて

質問1
3.もとのファイルどおり市町村単位が理想ですが、平成の大合併で広大になった市町村も多いので、一部の小規模な市町村以外は、1.町丁目単位(ないしは旧市町村単位、地域地区単位、大字単位など)が現実的なのかと思います。

質問2
候補地として、神奈川県大和市や東京都調布市が上がっていますが、元ファイルの市町村間の接合をみるために、隣接市町村も１つ２つ入れてみてはどうでしょうか？
大和市だと綾瀬市が、調布市だと府中市とか三鷹市などが、広さもソコソコで農地もあっていいのかな、と思います。

On 2019年7月5日 16:48:25 JST, Satoshi IIDA  wrote:
>いいだです。
>先程、農水省から、IDつきデータのダウンロードページが公開されました。
>国土数値情報のように、アンケートを答えた後にDLすることができます。
>（利用規約はほぼ変わっていませんので、再配布など可能です）
>
>https://www.contactus.maff.go.jp/j/form/tokei/seiryu/hudeporianke-to.html
>
>僕はちょうどDLおわったところで、これから内容を検分します。
>
>また、特に作業に対する反対意見はないようですので、前に進めたいと思います。（ありがとうございます！）
>そして、ライセンスに関しては長期的に揉めるところだと思いますので、
>Imports MLのほうにも早めに一報する予定です。
>
>> 浅野さん、岩崎さん（Tomさんも？）
>Githubのページで、進め方を検討しようと思っています。
>ついては、ProjectのTeamへの追加を行いたいです。
>
>浅野さん＞Githubのアカウントはお持ちですか？ また、無い場合作成は可能でしょうか
>岩崎さん＞こちらのアカウントをInviteさせてください https://github.com/wata909
>
>まぁ実際のところ、Issueに書き込むこととかはTeamに参加していなくてもできるので、
>なんかこう、チームとして顔が見えてるといいよね、というくらいの感覚です。
>無理強いするものではありませんです。
>
>> 作業ワークフローについて
>2つほど、意見を聞きたいです。
>
>質問1. ファイルの単位について
>基本的にファイルは、市町村の単位で作成されています。
>ただ、実際の作業にあたって、1つの市町村を1つの変更セットで作業することは、非常に手間が大きいと思っています。
>
>なので、いくつかのファイルに分割したほうがよいのではないかと思っています。
>どれがよいでしょう？
>
>1. 町丁目単位（あるいはestatの小区域単位）で分割
>2. 地域メッシュなど、なにかしらのメッシュ単位で分割
>3. もとのファイルどおり、市町村単位で作業
>
>なお、複数人で作業になるので、Tasking Managerを使ってインポート＆確認作業をすることを考えていたのですが、
>タスク選択後、対象地域の.osmファイルを適切に拾ってくることができるのかなぁ、というのが課題です。
>いくつかのインポート作業の際に、どうしていたのか、諸外国のインポート作業Wikiをあさっています。
>うまいやりかたをご存知のかたがいたら教えてください。
>
>質問2. 対象地域の選定
>まずはいくつかの地域で、テスト的に作業を実施できる市町村を探しています。
>「うちの地域でやってみませんか」というところがありましたら、お声がけください。
>古橋さんのゼミの方からお手伝いしたい、という申し出をいただいていて、
>埼玉県横瀬町、神奈川県大和市、東京都調布市、あたりはどうでしょう？という話があります。
>合計で2−3くらいあるといいな、と思っています。
>
>農地があまり多くない都市圏、かつ既存データの位置精度が高めだと、作業しやすい印象です。

-- 
K-9 Mail で Android デバイスから送信しました。簡単で申し訳ありません。

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

Re: [OSM-talk] [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Mateusz Konieczny]

5 Jul 2019, 05:22 by yumean1...@gmail.com:

> The main point at issue is whether we are allowed to use official websites 
> that provide primary information or not.
> Some of us think that we can use data from official websites unless it is 
> prohibited by their term of service.
>
I am not a lawyer, please correct me if I am wrong:
- facts are not copyrightable and from copyright view it does not matter 
whatever
one copied information from opening hours sign or from website
- collections of facts may have copyright or copyright like restrictions, 
copying
phone book or all branches of $CORPORATION may be not OK
- copying collections of facts is not OK also when distributed among many people
(that is why Wikidata is problematic - copying database one fact at time is not 
removing
sui generis database rights)

> is also against using official websites. His opinion is that we would able to 
> map POIs without surveying on the ground at all
> if it was OK to use data from websites. 
> (example: > 
> https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html 
> >  )
>
1) Some survey is necessary to check whatever data is trustworthy and up to date
2) Even if true it would not influence copyright status of such data
3) Imports (mapping POIs without surveying) is acceptable in case of good data 
on a suitable
license and following import guidelines and there are cases of succesfull and 
useful imports
doing this.

> What do you think about the issue?
>
I am sure that mapping opening hours, name etc from signs is OK.
I am sure that mapping opening hours, name etc from website of individual 
business is OK.
I am sure that "we would able to map POIs without surveying on the ground at 
all" does not
matter as far as copyright status of such data is concerned.

I am not sure is it OK to systematically copy such data from website that is 
basically a database.
I am not sure is it OK to systematically copy such data from website that is 
basically a database,
with individuals copying one fact at time.

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

Re: [OSM-legal-talk] Proposal for a revision of JA:Available Data

[Mateusz Konieczny]

5 Jul 2019, 05:22 by yumean1...@gmail.com:

> The main point at issue is whether we are allowed to use official websites 
> that provide primary information or not.
> Some of us think that we can use data from official websites unless it is 
> prohibited by their term of service.
>
I am not a lawyer, please correct me if I am wrong:
- facts are not copyrightable and from copyright view it does not matter 
whatever
one copied information from opening hours sign or from website
- collections of facts may have copyright or copyright like restrictions, 
copying
phone book or all branches of $CORPORATION may be not OK
- copying collections of facts is not OK also when distributed among many people
(that is why Wikidata is problematic - copying database one fact at time is not 
removing
sui generis database rights)

> is also against using official websites. His opinion is that we would able to 
> map POIs without surveying on the ground at all
> if it was OK to use data from websites. 
> (example: > 
> https://lists.openstreetmap.org/pipermail/talk-ja/2019-June/010604.html 
> >  )
>
1) Some survey is necessary to check whatever data is trustworthy and up to date
2) Even if true it would not influence copyright status of such data
3) Imports (mapping POIs without surveying) is acceptable in case of good data 
on a suitable
license and following import guidelines and there are cases of succesfull and 
useful imports
doing this.

> What do you think about the issue?
>
I am sure that mapping opening hours, name etc from signs is OK.
I am sure that mapping opening hours, name etc from website of individual 
business is OK.
I am sure that "we would able to map POIs without surveying on the ground at 
all" does not
matter as far as copyright status of such data is concerned.

I am not sure is it OK to systematically copy such data from website that is 
basically a database.
I am not sure is it OK to systematically copy such data from website that is 
basically a database,
with individuals copying one fact at time.

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Frédéric Rodrigo]

Le 05/07/2019 à 09:02, Tony Emery via Talk-fr a écrit :

Bonjour à tous,

Je me suis mis à utiliser osmose/osm2pgsql dans mon circuit d'intégration
des données et je rencontre 2 difficultés.

la première est que les attributs des métadonnées (osm_user, osm_uid,
osm_changeset et osm_timestamps) ne remontent pas dans les tables.

la deuxième est que j'ai l'impression qu'une partie des relations n'est pas
traité dans la moulinette.

Est-ce que vous avez déjà rencontré ce problème et comment le solutionner ?

Avant d'aller plus loin regarde si c'est bien de osm2pgsql que tu as 
besoin et pas de osmosis ou de imposm3 ?



Frédéric.



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

Re: [Talk-it] Mapping campi rom

[Andrea Albani]

Il giorno gio 4 lug 2019 alle ore 21:26 Andrea Musuruane 
ha scritto:

> Ciao,
>
> On Thu, Jul 4, 2019 at 9:17 PM Francesco Ansanelli 
> wrote:
>
>> Buonasera Lista,
>>
>> vorrei sapere se avete già mappato campi rom e quali tag avete utilizzato.
>> Ho fatto alcune ricerche su OSM e condivido l'idea di mettere
>> "landuse=residential", es:
>> https://www.openstreetmap.org/way/211772563
>> https://www.openstreetmap.org/way/338456215
>>
>> però non mi piace identificarli mediante il mero tag name.
>> C'è chi ha messo "residential=halting_site" come suggerito dal Wiki
>> francese:
>> https://wiki.openstreetmap.org/wiki/Tag:residential%3Dhalting_site
>> es:
>> https://www.openstreetmap.org/way/595179726
>>
>
> Concordo sull'uso di landuse=residential + residential=halting_site.
>
> Ciao,
>
> Andrea
>
>
Quoto Andrea M.
Stiamo parlando infatti di un'area di terreno, a volte attrezzata, a volte
no, e l'uso di residential=halting_site mi sembra una buona
generalizzazione per evitare la frammentazione del dato.
Il tag è già usato 695 volte, prevalentemente in Francia dove è stato
"inventato", e fa riferimento al termine amministrativo francese "Gens du
voyage" che comprende i gruppi etnici che normalmente occupano queste aree
anche in Italia [1].
Mi sembrano siano buoni presupposti per riusare il termine.

La proposta building=static_caravan non fa riferimento all'area, ma ad un
elemento su di essa che uno può liberamente mappare.

Sinceramente anche la proposta di Federico non mi soddisfa appieno perchè
in base alla wiki:
- una amenity=social_facility [2] è "... any place where social services
are conducted "... ma in un campo rom sono forniti servizi sociali ? o
meglio è fatto per fornire servizi sociali ?
- social_facility=shelter [3] è definito come "A facility that provides
temporary sleeping facilities or refuge from exposure to the environment "
che fa pensare ad una struttura organizzata di terzi che fornisce servizi,
ma in modo temporaneo (esempio: dormitorio per persone senza tetto)
- social_facility:for=migrant [4] parla di "Those who have migrated from
another country or region " che mi sembra più appropriato per gente che
fugge dal proprio paese invece che ai gruppi etnici che risiedono in Italia
direi da tempo immemore, ma che per loro cultura si muovono

Ciao

[1] https://fr.wikipedia.org/wiki/Gens_du_voyage
[2] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dsocial_facility
[3] https://wiki.openstreetmap.org/wiki/Key:social_facility
[4] https://wiki.openstreetmap.org/wiki/Key:social_facility:for
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Leroy Olivier]

> Elle fait quoi de particulier l'option "--multi-geometry" ?
>

Si j'en crois le wiki (https://wiki.openstreetmap.org/wiki/Osm2pgsql) elle
prend en charge les objets avec des multi-geometries (j'ai assumé que
c’était plusieurs géométries pour un objet, c'est pas courant mais je me
suis dit que cela pouvait exister dans OSM). Je pense pas que cela soit ton
problème (sauf si je me trompe sur ce qu'est une "multi geometry").

Tu prends pas non plus la colonne hstore (--hstore) ?

Si je dis pas de bêtise dans geofabrik par défaut tu n'as pas accès
osm_user, osm_uid, osm_changeset et osm_timestamps il faut être authentifié
via OAuth (on m'a suggéré que c’était en lien avec la réglementation
allemande).

>
> la deuxième est que j'ai l'impression qu'une partie des relations n'est
> pas traité dans la moulinette.
>

Ici je peux pas trop t'aider.

Olivier

Le ven. 5 juil. 2019 à 09:43, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> J'utilise Géofabrik avec cette commande :
> /usr/bin/osm2pgsql --slim --create -C 1500 --number-processes 4
> $OSM_DEST_FOLDER/ccpro.osm.pbf -p habillage_osm -E 2154 -j -d openstreetmap
> -U postgres --extra-attributes -S $OSM_DEST_FOLDER/ccpro_osm2pgsql.style
>
> Et, par exemple pour un noeud, j'ai ça :
> {osm_version,3,osm_changeset,0,osm_uid,0,osm_user,""}
>
> Dans le fichier de style, j'ai ça :
> node,wayosm_usertextlinear  #tous
> node,wayosm_uid integer linear  #tous
> node,wayosm_version integer linear  #tous
> node,wayosm_changeset   integer linear  #tous
> node,wayosm_timestamp   timestamptz(0)  linear  #tous
> node,wayz_order int4linear  #tous
> way way_areareallinear  #tous
>
> Mais je n'ai rien modifié à ce niveau je crois.
>
> Elle fait quoi de particulier l'option "--multi-geometry" ?
>
>
>
> -
> Tony EMERY
> OpenStreetMap.fr
> Ingénieur SIG
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[marc marc]

Le 05.07.19 à 09:42, Tony Emery via Talk-fr a écrit :
> J'utilise Géofabrik

extract public ou celui privé après authentification osm ?
car l'extract public n'a plus les meta-donnée grace à la RGPD
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-ja] 農水省の筆ポリゴンのインポート許可がおりました

[Satoshi IIDA]

いいだです。
先程、農水省から、IDつきデータのダウンロードページが公開されました。
国土数値情報のように、アンケートを答えた後にDLすることができます。
（利用規約はほぼ変わっていませんので、再配布など可能です）

https://www.contactus.maff.go.jp/j/form/tokei/seiryu/hudeporianke-to.html

僕はちょうどDLおわったところで、これから内容を検分します。

また、特に作業に対する反対意見はないようですので、前に進めたいと思います。（ありがとうございます！）
そして、ライセンスに関しては長期的に揉めるところだと思いますので、
Imports MLのほうにも早めに一報する予定です。

> 浅野さん、岩崎さん（Tomさんも？）
Githubのページで、進め方を検討しようと思っています。
ついては、ProjectのTeamへの追加を行いたいです。

浅野さん＞Githubのアカウントはお持ちですか？ また、無い場合作成は可能でしょうか
岩崎さん＞こちらのアカウントをInviteさせてください https://github.com/wata909

まぁ実際のところ、Issueに書き込むこととかはTeamに参加していなくてもできるので、
なんかこう、チームとして顔が見えてるといいよね、というくらいの感覚です。
無理強いするものではありませんです。

> 作業ワークフローについて
2つほど、意見を聞きたいです。

質問1. ファイルの単位について
基本的にファイルは、市町村の単位で作成されています。
ただ、実際の作業にあたって、1つの市町村を1つの変更セットで作業することは、非常に手間が大きいと思っています。

なので、いくつかのファイルに分割したほうがよいのではないかと思っています。
どれがよいでしょう？

1. 町丁目単位（あるいはestatの小区域単位）で分割
2. 地域メッシュなど、なにかしらのメッシュ単位で分割
3. もとのファイルどおり、市町村単位で作業

なお、複数人で作業になるので、Tasking Managerを使ってインポート＆確認作業をすることを考えていたのですが、
タスク選択後、対象地域の.osmファイルを適切に拾ってくることができるのかなぁ、というのが課題です。
いくつかのインポート作業の際に、どうしていたのか、諸外国のインポート作業Wikiをあさっています。
うまいやりかたをご存知のかたがいたら教えてください。

質問2. 対象地域の選定
まずはいくつかの地域で、テスト的に作業を実施できる市町村を探しています。
「うちの地域でやってみませんか」というところがありましたら、お声がけください。
古橋さんのゼミの方からお手伝いしたい、という申し出をいただいていて、
埼玉県横瀬町、神奈川県大和市、東京都調布市、あたりはどうでしょう？という話があります。
合計で2−3くらいあるといいな、と思っています。

農地があまり多くない都市圏、かつ既存データの位置精度が高めだと、作業しやすい印象です。


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

J'utilise Géofabrik avec cette commande :
/usr/bin/osm2pgsql --slim --create -C 1500 --number-processes 4
$OSM_DEST_FOLDER/ccpro.osm.pbf -p habillage_osm -E 2154 -j -d openstreetmap
-U postgres --extra-attributes -S $OSM_DEST_FOLDER/ccpro_osm2pgsql.style

Et, par exemple pour un noeud, j'ai ça :
{osm_version,3,osm_changeset,0,osm_uid,0,osm_user,""}

Dans le fichier de style, j'ai ça :
node,wayosm_usertextlinear  #tous
node,wayosm_uid integer linear  #tous
node,wayosm_version integer linear  #tous
node,wayosm_changeset   integer linear  #tous
node,wayosm_timestamp   timestamptz(0)  linear  #tous
node,wayz_order int4linear  #tous
way way_areareallinear  #tous

Mais je n'ai rien modifié à ce niveau je crois.

Elle fait quoi de particulier l'option "--multi-geometry" ?



-
Tony EMERY
OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] osm2pgsql : métadonnées et relations

[Leroy Olivier]

Hello,

Tu utilises quoi comme source (geofrabrik / osm france ?) ? Tu as bien mis
--extra-attributes  ?

A titre d'exemple voici ma commande :

osm2pgsql -v -c -d $DB --slim --cache 8000 --number-processes 2 --hstore
--extra-attributes --multi-geometry /osm_maj_auto/osm_dl/$ETENDUE.osm.pbf
-H localhost -P $PORT -U postgres >> /osm_maj_auto/osm_dl/$JOURNAL

Olivier

Le ven. 5 juil. 2019 à 09:02, Tony Emery via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour à tous,
>
> Je me suis mis à utiliser osmose/osm2pgsql dans mon circuit d'intégration
> des données et je rencontre 2 difficultés.
>
> la première est que les attributs des métadonnées (osm_user, osm_uid,
> osm_changeset et osm_timestamps) ne remontent pas dans les tables.
>
> la deuxième est que j'ai l'impression qu'une partie des relations n'est pas
> traité dans la moulinette.
>
> Est-ce que vous avez déjà rencontré ce problème et comment le solutionner ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Ingénieur SIG
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS ANR Rêveries 
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

[lenny.libre]

Le 05/07/2019 à 08:10, Topographe Fou a écrit :
J'ai encore un soucis de timeout... J'avais réussi à y accéder entre 
temps. Peux-tu mettre sur la liste la phrase originale en anglais stp, 
celle avec les {x} ? Normalement si tu as les mêmes accolades entre 
l'original et le traduit cela devrait passer.


original anglais  :

Which way segment should reuse the history of {0}?

ma traduction :

Quel segment de chemin doit réutiliser l'historique de {0} ?

J'ai utilisé le bouton copie (la petite flèche à côté de English:) donc, 
ce sont les mêmes accolades (il me semble) et ce matin même message d'erreur


Leni



LeTopographeFou
*De:* lenny.li...@orange.fr
*Envoyé:* 4 juillet 2019 12:08 PM
*À:* talk-fr@openstreetmap.org
*Répondre à:* talk-fr@openstreetmap.org
*Objet:* Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le 
chemin




Le 24/06/2019 à 22:35, LeTopographeFou a écrit :
Pour Launchpad, la liste des phrases non traduits (14 à ce jour pour 
le français) est accessible là : 
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated 
. Sauf que actuellement j'ai une erreur de Timeout :-( .


LeTopographeFou


Comme je ne l'ai pas trouvée dans les éléments à traduire, j'ai 
recherché le texte et j'ai trouvé : 
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=which+way

Elle était indiquée comme traduite, avec le texte anglais.

J'ai essayé de mettre une nouvelle traduction "Quel segment de chemin 
doit réutiliser l'historique de {0} ?" ; mais j'ai le message d'erreur 
"There is an error in a translation you provided. Please correct it 
before continuing."


Où ais-je fait l'erreur ?

Leni


___
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-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

Since the other thread has become a tagging discussion on the pros and cons
of PTv2, let's try this again.

Would there be any objections to an import of the following scope:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload using JOSM
   5. Split the edits up according to the "LocalityName" data field
   (basically districts)  [or is it better to be one changeset for the whole
   area?]



Using the following established tags:

   - `highway=bus_stop`
  - `public_transport=platform`
  - `bus=yes`
  - `name=*` [Imported]
  - `naptan:AtcoCode=*` [Imported]
  - `naptan:NaptanCode=*` [Imported]
  - `source=naptan`
  - `naptan:verified=no`

Alternatively, if you support the proposal then it's also useful to know 

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

Re: [talk-au] Path on sand/bare rock

[Andrew Davidson]

This seems to have been asked a few times before:

https://www.mail-archive.com/talk-au@openstreetmap.org/msg09528.html
https://www.mail-archive.com/talk-au@openstreetmap.org/msg11443.html
https://www.mail-archive.com/tagging@openstreetmap.org/msg41293.html
https://www.mail-archive.com/talk-us@openstreetmap.org/msg13183.html

On Thu, Jul 4, 2019 at 6:40 PM Ewen Hill  wrote:

> Hi,
>   On a corcular island with a sand/bare rock surface all the way around the
> outside, would you add a path?
>
> Now where a track might head down to the beach to cross a stream, it makes
> sense however should we infer a path where there is no man made assistance
> or guidance?
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Australia-f5416966.html
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] osm2pgsql : métadonnées et relations

[Tony Emery via Talk-fr]

Bonjour à tous,

Je me suis mis à utiliser osmose/osm2pgsql dans mon circuit d'intégration
des données et je rencontre 2 difficultés.

la première est que les attributs des métadonnées (osm_user, osm_uid,
osm_changeset et osm_timestamps) ne remontent pas dans les tables.

la deuxième est que j'ai l'impression qu'une partie des relations n'est pas
traité dans la moulinette.

Est-ce que vous avez déjà rencontré ce problème et comment le solutionner ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

[Tony Emery via Talk-fr]

Je n'arrive pas à comprendre pourquoi un giratoire ne pourrait pas contenir
de "ref" s'il appartient bien au tracé de la route qu'il coupe.
Sur l'argument de "on met quelle ref si les 2 routes qui se croisent en ont
toute les 2 ? ", je dirais que c'est comme pour la valeur de highway. Quand
2 routes de 2 types différents se croisent (primary et secondary par ex), on
met au giratoire la valeur de la route la plus importante.

De toute façon, la "ref" est définie dans l'arrêté de classement donc, si le
giratoire est inclu, il n'y a pas à tortiller...

Après, on pourrait mettre la clé ref sur la relation mais, là encore, il y a
de rares exceptions où une voie commence avec une ref et fini sans.

De notre côté, nous devons également gérer des ref "locale" de type VC et CR
sur des routes qui ont aussi des ref nationales. Du coup, j'utilise loc_ref
pour le premier. Mais ça, c'est un autre débat.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Ingénieur SIG
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

[Topographe Fou]

  J'ai encore un soucis de timeout... J'avais réussi à y accéder entre temps. Peux-tu mettre sur la liste la phrase originale en anglais stp, celle avec les {x} ? Normalement si tu as les mêmes accolades entre l'original et le traduit cela devrait passer.LeTopographeFou   De: lenny.li...@orange.frEnvoyé: 4 juillet 2019 12:08 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin  
Le 24/06/2019 à 22:35, LeTopographeFou
  a écrit :
Pour
  Launchpad, la liste des phrases non traduits (14 à ce jour pour le
  français) est accessible là :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated
  . Sauf que actuellement j'ai une erreur de Timeout :-( .
  
  
  LeTopographeFou
  
Comme je ne l'ai pas trouvée dans les éléments à traduire, j'ai
  recherché le texte et j'ai trouvé :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=which+way
  Elle était indiquée comme traduite, avec le texte anglais.J'ai essayé de mettre une nouvelle traduction "Quel segment de
  chemin doit réutiliser l'historique de {0} ?" ; mais j'ai le
  message d'erreur "There is an error in a
translation you provided. Please correct it before continuing."Où ais-je fait
  l'erreur ?Leni
  
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr