Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Richard Fairhurst]

[I'm going to break my rule of not posting to the mailing lists for this,
because it's an interesting query and important for OSM. Since I started
writing this, Robert has made an excellent posting which covers much of the
same ground and comes to related conclusions, but from a slightly different
angle]

Alex Barth wrote:
 I just updated the Wiki with a proposed community guideline
 on geocoding.

 In a nutshell: geocoding with OSM data yields Produced Work, 
 share alike does not apply to Produced Work, other ODbL 
 stipulations such as attribution do apply. The goal is to 
 remove all uncertainties around geocoding

This is an interesting approach and one that I think has potential, but
perhaps in a different form from that proposed.

I find it difficult to square geocoding results always being a Produced Work
with the text of the ODbL. In the medium term, we want complete address data
in major urban areas (those of highest commercial demand). This suggests
address data on every building object in the city.

Geocoding street addresses against such a dataset (the 90% case) is
essentially a clever lookup function: it is extracting raw OSM data (lat/lon
pairs) from the database via a query, and then not doing any significant
transformative work on the lat/lon pairs. That is ODbL's definition of a
Derivative Database, reinforced by the option in 4.6.b of an algorithm...
that make[s] up all the differences between the Database and the Derivative
Database.

As Randy has alluded, geocoders are powerful tools which put much effort
into providing reliable results. To argue that this effort results in a
Produced Work, you would have to:

- agree that a collection of lat/lon pairs (the result of geocoding) is
analogous with the creative-world examples of image, audiovisual material,
text, or sounds, and
- agree that this holds true for a significant majority of geocoding
results, particularly with reference to that data which is likely to be
extracted (i.e. San Francisco more likely to be extracted than deepest
Idaho)

To me, those statements seem like a leap beyond what OSMF and the OSM
community would be comfortable to take right now.


However, despite this, I think the Produced Work angle is potentially a
promising avenue towards removing all uncertainties around geocoding.

Instead of a blanket and potentially problematic statement that geocoding
with OSM data yields Produced Work, we should focus on the next level down.
In other words, accept that data extracted from OSM by means of address
queries remains ODbL-licensed OSM data: but then look at what is done with
this data (how it is used), and whether this might be a Produced Work or a
Collective Database.

In particular, I would throw into the mix what Matt generously called the
Fairhurst Doctrine
(https://lists.openstreetmap.org/pipermail/legal-talk/2009-October/002881.html,
https://lists.openstreetmap.org/pipermail/legal-talk/2009-October/002911.html).
This argues that if you match ODbL data against third-party data by means of
a simple query, the table mapping ids from one to the other is not
qualitatively substantial: therefore the two datasets become a Collective
Database, in which the third-party data can be licensed any which way.

So let's try this with one of Alex's examples: the first one, in which the
store locations are being exposed to the public on a store locator map using
Bing maps.

If you reference the store addresses against OSM address data, following the
Fairhurst Doctrine, the result is a Collective Database: the address data in
OSM in one database, the store data in another, and a simple mapping between
the two (imagine it as a separate table for now). Therefore the store data
is not subject to ODbL.

There is one major question in this: whether geocoding is just a simple
query, or whether it's something big and difficult and complicated. The
latter is just another way of saying qualitatively substantial, which
would mean that the table mapping ids between the databases becomes
derivative, and the result can't be a Collective Database.

Again, this would be up to OSMF to decide in consultation with the
community. I'd personally argue that, more often than not, it's a simple
query. I don't mean any disrespect to Sarah and Brian, or Randy's geocoding
experts, or any of the other people working on geocoders. A 100% geocoder is
undoubtedly a ball of hurt. But taking the urban street example from above,
which are likely to be the majority of the queries thrown at a geocoder, it
remains at heart a predictable algorithmic translation of OSM data. Edge
cases are the hard part, and there are plenty of them, but edge cases are by
definition not substantial.

By looking at the use, and considering whether it counts as a Collective
Database or a Produced Work, we should be able to come up with clear answers
for all of the common geocoding use cases. Yes, there'll always be some
scenarios where it could go either way: that's inevitable when 

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Kai Krueger]

I thought I'd throw in my $0.02 into the discussion as well.

First of all, I think it is good that we are having this discussion and I
hope that eventually we can come to a OSMF sanction conclusion (set of
community guidelines) one way or another.

Overall, I think the route via produced works is the correct way to go here.

For reverse geocoding I think declaring things as produced work is pretty
well justified.

The process is to take a geographic coordinate as input. This input is then
turned, with the help of a bunch of complex algorithms(e.g. nominatum), into
a (textual) rendering of an extract of the openstreetmap data. This textual
rendering is then stored and eventually displayed to a human observer. 

This is nearly exactly equivalent to the process of rendering map tiles.
I.e. you take four geographic coordinates (bounding box) as input. This
input is then turned, with the help of a bunch of complex algorithms (e.g.
mapnik), into a (bitmap) rendering of an extract of the openstreetmap data.
This bitmap rendering is then stored and eventually displayed to a human
observer.

Given that map tiles are universally considered as produced works, so should
imho be the result of reverse geocoding. As such, this should then also not
trigger share-a-like.

Just like one could take a proprietary database, use the stored lat/lon
values in that database and render a 256x256 pixel image of the map for each
entry of the database and store it back into the proprietary database
without infecting the database with the ODbL share-a-like, one should be
able to do the same with reverse geocoding.

Imho anything that is intended for (more or less) direct consumption by
humans is a produced work. 

For forward geocoding, the picture gets a bit more murky though, as the
distinction between what is for human consumption and what is data, and thus
a derived database, is much less clear cut.

If you geocode an address and then all you do with the the resulting lat/lon
is to display it in some form, then that is imho clearly also a produced
work and thus shields things from the ODbL share-a-like requirement.

However, once you start manipulating and computing with those lat/lon
values. E.g. to calculate the average distance between all of the POIs in
your proprietary db, the definition of produced work probably starts
breaking down, because the output of the geocoding process is no longer the
end product.

Where exactly that line is though between produced work and derived
database, I am not sure is obvious, and thus the intention of making the
license clearer would unfortunately not really be achieved.


Generally, I would consider my self as a proponent of share-a-like, but at
least to me personally, I would consider all of the use cases presented in
the proposed community guidelines as acceptable and within the spirit of
share-a-like requirement for the OSM database. But it probably needs a bit
more explanation of what you can and cannot do with the derived lat/lon
values of the geocoding process.

Kai





--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811672.html
Sent from the Legal Talk mailing list archive at Nabble.com.

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

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Kai Krueger]

Robert Whittaker (OSM lists) wrote
 So the way I see it, if there's any (substantial) addition of external
 geo-data along the way, then that addition creates a derivative
 database, before the produced work is created. So if you want to
 publicly use this database (or any produced work based on it) then
 either the derivative database must be shared-alike, or the algorithm
 used to produce it and any additional input data must be shared.
 
 In the case of any substanitial amount of geocoding, you are clearly
 having to add additional geographic data to the OSM data in order to
 do the geocoding.

I would interpret it as quite the opposite and you are not adding any
substantial amount of geographical information.

You do query the db with external geo-data. But if the geocoder gives you a
result, the information was (in this form) already in the OSM database and
so you haven't added anything. If the data was not already in the OSM
database, then the geocoder will not spit out any result and thus you
haven't created any derived database (or anything else for that matter).

So in either case, the result(s) from the geocoding process are pure
OpenStreetMap data and there is no additional external geo-data added to the
output. Therefore this process then also does not trigger the share-a-like
clause in it self. And so as long as you don't use the resultant lat/lon in
a way incompatible with the definition of produced work, geocoding itself is
fine.




--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811673.html
Sent from the Legal Talk mailing list archive at Nabble.com.

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

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Frederik Ramm]

Hi,

On 07/17/2014 01:25 AM, Kai Krueger wrote:
 For forward geocoding, the picture gets a bit more murky though, as the
 distinction between what is for human consumption and what is data, and thus
 a derived database, is much less clear cut.

Indeed. If we were only talking about the enter your address here and
we'll zoom the map to your location use case, we'd never be creating
any database that contains OSM data in the first place.

 However, once you start manipulating and computing with those lat/lon
 values. E.g. to calculate the average distance between all of the POIs in
 your proprietary db,

I guess the most commercially interesting use case is: I have a bunch
of POIs or properties or client addresses and I want to be able to
compute, at any time, for a given lat/lon, which of these are in the
vicinity. The archetypal where's the nearest pizza place application
comes to mind. This requires augmenting my proprietary database with
lat/lons from OSM, else I would have to on-the-fly geocode half my
database every time I want to make a query which would be too expensive.

In your own distinction of is this for human consumption or for a
computer's, it is clearly for a computer's - since the coordinates form
the basis for filtering which items to display to the user. A human
wouldn't be able to sift through the list so quickly.

Bye
Frederik

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

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

Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014

[Stefan Keller]

Update from Stefano (many thanks!):
https://twitter.com/maps4thought/status/489388472063774720
Now it looks better!

-S.


2014-07-15 21:54 GMT+02:00 Christoph Hormann chris_horm...@gmx.de:

 On Tuesday 15 July 2014, Stefan Keller wrote:
 
  Which node density map by Martin Raifer do you mean?

 http://tyrasd.github.io/osm-node-density/

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

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

Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014

[Christoph Hormann]

On Wednesday 16 July 2014, Stefan Keller wrote:
 Update from Stefano (many thanks!):
 https://twitter.com/maps4thought/status/489388472063774720
 Now it looks better!

Yes that looks much more plausible.

Still the population data is quite strange - northern Quebec uninhabited 
and northern Greenland inhabited is a bit of a stretch...

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

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

Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014

[Paul Johnson]

Hah, you can obviously see a stretch from approximately Ponca City, OK and
Stillwater through Tulsa and Bartlesville and down to about I40 at Oologah
and Fort Smith, AR where I've done a lot of work over the last two years.
On Jul 15, 2014 7:17 AM, Stefan Keller sfkel...@gmail.com wrote:

 Interesting visualization about OpenStreetMap availability/coverage:
 Visualizing nodes per inhabitant worldwide.
 https://twitter.com/CiaranStaunton/status/488761438065156096
 (Source: S. De Sabbatta, Oxford Internet Institute, 2014,
 http://geography.oii.ox.ac.uk )
 Note: IMHO Diagram/color scheme has some potential to be enhanced.

 -S.

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


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

Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014

[Christian Quest]

Yet another OSM density dataviz... ;)

http://cl.ly/image/2f0y3K2b1Z1b

Instead of just taking nodes into account, I used an awfull* SELECT
count(*) query on osm2pgsql point and line tables.
It means that only nodes with some useful tags are showing up in the green
channel, and lines are showing up in the red channel.


* here it is: https://gist.github.com/cquest/d1734a71c3a4a18587fe



2014-07-16 16:10 GMT+02:00 Paul Johnson ba...@ursamundi.org:

 Hah, you can obviously see a stretch from approximately Ponca City, OK and
 Stillwater through Tulsa and Bartlesville and down to about I40 at Oologah
 and Fort Smith, AR where I've done a lot of work over the last two years.
 On Jul 15, 2014 7:17 AM, Stefan Keller sfkel...@gmail.com wrote:

 Interesting visualization about OpenStreetMap availability/coverage:
 Visualizing nodes per inhabitant worldwide.
 https://twitter.com/CiaranStaunton/status/488761438065156096
 (Source: S. De Sabbatta, Oxford Internet Institute, 2014,
 http://geography.oii.ox.ac.uk )
 Note: IMHO Diagram/color scheme has some potential to be enhanced.

 -S.

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


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




-- 
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Drop rendering of permissive access?

[Martin Koppenhoefer]

 Am 16/lug/2014 um 19:48 schrieb martyn i...@dynoyo.plus.com:
 
 So having them surveyed and mapped in OSM is a useful  addition to PROW data, 
 as information about them is not easy to find.


the plan is to remove the access restriction rendering, not the highway 
itself...
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tablet, OpenStreetMap, navigator

[Paul Johnson]

As a substitute to Google Maps:
https://play.google.com/store/apps/details?id=com.telenav.app.android.scout_ushl=en
As an OpenStreetMap swiss army knife:
https://play.google.com/store/apps/details?id=net.osmandhl=en


On Mon, Jul 14, 2014 at 1:42 AM, Kaare Rasmussen ka...@jasonic.dk wrote:

 Hi All

 I've tried and failed to find recent, up to date discussions or
 information on the use of OpenStreetMap with a tablet as a navigator.

 http://wiki.openstreetmap.org/wiki/Tablet_PC  is a rather outdated wiki
 page about how to use a tablet to collect OSM data
 http://wiki.openstreetmap.org/wiki/Android lists every application known
 to man. I guess I'd like to find a shortlist of recommendations, or a
 discussion of sorts.

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

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

Re: [OSM-talk] Drop rendering of permissive access?

[martyn]

Here in England and Wales, permissive footpaths and permissive 
bridleways are useful additions to the countryside access network. I 
recently discovered and mapped some that have been established by the 
organisation Natural England.  They are often used to link existing 
Public Rights of Way (PROWs), and extend access in areas with fewer 
PROWs.  They are not mapped on Ordnance Survey maps, probably due to 
their potential non-permanent status.  So having them surveyed and 
mapped in OSM is a useful  addition to PROW data, as information about 
them is not easy to find.


So please continue to render them if they are tagged as described in:
http://wiki.openstreetmap.org/wiki/UK_access_provisions

regards, Martyn

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

Re: [Talk-br] Posto Fiscal

[Nelson A. de Oliveira]

2014-07-16 2:23 GMT-03:00 A. Carlos anorcar...@hotmail.com:
 Alguém tem alguma dica de como se formata Posto De Fiscalização de ICMS
 (Rodovia) no OSM?

office=government
A general tag for the office of a government agency or department.
These are fully paid for by the government and completely controlled
by them, for example the taxation service, or Department of Primary
Industries. Use this where a suitable subtag doesn't yet exist or
isn't justified.

office=tax
Fiscal authorities, tax and revenue office

Eu usaria o último; apesar de não passar a ideia que é do governo, é
mais específico.

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

[Talk-de] Wochennotiz Nr. 208 8.7.–14.7.2014

[wn reader]

Hallo,

die Wochennotiz Nr. 208 mit allen wichtigen Neuigkeiten aus der 
OpenStreetMap Welt ist da:


http://blog.openstreetmap.de/blog/2014/07/wochennotiz-nr-208/

Viel Spaß beim Lesen!

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

[Talk-de] Wochenaufgabe: Geldautomat - War: Wochennotiz Nr. 208 8.7.–14.7.2014

[Alexander Lehner]

Danke erstmal fuer die woechentliche Zusammenfassung!

Zum Thema Geldautomat (Wochenaufgabe) faellt mir spontan ein:

Es gibt auch Geschaefte (Baeckereien, Tankstellen, Edeka's etc.) bei denen 
man Geld abheben kann. Beim Penny hab ich auch mal gesehen, dass man ab 
einem Einkauf ab 25EUR noch mit der EC Karte zusaetzlich Geld abheben 
kann.
In den USA gibt's das schon laenger, das nennt sich dort glaube ich 'cash 
back'.


Insbes. die 24h Tanken sind hier natuerlich interessant und eigentlich 
den Geldautomaten gleichzusetzen.


Der Baecker hat wiederum Oeffnungszeiten, ist aber nicht direkt eine Bank.

Und der Edeka hat eine Postbankfiliale, bei der man Bankkeschaefte 
abwickeln kann, aber eben nur von einem Postbank Girokonto Geld abheben 
kann.


Also waeren bei solchen Hybriden vielleicht mehrere POIs notwendig und die 
Angaben operator, opening_hours und atm/bank anzugeben...?


A.



On Wed, 16 Jul 2014, wn reader wrote:


Hallo,

die Wochennotiz Nr. 208 mit allen wichtigen Neuigkeiten aus der OpenStreetMap 
Welt ist da:


http://blog.openstreetmap.de/blog/2014/07/wochennotiz-nr-208/

Viel Spaß beim Lesen!

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

Re: [Talk-de] place=municipality für Gemeinden verwenden?

[Martin Koppenhoefer]

 Am 15/lug/2014 um 20:43 schrieb Tirkon tirko...@yahoo.de:
 
 Aber im Gegensatz zu einem Dorf hat eine Gemeinde (das war es, worum
 es mir in diesem Thread ging) analog zu den Stadtteilen auch
 (offizielle) Ortsteile. Mit welchem place-value sollte man 15 bis 20
 Kilometer durchmessende Gemeinden und deren einige Kilometer
 durchmessenden Ortsteile taggen?  


Die Wörter Gemeinde und offizieller Ortsteil scheinen mir in der Tat mehr 
zu Admin boundary zu passen, ob man dafür place zusätzlich verwenden will, kann 
man mal überlegen, tendenziell würde ich sagen, dass das unabhängig ist (wenn 
der Ortsteil z.B. ein Dorf ist, würde ich place=village verwenden)


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

Re: [Talk-de] Ortsteil im addr: namespace Re: place=municipality für Gemeinden verwenden?

[Martin Koppenhoefer]

 Am 15/lug/2014 um 22:03 schrieb 715371 osmu715...@gmx.de:
 
 Z.B. ist es keine useful
 combination die Bevölkerungszahl noch einmal am place-Knoten zu haben,
 wenn es an der Grenze bereits ist.


ja, an nodes ist der tag ein bisschen kritisch weil die Ausdehnung nicht klar 
ist


 Das führt nur zur doppelt-Zählung -
 ist aber hilfreich, solange es keine Grenzen in der OSM zu dem Ort gibt.


hm, Doppelzählung ist generell ein Thema (meint: einfach addieren geht sowieso 
nicht), sonst dürfte man population nur noch an einzelne Häuser oder Wohnungen 
machen, weil es ja üblich ist, dass eine administrative Einheit wieder in der 
nächstgrößeren auch ist


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

Re: [Talk-in] pincode and area mapping?

[Nagarjuna G]

On Tuesday 15 Jul 2014 2:14:53 AM Ravi Kumar wrote:
 Public schools in India, with pincode.. you need at least the location in
 Lat/Long.


 1. The following table helps in adding Lat/Long to the pincodes where ever
 pincodes match.

 http://pincode.datameet.org/download
 Populate your data to this for others to use.

 2. Then use the resultant table as input in Qgis (or gvSIG, OpenJump) make a
 shape file. 3. Use JOSM add the shape file,  and then upload to OSM.
 Cheers


Thanks so much Prateek, Naveen and Ravi.  I will first make a csv file with
schoolname, district, pincode. We will keep updating this with lat.long,
possibly from the above link given by Ravi.

After this I will attend to the challenge of shape files for each pincode area.
Initially we will keep the schools randomly around the lat/long,and then get
it corrected through some citizen science engagement.

--
GN


signature.asc
Description: This is a digitally signed message part.
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-in] pincode and area mapping?

[Ravi Kumar]

To make a shape file from Pincodes is a breeze in Qgis

http://www.slideshare.net/ravivundavalli/pincode2qgis

I have not covered how to save the result as a shape file.. or .. How to upload 
back to OSM
Cheers
Ravi Kumar

On Tuesday, July 15, 2014 3:14 PM, Ravi Kumar ravivundavall...@yahoo.com 
wrote:
 


Public schools in India, with pincode.. you need at least the location in 
Lat/Long.


1. The following table helps in adding Lat/Long to the pincodes where ever 
pincodes match.

http://pincode.datameet.org/download
Populate your data to this for others to use.

2. Then use the resultant table as input in Qgis (or gvSIG, OpenJump) make a 
shape file.
3. Use JOSM add the shape file,  and then upload to OSM.
Cheers



On Tuesday, July 15, 2014 3:00 AM, Naveen Francis navee...@gmail.com wrote:
 


Can you check this will work for you ?


http://post.gisserver.nic.in/




On 14 July 2014 03:17, Nagarjuna G nagar...@gnowledge.org wrote:

 
 
Do we have the area maps of the pincodes in India? 
 
We want to create a layer of public schools in India on OSM.  we have the data 
of schools (1.3 million schools).  We have only the postal address.  Can we 
place the schools through a script, given the address of the schools? 
 
--
GN
 
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in




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

[Talk-in] Information on Railway Station

[Shajeer]

There is data available here on Indian railway station. One thing I found 
missing is the station codes.

http://sims.railnet.gov.in/gis.htm
http://sims.railnet.gov.in/Software/ir_gis.zip
http://sims.railnet.gov.in/Software/Introduction.pdf

What are the thoughts on importing this.. There is no license info any where
In case we agree to use this, some of the stations are already marked on OSM. 
In that case how can we manage the duplicates?___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Help su multipoligoni... please!

[Max1234Ita]

Grazie per le risposte, e scusate se mi faccio vivo solo ora... avevo bisogno
di poter leggere con calma . :-)


Dunque, se ho ben capito, quello che conta è il tag della relation; io
credevo che il tag della relation dipendesse dal tagg degli oggetti
dichiarati come Outer. Forse questa era la causa dell'errore.
Provvedo a verificare gli altri errori simili che sono rimasti in zona.

Ciao e grazie ancora per l'aiuto!

MAx




--
View this message in context: 
http://gis.19327.n5.nabble.com/Help-su-multipoligoni-please-tp5810981p5811526.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Help su multipoligoni... please!

[Daniele Forsi]

Il 16 luglio 2014 09:41, Max1234Ita ha scritto:

 Dunque, se ho ben capito, quello che conta è il tag della relation; io
 credevo che il tag della relation dipendesse dal tagg degli oggetti
 dichiarati come Outer.

non è un problema di outer conto relazione, ma che keepright considera
che certi tag descrivono aree, quindi segnala errore se li trova su
nodi o way, e in quel caso l'outer preso singolarmente come way non
formava un'area mentre la formava una volta considerato nella
relazione insieme agli altri

-- 
Daniele Forsi

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

Re: [Talk-it] Mappare la Rotonda Antonelliana

[girarsi_liste]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Il 16/07/2014 00:23, Michele iw1gfv ha scritto:
 Vorrei mappare la Rotonda Antonelliana e la chiesa di
 Castellamonte. http://www.fctp.it/media///luoghi/10370_97860_1.jpg
 
 Le mura a cerchio dovevano essere la chiesa, ma i lavori non sono
 stati completati, ora queste mura cingono il piazzale antistante la
 chiesa.
 
 Secondo voi è corretto usare historic:monument ?
 
 


Il problema è che il tag historic crea un'area, o si aspetta ciò.

Taggherei gli edifici come historic, e il muro come barrier=wall, oppure

puoi crearti una relazione outer con multipoligono creando un'area
apposita che racchiuda edifici e muri, cioè unendo i nodi dell'area
creata con il perimetro esterno del tutto, e mettendo nel
multipoligono historic=monument, start_date=* (quando è stata fatta),
amenity=place_of_worship, denomination=catholic, religion=christian,
name=*, tourism=attraction.


Gli edifici e i muri non serve taggarli con historic, in quanto già
inteso nel multipoligono

- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlPGPJoACgkQoVS0hKoD3POEPQD+MJbV0PU2/fIKvpcmpQzWcVXf
IYVBdSkpYAbjLNDc/pIA/RFf6XvGfmVRqjGqVvYzLbKi8McLuvtK7tcEQkd1dQJh
=uFbn
-END PGP SIGNATURE-

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

Re: [Talk-it] Help su multipoligoni... please!

[girarsi_liste]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Il 16/07/2014 09:41, Max1234Ita ha scritto:
 Grazie per le risposte, e scusate se mi faccio vivo solo ora...
 avevo bisogno di poter leggere con calma . :-)
 
 
 Dunque, se ho ben capito, quello che conta è il tag della relation;
 io credevo che il tag della relation dipendesse dal tagg degli
 oggetti dichiarati come Outer. Forse questa era la causa
 dell'errore. Provvedo a verificare gli altri errori simili che sono
 rimasti in zona.
 
 Ciao e grazie ancora per l'aiuto!
 
 MAx
 
 

Colgo l'occasione di questo thread per chiarire con una domanda, che
mi assilla da tempo e la wiki non mi è chiara su questo aspetto, a
riguardo la relazione inserita nei multipoligoni.

Per esempio nei landuse=forest, è sufficiente metterlo nella
relazione il tag? oppure anche nei singoli multipoligoni?


Perchè mi capita di vedere poligono chiusi con specificato il tag sia
nel perimetro del poligono che nella relazione, ma non capisco se è
questo che spesso mi genera dei warning specifici con josm, quando mi
segnala problemi con quelle relazioni.


- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlPGPiUACgkQoVS0hKoD3PNE5gD/dw2yXQRlmVMCsNQCZexiPH/q
1AewQkS2JKmbsAytlt0BAKcQfpStNUVQO3psH0vM2ratSueL7PKoanlpRrwIgXOB
=0qVz
-END PGP SIGNATURE-

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

Re: [Talk-it] Help su multipoligoni... please!

[Daniele Forsi]

Il 16 luglio 2014 10:56, girarsi_liste ha scritto:

 Per esempio nei landuse=forest, è sufficiente metterlo nella
 relazione il tag? oppure anche nei singoli multipoligoni?

solo sulla relazione perché landuse si usa solo su aree

 Perchè mi capita di vedere poligono chiusi con specificato il tag sia
 nel perimetro del poligono che nella relazione, ma non capisco se è
 questo che spesso mi genera dei warning specifici con josm, quando mi
 segnala problemi con quelle relazioni.

per i poligoni chiusi non dovrebbe segnalare niente, se ti ricapita
facci sapere l'id

capita di trovare i tag duplicati o relazioni con i tag solo sugli
outer perché quando le relazioni sono state inventate i tag si
mettevano sugli outer invece che sulla relazione, ma è un problema
solo se gli outer sono mappati diversamente per errore (es. uno forest
e l'altro riverbank) perché un programma non può sapere cosa è
rappresentato se non ci sono tag fisici sulla relazione

-- 
Daniele Forsi

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

Re: [Talk-it] Mappare la Rotonda Antonelliana

[Michele iw1gfv]

On 16/07/2014 10:49, girarsi_liste wrote:


Il 16/07/2014 00:23, Michele iw1gfv ha scritto:

Vorrei mappare la Rotonda Antonelliana e la chiesa di
Castellamonte. http://www.fctp.it/media///luoghi/10370_97860_1.jpg

Le mura a cerchio dovevano essere la chiesa, ma i lavori non sono
stati completati, ora queste mura cingono il piazzale antistante la
chiesa.

Secondo voi è corretto usare historic:monument ?





Il problema è che il tag historic crea un'area, o si aspetta ciò.


A me non serve un area intera, ma solo l'area dei muri, visto che sono 
pittosto spessi.





Taggherei gli edifici come historic,

Fatto

e il muro come barrier=wall, oppure

wall non crea un area, e visto che i muri sono piuttosto spessi ho 
optato per la relazione.


puoi crearti una relazione outer con multipoligono creando un'area
apposita che racchiuda edifici e muri, cioè unendo i nodi dell'area
creata con il perimetro esterno del tutto, e mettendo nel
multipoligono historic=monument, start_date=* (quando è stata fatta),
amenity=place_of_worship, denomination=catholic, religion=christian,
name=*, tourism=attraction.

Ho fatto così, ma leggendo bene il wiki ho visto che monument dovrebbe 
essere usato solo per i monumenti, così ho taggato con historic:yes , 
visto che non ho trovato altre cose più precise.





Gli edifici e i muri non serve taggarli con historic, in quanto già
inteso nel multipoligono




Grazie mille per l'aiuto!


--
Michele
www.iw1gfv.it
Canale Youtube http://www.youtube.com/user/iw1gfv

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

[Talk-it] Piste da fondo, occorre richiesta per apertura dati?

[dvdzero]

Ciao,

vorrei riportare su osm i dati delle piste da fondo della Lessinia (Verona).
Ho trovato questa pagina
http://www.altalessinia.it/il-centro-fondo/le-piste/ con mappa pdf e
percorsi kml. Non si tratterebbe di un import da zero ma solo di aggiungere
i tag necessari a percorsi già presenti oppure di aggiungere relazioni o
percorsi visibili anche dalle satellitari.

Siccome vorrei comunque contattare la società che gestisce le piste per
chiedere se i percorsi indicati sono aggiornati, occorre chiedere
esplicitamente l'apertura dei dati?

Ciao
Davide



--
View this message in context: 
http://gis.19327.n5.nabble.com/Piste-da-fondo-occorre-richiesta-per-apertura-dati-tp5811588.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Mappare la Rotonda Antonelliana

[Martin Koppenhoefer]

 Am 16/lug/2014 um 14:35 schrieb Michele iw1gfv iw1...@yahoo.it:
 
 A me non serve un area intera, ma solo l'area dei muri, visto che sono 
 pittosto spessi.



+1
comunque si può usare 'historic' anche su nodi o features lineari
es. historic=roman_road

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

Re: [Talk-it] Mappare la Rotonda Antonelliana

[Martin Koppenhoefer]

 Am 16/lug/2014 um 14:35 schrieb Michele iw1gfv iw1...@yahoo.it:
 
 Ho fatto così, ma leggendo bene il wiki ho visto che monument dovrebbe essere 
 usato solo per i monumenti, così ho taggato con historic:yes , visto che non 
 ho trovato altre cose più precise.


ti puoi sempre inventare un tag ad-hoc, non c'è problema. Si potrebbe anche 
considerare rovina (mai completato invece di rovinato), ma ad oggi mi sembra 
che la struttura è ben integrato come elemento urbanistico, quindi ruin 
sembrerebbe un po' strano...


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

[Talk-it] Fwd: [OSM-talk] OpenStreetMap Availability (Coverage) 2014

[Martin Koppenhoefer]

per chi non legge talk inoltro questa grafica della densità dei dati osm...


Anfang der weitergeleiteten E‑Mail:

 Von: Christian Quest cqu...@openstreetmap.fr
 Datum: 16 luglio 2014 18:20:02 CEST
 An: Talk Openstreetmap t...@openstreetmap.org
 Betreff: Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014
 
 Yet another OSM density dataviz... ;)
 
 http://cl.ly/image/2f0y3K2b1Z1b
 
 Instead of just taking nodes into account, I used an awfull* SELECT count(*) 
 query on osm2pgsql point and line tables.
 It means that only nodes with some useful tags are showing up in the green 
 channel, and lines are showing up in the red channel.
 
 
 * here it is: https://gist.github.com/cquest/d1734a71c3a4a18587fe
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-dk] osm standard kort

[Kristian Krægpøth]

Jeg synes ikke, at highway=unclassified er en passende betegnelse for de
veje, der fører frem til både ejendomme og eventuelle
mark- og skovveje. Hvis highway=unclassified skal bruges, skal der i hvert
fald tilføjes et eller flere access=XX, fx access=forestry. Men det er ikke
rigtig godt.

Når jeg læser i wiki´en kan jeg se at highway=service er for access roads
to, or within an industrial estate, camp site, business park, car park
etc. Jeg anser landejendomme for en business i den her forbindelse.
Hvis man giver highway=service tilføjelsen service=driveway betyder det a
service road leading to a residens or business, usually with
access=private.

Det virker som der ikke rigtig er forskel på
higway=service og
highway=service, service=driveway.
Den sidste omfatter også boliger og er måske oftere privat end den første.

For fremtiden vil jeg bruge highway=service i forbindelse med adgangsveje
til ejendomme, som også er adgangsveje til fx skovområder.
Kun hvis der ALENE er tale om adgang til ejendomme vil jeg tilføje
service=driveway.

Men pyh-ha, hvor har jeg tegnet mange adgangsveje, som også er adgang til
skovarealer, med tilføjelsen driveway.
Findes der en enkel måde hvor man i ét (eller få) hug kan slette alle
service=driveway på de veje, som giver adgang til highway=track?


Venlig hilsen
Kristian Krægpøth


Den 16. jul. 2014 kl. 08.35 skrev Lars Thegler l...@thegler.dk:

 2014-07-16 0:00 GMT+02:00 Ole Nielsen on-...@xs4all.nl:
  Måske undlade at bruge service=driveway,
  hvis der er tracks forbundet i enden?

 Enig. Tagget service=driveway indikerer indkørsel til en ejendom, dvs
 implicit 'privat vej' - men hvis vejen samtidigt er adgangsvej til
 'offentlige' skovveje med highway=track, så er det ikke en
 service=driveway.

 /Lars

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

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

Re: [Talk-dk] osm standard kort

[Leif Lodahl]

Hej,
En indkørsel er en indkørsel. En servicevej er en servicevej. Hvordan det
renderes på kortet er ikke relevant.

Jeg synes det vil være forkert, hvis vi ændrer måden vi kortlægger på, bare
for at få det til at se rigtigt ud.

Bedre er det, hvis vi kan få ændret renderingen?


/Leif Lodahl




Den 16. jul. 2014 kl. 16.53 skrev Kristian Krægpøth k.kragp...@gmail.com:


 Jeg synes ikke, at highway=unclassified er en passende betegnelse for de
 veje, der fører frem til både ejendomme og eventuelle
 mark- og skovveje. Hvis highway=unclassified skal bruges, skal der i hvert
 fald tilføjes et eller flere access=XX, fx access=forestry. Men det er ikke
 rigtig godt.

 Når jeg læser i wiki´en kan jeg se at highway=service er for access roads
 to, or within an industrial estate, camp site, business park, car park
 etc. Jeg anser landejendomme for en business i den her forbindelse.
 Hvis man giver highway=service tilføjelsen service=driveway betyder det a
 service road leading to a residens or business, usually with
 access=private.

 Det virker som der ikke rigtig er forskel på
 higway=service og
 highway=service, service=driveway.
 Den sidste omfatter også boliger og er måske oftere privat end den første.

 For fremtiden vil jeg bruge highway=service i forbindelse med adgangsveje
 til ejendomme, som også er adgangsveje til fx skovområder.
 Kun hvis der ALENE er tale om adgang til ejendomme vil jeg tilføje
 service=driveway.

 Men pyh-ha, hvor har jeg tegnet mange adgangsveje, som også er adgang til
 skovarealer, med tilføjelsen driveway.
 Findes der en enkel måde hvor man i ét (eller få) hug kan slette alle
 service=driveway på de veje, som giver adgang til highway=track?


 Venlig hilsen
 Kristian Krægpøth


 Den 16. jul. 2014 kl. 08.35 skrev Lars Thegler l...@thegler.dk:

 2014-07-16 0:00 GMT+02:00 Ole Nielsen on-...@xs4all.nl:
  Måske undlade at bruge service=driveway,
  hvis der er tracks forbundet i enden?

 Enig. Tagget service=driveway indikerer indkørsel til en ejendom, dvs
 implicit 'privat vej' - men hvis vejen samtidigt er adgangsvej til
 'offentlige' skovveje med highway=track, så er det ikke en
 service=driveway.

 /Lars

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



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


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

Re: [Talk-dk] osm standard kort

[Niels Elgaard Larsen]

On 14-07-16 02:50 PM, Leif Lodahl wrote:

Hej,
En indkørsel er en indkørsel. En servicevej er en servicevej. Hvordan
det renderes på kortet er ikke relevant.

Jeg synes det vil være forkert, hvis vi ændrer måden vi kortlægger på,
bare for at få det til at se rigtigt ud.


Det er ikke kortet paa hjemmesiden, der er problemet.

Hvis jeg vil ind i en skov hvor der er skovveje, saa vil jeg stadig 
gerne undgaa at komme ind paa folks indkorsler.


Hvis det er meningen, at jeg kan komme ind i en skov, ad veje der gaar 
forbi gaarde, saa er de veje ikke indkorsler, de er maaske 
highway=service, men de er ikke service=driveway.


Men hvis det bare er landmanden som har sit private hjulspor til et sted 
hvor et par koer staar paa graes, saa kan den godt vaere forbundet til 
en indkorsel.



Noget andet er saa at mange af skovvejene heller ikke burde vaere 
highway=track. Bare fordi en vej ikke er asfalteret og der er skov rundt 
omkring den, betyder det ikke, at den er highway=track.



Bedre er det, hvis vi kan få ændret renderingen?


/Leif Lodahl




Den 16. jul. 2014 kl. 16.53 skrev Kristian Krægpøth
k.kragp...@gmail.com mailto:k.kragp...@gmail.com:


Jeg synes ikke, at highway=unclassified er en passende betegnelse
for de veje, der fører frem til både ejendomme og eventuelle
mark- og skovveje. Hvis highway=unclassified skal bruges, skal der i
hvert fald tilføjes et eller flere access=XX, fx access=forestry.
Men det er ikke rigtig godt.

Når jeg læser i wiki´en kan jeg se at highway=service er for access
roads to, or within an industrial estate, camp site, business park,
car park etc. Jeg anser landejendomme for en business i den her
forbindelse.
Hvis man giver highway=service tilføjelsen service=driveway betyder
det a service road leading to a residens or business, usually with
access=private.

Det virker som der ikke rigtig er forskel på
higway=service og
highway=service, service=driveway.
Den sidste omfatter også boliger og er måske oftere privat end den
første.

For fremtiden vil jeg bruge highway=service i forbindelse med
adgangsveje til ejendomme, som også er adgangsveje til fx skovområder.
Kun hvis der ALENE er tale om adgang til ejendomme vil jeg tilføje
service=driveway.

Men pyh-ha, hvor har jeg tegnet mange adgangsveje, som også er
adgang til skovarealer, med tilføjelsen driveway.
Findes der en enkel måde hvor man i ét (eller få) hug kan slette
alle service=driveway på de veje, som giver adgang til highway=track?


Venlig hilsen
Kristian Krægpøth


Den 16. jul. 2014 kl. 08.35 skrev Lars Thegler l...@thegler.dk
mailto:l...@thegler.dk:

2014-07-16 0:00 GMT+02:00 Ole Nielsen on-...@xs4all.nl
mailto:on-...@xs4all.nl:
  Måske undlade at bruge service=driveway,
  hvis der er tracks forbundet i enden?

Enig. Tagget service=driveway indikerer indkørsel til en
ejendom, dvs
implicit 'privat vej' - men hvis vejen samtidigt er adgangsvej til
'offentlige' skovveje med highway=track, så er det ikke en
service=driveway.

/Lars

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



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




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




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

[Talk-se] Fwd: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm

[Karl Wettin]

John söker någon som kan komma till Stockholm den 25:e juli och hjälpa 
HOT-nybörjare att kartera.

Han är inte med på listan, så CC:a gärna honom eller svara privat, så slipper 
jag vidarebefodra! ; )


kalle

Begin forwarded message:

 From: John Andersson john.anders...@wikimedia.se
 Subject: RE: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm
 Date: 16 Jul 2014 15:37:07 GMT+2
 To: Karl Wettin karl.wet...@kodapan.se
 Cc: Joakim Fors joa...@fo.rs
 
 Hej!
 
 Det får ni gärna göra om ni inte kan! 
 
 Om ni skulle vara intresserade av att besöka Stockholm så går det att söka 
 ett minibidrag från oss på upp till 2 000 kronor! 
 
 Mvh,
 
 John
 - - - -
 John Andersson
 Wikimedia Sverige
 Project Manager
 
 Phone: +46(0)73-3965189
 Email: john.anders...@wikimedia.se
 Skype: johnandersson86 
 
 Be sure to follow us on Twitter at @WikiEuropeana and @WikimediaSE
 Would you like to support free knowledge and Wikipedia? Please consider 
 becoming a member of Wikimedia Sverige! We need your support.
 
 
  Subject: Re: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i 
  Sthlm
  From: karl.wet...@kodapan.se
  Date: Wed, 16 Jul 2014 15:27:18 +0200
  CC: joa...@fo.rs
  To: john.anders...@wikimedia.se
  
  Hej John,
  
  både Joakim och jag är långt nere i Skåne och min misstanke är att han har 
  lika få möjligheter som mig att ställa upp i Stockholm. Mitt bästa tips är 
  att du går med på mejllistan 
  https://lists.openstreetmap.org/listinfo/talk-se och ställer samma fråga 
  där. Eller om du vill så kan jag vidarebefodra det här mejlet åt dig dit 
  och be folk svara dig privat.
  
  
  kalle
  
  On 16 Jul 2014, at 14:57, John Andersson john.anders...@wikimedia.se 
  wrote:
  
   Hejsan!
   
   Jag heter John och jobbar för Wikimedia Sverige, men skriver till er som 
   volontär. Jag har de senaste månaderna börjat bidra lite smått på HOT, 
   vilket jag tycker är ett helt fantastiskt projekt. Jag har tänkt att dra 
   ihop ett litet evenemang runt det vid tillfälle och tänkte nu göra ett 
   första försök. 
   
   På HOT:s mailinglista gick nedanstående mail ut för några dagar sedan och 
   jag tänkte att nu är det dags att ta tag i det hela. I korthet handlar 
   det om att det i flera länder kommer att äga rum mapathon som fokuserar 
   på att kartera Lesotho. 
   
   Saken är dock den att jag själv inte är kunnig nog i OSM och HOT för att 
   känna mig redo att hålla en presentation och lära andra hur man ska göra. 
   Jag har dock förstått av mina kollegor att ni är väldigt kunniga och 
   tänkte höra om ni båda eller någon av er vore intresserade av att vara 
   med på evenemanget och lära mig och andra nybörjare hur man ska göra på 
   bästa sätt? Jag tror att det skulle kunna bli riktigt trevligt! 
   
   Jag kan då ordna lokalen och troligtvis fika/pizza/whatever samt 
   kommunicera ut det i våra kanaler.
   
   Vad tror ni om detta? Vore det intressant? 
   
   Med vänliga hälsningar,
   
   John
   - - - -
   John Andersson
   Wikimedia Sverige
   Project Manager
   
   Phone: +46(0)73-3965189
   Email: john.anders...@wikimedia.se
   Skype: johnandersson86 
   
   Be sure to follow us on Twitter at @WikiEuropeana and @WikimediaSE
   Would you like to support free knowledge and Wikipedia? Please consider 
   becoming a member of Wikimedia Sverige! We need your support.
   
   
   Hi Severin,
   
   To answer some of your questions..
   
   - The TM jobs should be set up later this week
   - They will cover the bulk of the country. The center of Lesotho is mostly
   mountainous so there will likely be very few settlements to be mapped, but
   there will be rivers, streams  roads. The rivers  streams are important
   due to flooding / drought risks that exist in Lesotho.
   - Its possible I will create relations to set up the TM jobs, have to see
   what works best (relations or manual) as the rural task will be large, but
   there will be several urban areas (under the second TM job) that may
   intersect. To give you an idea, I've been playing with uMap to put a rough
   outline together of where we want to map
   http://umap.openstreetmap.fr/en/map/lesotho-mapathon_11639#8/-29.681/29.073
   
   Over the last 2 weeks, we have been reaching out to many, many individuals
   and groups.
   - Every regional OSM mailing list recieved an email asking for support.
   There have been responses but mostly single mappers saying they will join
   in on the 25th. In addition, we started with 3 groups hosting mapathons
   (Ireland, Lesotho  Germany) and in recent days we have added 3 more, one
   in Poland, another in the US and most importantly, a 2nd event in Lesotho
   itself on the opposite side of the country
   
   - Some diary posts outlining the event / plans etc
   
   - Identified and contacted over 20 NGO's involved in working in Lesotho in
   some capacity, some (MSF) have come back saying they will host their own
   mapathon, some others (Help Lesotho) are 

[Talk-es] #GEOpaella el 25 de julio de Geoinquietos Valencia en Descubre l'Horta

[Rafael Oliete Ballester]

Buenas tardes!

Puntualización: [Este email creo que se debería considerar como un
OFFTOPIC aunque esté muy relacionado con todas las actividades que
mueve OSM. ]

Desde Geoinquietos Valencia http://valencia.geoinquietos.org queríamos
anunciar que el próximo 25 de julio celebramos unas nuevas #geopaellas
donde geoinquietos* y no tan geoinquietos tratamos temas relacionados
con la Geomática, los mapas, OpenStreetMap..

Primero de todo, de nuevo una presentación en el hilo de los
geoinquietos http://geoinquietos.org y Geoinquietos Valencia .
Geoinquietos son encuentros locales informales entre gente que
comparte inquietudes, intereses, experiencias o cualquier idea en el
ámbito de la geomática, el software libre y la tecnología geoespacial
(todo aquello relacionado con el ámbito GEO y SIG). Son reuniones
distendidas que suelen constar de una o varias pequeñas presentaciones
o talleres sobre un tema relacionado con la tecnología y la
información geográfica. Además se ha ido evolucionando hacia
#geobirras #geopaella, Mapping Parties incluso cursos.
En nuestra web, un wiki, podréis ver en qué consiste todo
http://valencia.geoinquietos.org

En estas fechas siempre solemos hacer una #GEOpaella en Valencia, en
nuestro evento de FB podéis ver más datos incluso fotos del año pasado
https://www.facebook.com/events/322746027890715/?ref=2 por ello
queríamos ampliar la convocatoria a este grupo por si estábais
interesados en conocer otro grupo de #geoinquietos y crear nuevas
sinergias entre ambos grupos.

Descripción del evento:

---

25 DE JULIO A LAS 15:00
Lugar: Descubre l'Horta [ver pie del email] [2] como el año pasado.
Precio: 20/22€
ES NECESARIO CONFIRMAR, la fecha límite para confirmar es DOMINGO 20
de julio a las 23:59
Para CONFIRMAR: En geoinquietos...@gmail.com, en el evento de facebook
que hemos creado o a Jorge, Pedro-Juan o yo mismo
[SI SE CONFIRMA ES QUE LA PERSONA VIENE Y SE CUENTA CON ELLA, PUESTO
QUE ES UN EVENTO EXCLUSIVO]

Evento de Facebook: https://www.facebook.com/events/322746027890715/

---

Este año, destaco además de un par de geobirras el curso que
realizamos con Mapping Parties [3] y Cursos [4]. Hay muchas más ideas
que queremos poner en común y os necesitamos para poder promover.

Como veréis en el wiki [5] ya nos hemos apuntado unos cuantos y
estamos a la espera de más respuesta, aunque sabemos que las fechas
son complicadas para muchos.

Como el año pasado, se comenzaría hacia las 15:00 y nos podríamos
extender un poco. El año pasado estuvimos muy agusto y queremos
repetir la experiencia.

[1] https://www.facebook.com/descubrelhorta?fref=ts
[2] 
https://www.facebook.com/media/set/?set=a.631414210204061.1073741828.289927994352686type=1
[2] http://wiki.osgeo.org/wiki/Geopaella_2_Geoinquietos_Valencia#Asistentes
[3] 
https://www.facebook.com/media/set/?set=a.708314205847394.1073741829.289927994352686type=3
[4] 
https://www.facebook.com/media/set/?set=a.780229571989190.1073741831.289927994352686type=3
[5] http://wiki.osgeo.org/wiki/Geopaella_3_Geoinquietos_Valencia#Coordedanadas

Un saludo!
Rafael Oliete Ballester
Organización de Geoinquietos Valencia
http://twitter.com/raolbaletco


PD: ¿Dónde está Descubre l'Horta? En Borbotó
Dirección: Josep Renau 44, 46016 Borbotó, Spain
Localización en Foursquare https://foursquare.com/descubrelhorta

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

[Talk-at] OSM-Karte Problem Südosttangente-Verteilerkreis

[fwork]

Hallo,
mit neuer OSM-Karte in Garmin Nüvi-550 wurde ich von der Südosttangente
abgeleitet, dann rund um den Verteilerkreis Favoriten und dann wieder
auf die Südosttangente rauf; so als ob der Laaerbergtunnel gesperrt
wäre.
Ist das ein Problem des Garmin oder der Karte ?

Mit freundlichen Gruessen
Franz Reiter
franz.rei...@cadcam.co.at



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

Re: [Talk-at] OSM-Karte Problem Südosttangente-Verteilerkreis

[Norbert Wenzel]

On 07/16/2014 11:28 AM, fwork wrote:
 mit neuer OSM-Karte in Garmin Nüvi-550 wurde ich von der Südosttangente
 abgeleitet, dann rund um den Verteilerkreis Favoriten und dann wieder
 auf die Südosttangente rauf; so als ob der Laaerbergtunnel gesperrt
 wäre.
 Ist das ein Problem des Garmin oder der Karte ?

Das lässt sich im Nachhinein schwer feststellen, ob die OSM Daten zum
Zeitpunkt der Erstellung der Garmin Daten wirklich einen Fehler hatten
oder ob das nur ein Fehler in der Datenaufbereitung für Garmin war oder
eben im Routing von Garmin selbst. Welche Karte ist denn am Garmin
installiert?

Im Moment funktioniert das Routing stadteinwärts[0] und stadtauswärts[1]
wunderbar.

Norbert

[0] http://osrm.at/8ub
[1] http://osrm.at/8uc

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

[Talk-ro] Întâlnire la București

[Michael Häckel]

Salut,

După părerea mea o întâlnire fizică nu este nici o idee rea, chiar dacă nu 
este nici un mapping party. După cum vedeți pe calendarul [1] în Germania noi 
avem întâlniri lunari la aproximativ 20 de orașe. Din păcate așa ceva nu este 
popular în alte țări. De obicei acolo sunt niște clienți fideli dar și oaspeți 
noi care nu știu mult despre OSM și au întrebări despre OSM.

O să vizitez București de la 30 August până la 1 Septembrie. Cineva știe un 
local potrivit și are timp sâmbătă seară sau duminică și vrea să vină la o 
bere la o țuică sau altceva?

Toate cele bune,
Michael

[1] http://wiki.openstreetmap.org/wiki/Main_Page

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

Re: [Talk-ro] Întâlnire la București

[Gabriel Sebastian Moise]

The other guys knows better than me some good places to meet... Razvan is
one of them ..  They shoul reply to you as soon as they will see this !
I'm living at 100km away from Bucharest but I'll be pleased to meet the
other guys from OSM Romania, and also to meet you...

All the best Michael !


În data de 16 iulie 2014, 22:34, Michael Häckel [via GIS] 
ml-node+s19327n581165...@n5.nabble.com a scris:

 Salut,

 După părerea mea o întâlnire fizică nu este nici o idee rea, chiar dacă nu
 este nici un mapping party. După cum vedeți pe calendarul [1] în Germania
 noi
 avem întâlniri lunari la aproximativ 20 de orașe. Din păcate așa ceva nu
 este
 popular în alte țări. De obicei acolo sunt niște clienți fideli dar și
 oaspeți
 noi care nu știu mult despre OSM și au întrebări despre OSM.

 O să vizitez București de la 30 August până la 1 Septembrie. Cineva știe
 un
 local potrivit și are timp sâmbătă seară sau duminică și vrea să vină la o
 bere la o țuică sau altceva?

 Toate cele bune,
 Michael

 [1] http://wiki.openstreetmap.org/wiki/Main_Page

 ___
 Talk-ro mailing list
 [hidden email] http://user/SendEmail.jtp?type=nodenode=5811650i=0
 https://lists.openstreetmap.org/listinfo/talk-ro


 --
  If you reply to this email, your message will be added to the discussion
 below:
 http://gis.19327.n5.nabble.com/Intalnire-la-Bucure-ti-tp5811650.html
  To start a new topic under Romania, email
 ml-node+s19327n542503...@n5.nabble.com
 To unsubscribe from Romania, click here
 http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5425034code=R2FicmllbFNlYmFzdGlhbk1vaXNlQGdtYWlsLmNvbXw1NDI1MDM0fC0xNjUyMTcwOTky
 .
 NAML
 http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml




-- 
Toate cele bune !
**
Gabriel Sebastian  Moise
Administrator Local - Departament Tehnic
*--*
NextGen Communications S.R.L. - Campina

Mobil NextGen  : 076 111 65 59
Mobil Personal : 0726 311 957

Adresa Postala: Strada Grivitei, Nr.63, Campina, Romania !
*--*




--
View this message in context: 
http://gis.19327.n5.nabble.com/Intalnire-la-Bucure-ti-tp5811650p5811657.html
Sent from the Romania mailing list archive at Nabble.com.___
Talk-ro mailing list
Talk-ro@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ro

[Talk-lv] rumaanja blokjeeshana

[Rich]

luuk, kaadas rumaanjiem probleemas :)

http://wiki.osmfoundation.org/w/images/8/8a/DWG_2014-07-10_Special_Romania.pdf
-- 
 Rich

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

[Talk-ca] OpenStreetMap 10th Birthday Party: Toronto

[Richard Weait]

The tenth anniversary of OpenStreetMap is coming up in just a few
weeks.  Several cities are holding local events to celebrate the local
surveyors who make OpenStreetMap data the best, the most complete, the
most current geographic data everywhere.

The Toronto community has just updated their event.  Please, consider
yourself part of the Toronto community and join us here if you are
able to do so!  We'd love to see you in person.[1]

If you can't make it to Toronto, and there isn't any event already
planned near you, this might be the right time for you to organize an
event.  Do it. Kick-start your local community.  There could be a
dozen quiet local mappers waiting for somebody else to organize the
event.  That's you.

https://wiki.openstreetmap.org/wiki/OpenStreetMap_10th_Anniversary_Birthday_party

Best Regards and Happy Mapping,
Richard

[1] The monthly Toronto Mappy Hour was this week and we had the good
fortune of a visit from a long time mapper who happened to be visiting
the area.  That was great.

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

Re: [Talk-cz] Funguje vam ortofoto?

[Dalibor Jelínek]

No, jo, jsou to kluci sikovni.

Zda se, ze jsem v tom bug reportu trochu kecal, ale nastesti to nebylo na skodu.

Hlavne, ze to zase funguje.

:-)

Dalibor

 

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Wednesday, July 16, 2014 8:59 AM
To: OpenStreetMap Czech Republic
Subject: Re: [Talk-cz] Funguje vam ortofoto?

 

Koukám, že už ti to opravili ;-)

Akorát netuším, jak jsi přišel na tohle:
 It seems to affect only Windows version as Linux users do not have this 
 isssue.

Mám linux a měl jsem i issue ;-)

Marián

-- Původní zpráva --
Od: Dalibor Jelínek dali...@dalibor.cz mailto:dali...@dalibor.cz 
Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org 
mailto:talk-cz@openstreetmap.org 
Datum: 10. 7. 2014 10:13:58
Předmět: Re: [Talk-cz] Funguje vam ortofoto?

 

Aha, diky. 

S tim PNG mi to funguje, ale ty obrazky jsou o dost osklivejsi (pripada mi, ze 
maji malo barev). 

Nevi nekdo, na jake verzi Javy to funguje s JPG, ze bych pripadne downgradoval? 

 

Dalibor 

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Thursday, July 10, 2014 9:59 AM
To: OpenStreetMap Czech Republic
Subject: Re: [Talk-cz] Funguje vam ortofoto? 

 

Viz: https://www.mail-archive.com/talk-cz@openstreetmap.org/msg09971.html

Marián 

-- Původní zpráva --
Od: Dalibor Jelínek dali...@dalibor.cz mailto:dali...@dalibor.cz 
Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org 
mailto:talk-cz@openstreetmap.org 
Datum: 10. 7. 2014 9:55:22
Předmět: [Talk-cz] Funguje vam ortofoto? 

 

Ahoj, 

od jiste doby mi v JOSM prestala fungovat Ortofotomapa. 

URL mam 

wms:http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/service.svc/get?FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=GR_ORTFOTORGBSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
 

a vidim jen chyba, chyba, chyba. 

V textovem okne to pak vypisuje 

Exception: Inconsistent metadata read from stream 

  

Ale kdyz ten odkaz, ktery se pokousi nacist nakopiruju do prohlizece, 

tak se mi dlazdice mapy normalne zobrazi, tak to vypada na nejaky problem  v 
JOSM, 

ale netusim, co je spatne. 

  

Jste na tom nekdo lepe? 

  

Zdravi, 

Dalibor 

  

  

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

= 

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

=

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

Re: [Talk-cz] Posunutá Jihlava

[jzvc]

Cus,  nevim jakej je lokalni posun Bingu, ale narazim na to pomerne 
casto. Tohle vypada naprosto klasicky, ze bing byl pouzitej jako ten 
top presnej podklad.


Snazim se ty lidi upozornit, ze Bing ma pomerne velkej rozpal a ze mame 
lepsi zdroje. Nic vic stim asi neudelas. Bohuzel pokud nekdo edituje 
jinde nez v josm ... tak asi nic jinyho nez Bing nema.


Dne 11.7.2014 19:20, Petr Vejsada napsal(a):

Ahoj,

Jihlava je krásné město, pěkně zmapované. Nikdy jsem tam nebyl, ale podle mapy
jsem si udělal představu, že je to město garáží. Stovky garáží, dosud
neoznačené adresou. Teď adresy přidávám. Potíž je v tom, že mám pocit, že je
skoro celé město posunuté tak o 3 metry. Je to podobně, jako když se díváme na
Bing - sem tam sedí přesně, ale o kus dál už je zase posunutá.

Velký barák asi není zásadní problém. Problém je garáž, která má tak ty 3
metry na šířku, takže adresy jsou často přesně o jednu vedle. Někde, kde to
šlo, jsem hnul celými bloky domů, ale celé město posunovat neumím, netroufám
si a ani by to nemuselo být ku prospěchu, protože posud není všude stejný.

Je nějaké howto, dobrá praxe či něco podobného, jak takovéto situace řešit?

Nejjednodušší je (a taky to někde dělám), posunout ty adresy. Jenže pokud se
dostanou v budoucnu botovi do spárů, vůbec se mu nebude líbit, že adresní bod
leží na jiném domě, než ke kterému patří.

?

--

p



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




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

Re: [Talk-cz] Tracer - nová testovací verze

[jzvc]

Cus, nevim v cem to je, ale s libovolnym pouzitim mi vznikne konflikt. 
Je to na tema ze lokalne sem smazal bod kterej na serveru existuje. 
Vyresit se da jedine tak, ze aplikuju verzi ze serveru, pri pokusu o 
aplikovani lokalni verze se to cykli porad dokola.



Navic pokud josm nekeca, tak ten koflikt vznikne na bodech budov, na 
ktery sem vubec nesahal = plugin zjevne ano.



Dne 11.7.2014 23:15, Marián Kyral napsal(a):

Ahoj,
vzhledem k tomu, že už nějakou dobu relativně bez problémů používán
novou verzi Traceru a zjistil jsem, že opravdu nejsem schopen ji odladit
na 100% (veškeré snahy o ladění stejně končí mapping party - viz moje
neustále stoupající pořadí ve statistikách ;-) ), tak jsem se rozhodl
vývoj ukončit a dát vám to k dispozici k otestování. Pokud by se našel
nějaký programátor, co by pomohl s vývojem, je vítán.

Pokud se nenajdou nějaké extra chyby, tak bych to po dovolené (začátek
srpna), dal do oficiálního repozitáře JOSM. Jestli tady je někdo, kdo
aktivně používá ještě původní Tracer plugin (lokální mono server),
vyzkoušejtě prosím, jestli to ještě stále funguje. Tuhle část jsem nijak
netestoval a nerad bych původní funkcionalitu rozbil ;-)

Plugin je zde: http://www.kyralovi.cz/tmp/josm/beta/Tracer.jar
Zdroje jako obvykle: https://github.com/mkyral/josm-tracer/commits/ruian

Upozorňuji, že je to kompilováno oproti nejnovější dostupné verzi JOSM
(josm-latest), takže to ve starších verzích JOSM nemusí jít nainstalovat.

Změny:
*) Plugin odstraňuje budovy, které se celé ocitnou uvnitř natrasované
budovy.
*) Snažím se řešit překrývající se budovy - nová budova ten přečnívající
kus ukousne - myslel, že to funguje na sto procent, ale teď jsem našel
jeden případ, kdy to nefunguje a zatím jsem to nevyřešil.
*) Snažím se připojit sousedící budovy
*) snažím se odstranit nadbytečné uzly
*) Jo a klávesová zkratka je teď CTRL+SHIFT+T - je to stejné s PointInfo
a taky mi Ctrl+T mezitím ukradli ;-( Komu to nevyhovuje, může si to dle
libosti přenastavit v JOSM.

Sice to nefunguje na 100%, ale rozhodně to funguje lépe než předchozí
verze. Hlavně co se problému s duplicitami týká.

Takže otestujte, hlaste problémy - možná je i opravím, když zatlačíte na
to správné tlačítko ;-)

Já se teď pokusím něco udělat s LPIS. Asi to bude další modul do Traceru
plus uvažuji o možnosti nahrávat vše ve zvoleném Boxu. Ale to ještě
uvidím, jestli to bude součást Traceru, nebo jako samostatný skript.

Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz




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

Re: [Talk-cz] Tracer - nová testovací verze

[Marián Kyral]

Ahoj,

-- Původní zpráva --
Od: jzvc j...@tpfree.net
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 16. 7. 2014 23:00:58
Předmět: Re: [Talk-cz] Tracer - nová testovací verze

Cus, nevim v cem to je, ale s libovolnym pouzitim mi vznikne konflikt. 
Je to na tema ze lokalne sem smazal bod kterej na serveru existuje. 
Vyresit se da jedine tak, ze aplikuju verzi ze serveru, pri pokusu o 
aplikovani lokalni verze se to cykli porad dokola.


Navic pokud josm nekeca, tak ten koflikt vznikne na bodech budov, na 
ktery sem vubec nesahal = plugin zjevne ano.




Divné, divné. Můžeš hodit nějaký příklad? Případně nějaké detaily?

Zkoušel jsi původní, nebo aktualizovanou verzi?




Díky,


Marián





Dne 11.7.2014 23:15, Marián Kyral napsal(a):
 Ahoj,
 vzhledem k tomu, že už nějakou dobu relativně bez problémů používán
 novou verzi Traceru a zjistil jsem, že opravdu nejsem schopen ji odladit
 na 100% (veškeré snahy o ladění stejně končí mapping party - viz moje
 neustále stoupající pořadí ve statistikách ;-) ), tak jsem se rozhodl
 vývoj ukončit a dát vám to k dispozici k otestování. Pokud by se našel
 nějaký programátor, co by pomohl s vývojem, je vítán.

 Pokud se nenajdou nějaké extra chyby, tak bych to po dovolené (začátek
 srpna), dal do oficiálního repozitáře JOSM. Jestli tady je někdo, kdo
 aktivně používá ještě původní Tracer plugin (lokální mono server),
 vyzkoušejtě prosím, jestli to ještě stále funguje. Tuhle část jsem nijak
 netestoval a nerad bych původní funkcionalitu rozbil ;-)

 Plugin je zde: http://www.kyralovi.cz/tmp/josm/beta/Tracer.jar
 Zdroje jako obvykle: https://github.com/mkyral/josm-tracer/commits/ruian

 Upozorňuji, že je to kompilováno oproti nejnovější dostupné verzi JOSM
 (josm-latest), takže to ve starších verzích JOSM nemusí jít nainstalovat.

 Změny:
 *) Plugin odstraňuje budovy, které se celé ocitnou uvnitř natrasované
 budovy.
 *) Snažím se řešit překrývající se budovy - nová budova ten přečnívající
 kus ukousne - myslel, že to funguje na sto procent, ale teď jsem našel
 jeden případ, kdy to nefunguje a zatím jsem to nevyřešil.
 *) Snažím se připojit sousedící budovy
 *) snažím se odstranit nadbytečné uzly
 *) Jo a klávesová zkratka je teď CTRL+SHIFT+T - je to stejné s PointInfo
 a taky mi Ctrl+T mezitím ukradli ;-( Komu to nevyhovuje, může si to dle
 libosti přenastavit v JOSM.

 Sice to nefunguje na 100%, ale rozhodně to funguje lépe než předchozí
 verze. Hlavně co se problému s duplicitami týká.

 Takže otestujte, hlaste problémy - možná je i opravím, když zatlačíte na
 to správné tlačítko ;-)

 Já se teď pokusím něco udělat s LPIS. Asi to bude další modul do Traceru
 plus uvažuji o možnosti nahrávat vše ve zvoleném Boxu. Ale to ještě
 uvidím, jestli to bude součást Traceru, nebo jako samostatný skript.

 Marián
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz



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

Re: [Talk-cz] Tracer - nová testovací verze

[Petr Vejsada]

Toto může vzniknout tehdy, kdy je v editované vrstvě jen samotná editovaná 
budova. JOSM pak nic neví o tom, že uzel je sdílený ještě se sousední budovou. 
Při editování budovy je nutné mít ve vrstvě i všechny budovy, které s ní 
bezprostředně  sousedí a tedy sdílejí společné body.

Dne St 16. července 2014 23:28:03, Marián Kyral napsal(a):

 Cus, nevim v cem to je, ale s libovolnym pouzitim mi vznikne konflikt. 
 Je to na tema ze lokalne sem smazal bod kterej na serveru existuje. 
 Vyresit se da jedine tak, ze aplikuju verzi ze serveru, pri pokusu o 
 aplikovani lokalni verze se to cykli porad dokola.
 
 
 Navic pokud josm nekeca, tak ten koflikt vznikne na bodech budov, na 
 ktery sem vubec nesahal = plugin zjevne ano.
 

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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[JeanMichel FRANCOIS]

Bonjour,

Oui en effet c'est dans mes taches. Le tableau principale nécessite 
d'être revu pour intégrer chaque relation de chaque ligne (+master)


J'aurais bien aimé pouvoir laisser des bugs. J'ai pu voir que certain 
laisse des notes (layer de commentaires) pour indiquer qu'il y a des 
problèmes. Ceci est peut être mieux qu'une case commentaire dans un 
tableau de wiki ?


Le 15/07/2014 16:27, Francescu GAROBY a écrit :

Bonjour,
As-tu aussi pensé à mettre à jour cette page, au fur et à mesure de 
l'avancement de tes corrections ? 
http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun


Francescu


Le 15 juillet 2014 16:08, JeanMichel FRANCOIS 
jeanmichel.franc...@makina-corpus.com 
mailto:jeanmichel.franc...@makina-corpus.com a écrit :


Bonjour,

Je suis entrain de travailler sur le réseau de transports de la
ville de Nantes avec pour objectif de sortir un plan dynamique
rapidement.

Ces données étaient dans un état assez catastrophiques.
Comme je ne connais pas (et pour l'instant ne souhaite pas
connaitre JOSM) j'ai donc pour l'occasion réalisé un outil pour
mettre à jour les données:

http://makinacorpus.github.io/osm-transport-editor/#/1733024

Sans être connecté il sert de browser de relations. (ici la
relation 1733024 correspond au réseau TAN, c'est une super
relation).
Une fois connecté vous pouvez modifier les tags,
ajouter/supprimer/reordonner des ways|nodes à une relation.

J'ai ici plusieurs objectifs :
* indiquer l'existence de cet outil
* indiquer que je travaille sur les données de la TAN
* organiser un événement à la rentrée pour effectuer la mise à
jour du réseau de la TAN

Pour les données
J'ai trouvé certaines relations comme par exemple
http://www.openstreetmap.org/relation/1710433.
Donc n'hésitez pas à revenir vers moi pour qu'on s'organise :)

Vous pouvez me contacter directement pour l'organisation de cet
événement (je pensai le faire à la cantine du numérique).
Pour les remarques sur l'outil merci de répondre sur la liste.

Pour info j'ai regardé du côté de l'intégration de OAUTH et c'est
une horreur (environ deux fois plus de code que toute
l'application juste pour l'auth tout ça parceque OSM ne supporte
pas oauth2). Bref donc je reste sur le concept de l'auth HTTP
basique pour le moment.

En vous souhaitant une bonne fin d'après midi !

-- 
Cordialement,

Makina Corpus http://makina-corpus.com
Newsletters http://makina-corpus.com/formulaires/newsletters |
Formations http://makina-corpus.com/formation | Twitter
https://twitter.com/makina_corpus

Jean-Michel FRANCOIS
Chef de projet
Makina Corpus
Tél : 02 51 79 80 84 tel:02%2051%2079%2080%2084
-- 
@toutpt https://twitter.com/toutpt | @toutpt_fr

https://twitter.com/toutpt_fr
-- 
Découvrez notre catalogue de formations

http://makina-corpus.com/formation


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




--
Cordialement,
Francescu GAROBY


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


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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[JeanMichel FRANCOIS]

C'est pas grave (moi j'ai rien compris à JOSM)

L'application a pour but de fournir un outil qui permet 
d'ajouter/supprimer/reordonner des ways|nodes a une relation.


J'ai hésité entre deux modes: outils généraliste au relation ou vraiment 
spécifique au système utilisé pour le réseau de la TAN:
une super relation (TAN) dont les membres sont des relations master 
dont les membres sont des relations trajets

donc sur trois niveaux.

J'ai pu voir que pour d'autres réseaux comme la RATP ce n'est pas le cas 
(je n'ai pas trouvé une super relation RATP).


Du coup ça fait une question : ce modèle avec trois relation (super / 
master / trajet) est il souvent / jamais / toujours appliqué ?


Voici quelques captures d'écran:
?
https://www.evernote.com/shard/s144/sh/79b6f99d-b217-49b2-8953-fa6b2f5d3d1a/60712f732a2a38e9ae09da2a639b0309


?
Le 15/07/2014 17:07, Christian Quest a écrit :
L'outil est censé faire quoi ? (oui, je n'ai rien compris à on 
fonctionnement)



Le 15 juillet 2014 16:27, Francescu GAROBY windu...@gmail.com 
mailto:windu...@gmail.com a écrit :


Bonjour,
As-tu aussi pensé à mettre à jour cette page, au fur et à mesure
de l'avancement de tes corrections ?
http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun

Francescu


Le 15 juillet 2014 16:08, JeanMichel FRANCOIS
jeanmichel.franc...@makina-corpus.com
mailto:jeanmichel.franc...@makina-corpus.com a écrit :

Bonjour,

Je suis entrain de travailler sur le réseau de transports de
la ville de Nantes avec pour objectif de sortir un plan
dynamique rapidement.

Ces données étaient dans un état assez catastrophiques.
Comme je ne connais pas (et pour l'instant ne souhaite pas
connaitre JOSM) j'ai donc pour l'occasion réalisé un outil
pour mettre à jour les données:

http://makinacorpus.github.io/osm-transport-editor/#/1733024

Sans être connecté il sert de browser de relations. (ici la
relation 1733024 correspond au réseau TAN, c'est une super
relation).
Une fois connecté vous pouvez modifier les tags,
ajouter/supprimer/reordonner des ways|nodes à une relation.

J'ai ici plusieurs objectifs :
* indiquer l'existence de cet outil
* indiquer que je travaille sur les données de la TAN
* organiser un événement à la rentrée pour effectuer la mise à
jour du réseau de la TAN

Pour les données
J'ai trouvé certaines relations comme par exemple
http://www.openstreetmap.org/relation/1710433.
Donc n'hésitez pas à revenir vers moi pour qu'on s'organise :)

Vous pouvez me contacter directement pour l'organisation de
cet événement (je pensai le faire à la cantine du numérique).
Pour les remarques sur l'outil merci de répondre sur la liste.

Pour info j'ai regardé du côté de l'intégration de OAUTH et
c'est une horreur (environ deux fois plus de code que toute
l'application juste pour l'auth tout ça parceque OSM ne
supporte pas oauth2). Bref donc je reste sur le concept de
l'auth HTTP basique pour le moment.

En vous souhaitant une bonne fin d'après midi !

-- 
Cordialement,

Makina Corpus http://makina-corpus.com
Newsletters http://makina-corpus.com/formulaires/newsletters
| Formations http://makina-corpus.com/formation | Twitter
https://twitter.com/makina_corpus

Jean-Michel FRANCOIS
Chef de projet
Makina Corpus
Tél : 02 51 79 80 84 tel:02%2051%2079%2080%2084
-- 
@toutpt https://twitter.com/toutpt | @toutpt_fr

https://twitter.com/toutpt_fr
-- 
Découvrez notre catalogue de formations

http://makina-corpus.com/formation


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




-- 
Cordialement,

Francescu GAROBY

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




--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Francescu GAROBY]

Réponse : jamais !
Explication : les relations ne sont pas des catégories
http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories

(par contre, le schéma master/trajets est correct)

Francescu


Le 16 juillet 2014 08:56, JeanMichel FRANCOIS 
jeanmichel.franc...@makina-corpus.com a écrit :

  C'est pas grave (moi j'ai rien compris à JOSM)

 L'application a pour but de fournir un outil qui permet
 d'ajouter/supprimer/reordonner des ways|nodes a une relation.

 J'ai hésité entre deux modes: outils généraliste au relation ou vraiment
 spécifique au système utilisé pour le réseau de la TAN:
 une super relation (TAN) dont les membres sont des relations master dont
 les membres sont des relations trajets
 donc sur trois niveaux.

 J'ai pu voir que pour d'autres réseaux comme la RATP ce n'est pas le cas
 (je n'ai pas trouvé une super relation RATP).

 Du coup ça fait une question : ce modèle avec trois relation (super /
 master / trajet) est il souvent / jamais / toujours appliqué ?

 Voici quelques captures d'écran:
 

 https://www.evernote.com/shard/s144/sh/79b6f99d-b217-49b2-8953-fa6b2f5d3d1a/60712f732a2a38e9ae09da2a639b0309


 
 Le 15/07/2014 17:07, Christian Quest a écrit :

 L'outil est censé faire quoi ? (oui, je n'ai rien compris à on
 fonctionnement)


 Le 15 juillet 2014 16:27, Francescu GAROBY windu...@gmail.com a écrit :

 Bonjour,
 As-tu aussi pensé à mettre à jour cette page, au fur et à mesure de
 l'avancement de tes corrections ?
 http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun

  Francescu


 Le 15 juillet 2014 16:08, JeanMichel FRANCOIS 
 jeanmichel.franc...@makina-corpus.com a écrit :

   Bonjour,

 Je suis entrain de travailler sur le réseau de transports de la ville de
 Nantes avec pour objectif de sortir un plan dynamique rapidement.

 Ces données étaient dans un état assez catastrophiques.
 Comme je ne connais pas (et pour l'instant ne souhaite pas connaitre
 JOSM) j'ai donc pour l'occasion réalisé un outil pour mettre à jour les
 données:

 http://makinacorpus.github.io/osm-transport-editor/#/1733024

 Sans être connecté il sert de browser de relations. (ici la relation
 1733024 correspond au réseau TAN, c'est une super relation).
 Une fois connecté vous pouvez modifier les tags,
 ajouter/supprimer/reordonner des ways|nodes à une relation.

 J'ai ici plusieurs objectifs :
 * indiquer l'existence de cet outil
 * indiquer que je travaille sur les données de la TAN
 * organiser un événement à la rentrée pour effectuer la mise à jour du
 réseau de la TAN

 Pour les données
 J'ai trouvé certaines relations comme par exemple
 http://www.openstreetmap.org/relation/1710433.
 Donc n'hésitez pas à revenir vers moi pour qu'on s'organise :)

 Vous pouvez me contacter directement pour l'organisation de cet
 événement (je pensai le faire à la cantine du numérique).
 Pour les remarques sur l'outil merci de répondre sur la liste.

 Pour info j'ai regardé du côté de l'intégration de OAUTH et c'est une
 horreur (environ deux fois plus de code que toute l'application juste pour
 l'auth tout ça parceque OSM ne supporte pas oauth2). Bref donc je reste sur
 le concept de l'auth HTTP basique pour le moment.

 En vous souhaitant une bonne fin d'après midi !

 --
 Cordialement,
   [image: Makina Corpus] http://makina-corpus.com
 Newsletters http://makina-corpus.com/formulaires/newsletters |
 Formations http://makina-corpus.com/formation | Twitter
 https://twitter.com/makina_corpus
  Jean-Michel FRANCOIS
 Chef de projet
 Makina Corpus
 Tél : 02 51 79 80 84
  --
  @toutpt https://twitter.com/toutpt | @toutpt_fr
 https://twitter.com/toutpt_fr
 --
 Découvrez notre catalogue de formations
 http://makina-corpus.com/formation

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




  --
 Cordialement,
 Francescu GAROBY

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




  --
 Christian Quest - OpenStreetMap France


 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr



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




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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)

[olivier delaune]

Heu pourquoi est ce qu'on reçoit tous les messages de Jean-Michel en double, 
triple, quadruple exemplaires ?
Un problème de ton côté Jean-Michel ?




 

 Message: 1
 Date: Wed, 16 Jul 2014 08:56:29 +0200
 From: JeanMichel FRANCOIS 
 To: talk-fr@openstreetmap.org
 Subject: Re: [OSM-talk-fr] Edition des relations pour les transports
 en commun (ville de Nantes)
 Message-ID: 53c6221d.4010...@makina-corpus.com
 Content-Type: text/plain; charset=iso-8859-1; Format=flowed
 
 C'est pas grave (moi j'ai rien compris à JOSM)
 
 L'application a pour but de fournir un outil qui permet 
 d'ajouter/supprimer/reordonner des ways|nodes a une relation.
 
 J'ai hésité entre deux modes: outils généraliste au relation ou vraiment 
 spécifique au système utilisé pour le réseau de la TAN:
 une super relation (TAN) dont les membres sont des relations master 
 dont les membres sont des relations trajets
 donc sur trois niveaux.
 
 J'ai pu voir que pour d'autres réseaux comme la RATP ce n'est pas le cas 
 (je n'ai pas trouvé une super relation RATP).
 
 Du coup ça fait une question : ce modèle avec trois relation (super / 
 master / trajet) est il souvent / jamais / toujours appliqué ?
 
 Voici quelques captures d'écran:
 ?
 https://www.evernote.com/shard/s144/sh/79b6f99d-b217-49b2-8953-fa6b2f5d3d1a/60712f732a2a38e9ae09da2a639b0309
 
 
 ?
 Le 15/07/2014 17:07, Christian Quest a écrit :
  L'outil est censé faire quoi ? (oui, je n'ai rien compris à on 
  fonctionnement)
 
 
  Le 15 juillet 2014 16:27, Francescu GAROBYa écrit :
 
  Bonjour,
  As-tu aussi pensé à mettre à jour cette page, au fur et à mesure
  de l'avancement de tes corrections ?
  http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun
 
  Francescu
 
 
  Le 15 juillet 2014 16:08, JeanMichel FRANCOIS
 a écrit :
 
  Bonjour,
 
  Je suis entrain de travailler sur le réseau de transports de
  la ville de Nantes avec pour objectif de sortir un plan
  dynamique rapidement.
 
  Ces données étaient dans un état assez catastrophiques.
  Comme je ne connais pas (et pour l'instant ne souhaite pas
  connaitre JOSM) j'ai donc pour l'occasion réalisé un outil
  pour mettre à jour les données:
 
  http://makinacorpus.github.io/osm-transport-editor/#/1733024
 
  Sans être connecté il sert de browser de relations. (ici la
  relation 1733024 correspond au réseau TAN, c'est une super
  relation).
  Une fois connecté vous pouvez modifier les tags,
  ajouter/supprimer/reordonner des ways|nodes à une relation.
 
  J'ai ici plusieurs objectifs :
  * indiquer l'existence de cet outil
  * indiquer que je travaille sur les données de la TAN
  * organiser un événement à la rentrée pour effectuer la mise à
  jour du réseau de la TAN
 
  Pour les données
  J'ai trouvé certaines relations comme par exemple
  http://www.openstreetmap.org/relation/1710433.
  Donc n'hésitez pas à revenir vers moi pour qu'on s'organise :)
 
  Vous pouvez me contacter directement pour l'organisation de
  cet événement (je pensai le faire à la cantine du numérique).
  Pour les remarques sur l'outil merci de répondre sur la liste.
 
  Pour info j'ai regardé du côté de l'intégration de OAUTH et
  c'est une horreur (environ deux fois plus de code que toute
  l'application juste pour l'auth tout ça parceque OSM ne
  supporte pas oauth2). Bref donc je reste sur le concept de
  l'auth HTTP basique pour le moment.
 
  En vous souhaitant une bonne fin d'après midi !
 
  -- 
  Cordialement,
  Makina Corpus 
  Newsletters 
  | Formations  | Twitter
  
  
  Jean-Michel FRANCOIS
  Chef de projet
  Makina Corpus
  Tél : 02 51 79 80 84 
  -- 
  @toutpt  | @toutpt_fr
  
  -- 
  Découvrez notre catalogue de formations
  
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org 
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
  -- 
  Cordialement,
  Francescu GAROBY
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org 
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
  -- 
  Christian Quest - OpenStreetMap France
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 -- section suivante --
 Une pièce jointe HTML a été nettoyée...
 URL: 
 -- section suivante --
 Une pièce jointe autre que texte a été nettoyée...
 Nom: non disponible
 Type: image/png
 Taille: 6926 octets
 Desc: non disponible
 URL: 
 
 --
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 Fin de Lot Talk-fr, Vol 96, Parution 81
 ***
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[JeanMichel FRANCOIS]

C'est dommage, je trouvais ça pratique.

Je pense qu'il y a quand même une différence entre cette super relation 
et une catégorie de relations.
En effet, elle n'a pas vocation à créer un type de relation ici mais 
bien regrouper les lignes pour former le 'réseau' de la TAN

qui est locale à la ville de Nantes.

Une autre question me vient : Quels sont les habitudes et les bonnes 
pratique avant de supprimer une donnée ?


Par exemple j'ai trouvé la relation suivante: C5 Quai des Antilles - 
Gare SNCF Sud

http://www.openstreetmap.org/relation/1710435

hors cette relation existe déjà avec un autre identifiant et dans un 
bien meilleur état :

https://openstreetmap.org/relation/1710434

J'ai contacté le dernier contributeur (trouvé avec l'outil d'historique) 
mais je reste sans réponse pour le moment.

http://osm.virtuelle-loipe.de/history/?type=relationref=1710435

Du coup quand je fais l'export de toutes les relations du réseau pour 
avoir le plan du réseau

j'ai des morceaux de rond point ici et la à cause de ces relations.

Merci.

Le 16/07/2014 09:14, Francescu GAROBY a écrit :

Réponse : jamais !
Explication : les relations ne sont pas des catégories 
http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories


(par contre, le schéma master/trajets est correct)

Francescu


Le 16 juillet 2014 08:56, JeanMichel FRANCOIS 
jeanmichel.franc...@makina-corpus.com 
mailto:jeanmichel.franc...@makina-corpus.com a écrit :


C'est pas grave (moi j'ai rien compris à JOSM)

L'application a pour but de fournir un outil qui permet
d'ajouter/supprimer/reordonner des ways|nodes a une relation.

J'ai hésité entre deux modes: outils généraliste au relation ou
vraiment spécifique au système utilisé pour le réseau de la TAN:
une super relation (TAN) dont les membres sont des relations
master dont les membres sont des relations trajets
donc sur trois niveaux.

J'ai pu voir que pour d'autres réseaux comme la RATP ce n'est pas
le cas (je n'ai pas trouvé une super relation RATP).

Du coup ça fait une question : ce modèle avec trois relation
(super / master / trajet) est il souvent / jamais / toujours
appliqué ?

Voici quelques captures d'écran:
?

https://www.evernote.com/shard/s144/sh/79b6f99d-b217-49b2-8953-fa6b2f5d3d1a/60712f732a2a38e9ae09da2a639b0309


?
Le 15/07/2014 17:07, Christian Quest a écrit :

L'outil est censé faire quoi ? (oui, je n'ai rien compris à on
fonctionnement)


Le 15 juillet 2014 16:27, Francescu GAROBY windu...@gmail.com
mailto:windu...@gmail.com a écrit :

Bonjour,
As-tu aussi pensé à mettre à jour cette page, au fur et à
mesure de l'avancement de tes corrections ?
http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun

Francescu


Le 15 juillet 2014 16:08, JeanMichel FRANCOIS
jeanmichel.franc...@makina-corpus.com
mailto:jeanmichel.franc...@makina-corpus.com a écrit :

Bonjour,

Je suis entrain de travailler sur le réseau de transports
de la ville de Nantes avec pour objectif de sortir un
plan dynamique rapidement.

Ces données étaient dans un état assez catastrophiques.
Comme je ne connais pas (et pour l'instant ne souhaite
pas connaitre JOSM) j'ai donc pour l'occasion réalisé un
outil pour mettre à jour les données:

http://makinacorpus.github.io/osm-transport-editor/#/1733024

Sans être connecté il sert de browser de relations. (ici
la relation 1733024 correspond au réseau TAN, c'est une
super relation).
Une fois connecté vous pouvez modifier les tags,
ajouter/supprimer/reordonner des ways|nodes à une relation.

J'ai ici plusieurs objectifs :
* indiquer l'existence de cet outil
* indiquer que je travaille sur les données de la TAN
* organiser un événement à la rentrée pour effectuer la
mise à jour du réseau de la TAN

Pour les données
J'ai trouvé certaines relations comme par exemple
http://www.openstreetmap.org/relation/1710433.
Donc n'hésitez pas à revenir vers moi pour qu'on
s'organise :)

Vous pouvez me contacter directement pour l'organisation
de cet événement (je pensai le faire à la cantine du
numérique).
Pour les remarques sur l'outil merci de répondre sur la
liste.

Pour info j'ai regardé du côté de l'intégration de OAUTH
et c'est une horreur (environ deux fois plus de code que
toute l'application juste pour l'auth tout ça parceque
OSM ne supporte pas oauth2). Bref donc je reste sur le
concept de l'auth HTTP basique pour le moment.

En vous souhaitant une bonne fin d'après midi !

-- 

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Francescu GAROBY]

Si tu veux regrouper les relations d'un même réseau/opérateur, utilise les
tags 'network' et 'operator' et donne-leur la même valeur pour chaque
relation, tout simplement...
Ici, c'est 'network=TAN' et 'operator=SEMITAN', si j'en crois les relations
déjà existantes.

Francescu


Le 16 juillet 2014 09:47, JeanMichel FRANCOIS 
jeanmichel.franc...@makina-corpus.com a écrit :

  C'est dommage, je trouvais ça pratique.

 Je pense qu'il y a quand même une différence entre cette super relation et
 une catégorie de relations.
 En effet, elle n'a pas vocation à créer un type de relation ici mais bien
 regrouper les lignes pour former le 'réseau' de la TAN
 qui est locale à la ville de Nantes.

 Une autre question me vient : Quels sont les habitudes et les bonnes
 pratique avant de supprimer une donnée ?

 Par exemple j'ai trouvé la relation suivante: C5 Quai des Antilles - Gare
 SNCF Sud
 http://www.openstreetmap.org/relation/1710435

 hors cette relation existe déjà avec un autre identifiant et dans un bien
 meilleur état :
 https://openstreetmap.org/relation/1710434

 J'ai contacté le dernier contributeur (trouvé avec l'outil d'historique)
 mais je reste sans réponse pour le moment.
 http://osm.virtuelle-loipe.de/history/?type=relationref=1710435

 Du coup quand je fais l'export de toutes les relations du réseau pour
 avoir le plan du réseau
 j'ai des morceaux de rond point ici et la à cause de ces relations.

 Merci.

 Le 16/07/2014 09:14, Francescu GAROBY a écrit :

 Réponse : jamais !
 Explication : les relations ne sont pas des catégories
 http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories

  (par contre, le schéma master/trajets est correct)

  Francescu


 Le 16 juillet 2014 08:56, JeanMichel FRANCOIS 
 jeanmichel.franc...@makina-corpus.com a écrit :

  C'est pas grave (moi j'ai rien compris à JOSM)

 L'application a pour but de fournir un outil qui permet
 d'ajouter/supprimer/reordonner des ways|nodes a une relation.

 J'ai hésité entre deux modes: outils généraliste au relation ou vraiment
 spécifique au système utilisé pour le réseau de la TAN:
 une super relation (TAN) dont les membres sont des relations master
 dont les membres sont des relations trajets
 donc sur trois niveaux.

 J'ai pu voir que pour d'autres réseaux comme la RATP ce n'est pas le cas
 (je n'ai pas trouvé une super relation RATP).

 Du coup ça fait une question : ce modèle avec trois relation (super /
 master / trajet) est il souvent / jamais / toujours appliqué ?

 Voici quelques captures d'écran:
 

 https://www.evernote.com/shard/s144/sh/79b6f99d-b217-49b2-8953-fa6b2f5d3d1a/60712f732a2a38e9ae09da2a639b0309


 
 Le 15/07/2014 17:07, Christian Quest a écrit :

 L'outil est censé faire quoi ? (oui, je n'ai rien compris à on
 fonctionnement)


 Le 15 juillet 2014 16:27, Francescu GAROBY windu...@gmail.com a écrit :

 Bonjour,
 As-tu aussi pensé à mettre à jour cette page, au fur et à mesure de
 l'avancement de tes corrections ?
 http://wiki.openstreetmap.org/wiki/Nantes/Transports_en_commun

  Francescu


 Le 15 juillet 2014 16:08, JeanMichel FRANCOIS 
 jeanmichel.franc...@makina-corpus.com a écrit :

   Bonjour,

 Je suis entrain de travailler sur le réseau de transports de la ville
 de Nantes avec pour objectif de sortir un plan dynamique rapidement.

 Ces données étaient dans un état assez catastrophiques.
 Comme je ne connais pas (et pour l'instant ne souhaite pas connaitre
 JOSM) j'ai donc pour l'occasion réalisé un outil pour mettre à jour les
 données:

 http://makinacorpus.github.io/osm-transport-editor/#/1733024

 Sans être connecté il sert de browser de relations. (ici la relation
 1733024 correspond au réseau TAN, c'est une super relation).
 Une fois connecté vous pouvez modifier les tags,
 ajouter/supprimer/reordonner des ways|nodes à une relation.

 J'ai ici plusieurs objectifs :
 * indiquer l'existence de cet outil
 * indiquer que je travaille sur les données de la TAN
 * organiser un événement à la rentrée pour effectuer la mise à jour du
 réseau de la TAN

 Pour les données
 J'ai trouvé certaines relations comme par exemple
 http://www.openstreetmap.org/relation/1710433.
 Donc n'hésitez pas à revenir vers moi pour qu'on s'organise :)

 Vous pouvez me contacter directement pour l'organisation de cet
 événement (je pensai le faire à la cantine du numérique).
 Pour les remarques sur l'outil merci de répondre sur la liste.

 Pour info j'ai regardé du côté de l'intégration de OAUTH et c'est une
 horreur (environ deux fois plus de code que toute l'application juste pour
 l'auth tout ça parceque OSM ne supporte pas oauth2). Bref donc je reste sur
 le concept de l'auth HTTP basique pour le moment.

 En vous souhaitant une bonne fin d'après midi !

 --
 Cordialement,
   [image: Makina Corpus] http://makina-corpus.com
 Newsletters http://makina-corpus.com/formulaires/newsletters |
 Formations http://makina-corpus.com/formation | Twitter
 https://twitter.com/makina_corpus
  Jean-Michel FRANCOIS
 Chef 

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Stéphane Péneau]

Le mercredi 16 juillet 2014 09:47:39, JeanMichel FRANCOIS a écrit :


Par exemple j'ai trouvé la relation suivante: C5 Quai des Antilles -
Gare SNCF Sud
http://www.openstreetmap.org/relation/1710435

hors cette relation existe déjà avec un autre identifiant et dans un
bien meilleur état :
https://openstreetmap.org/relation/1710434



Ces 2 relations sont très différentes, les terminus sont différents sur 
au moins un des côté, les trajets différents, et l'une est un 
chronobus et pas l'autre.


Par contre, je remarque qu'elles portent toutes les 2 les tags 
state=proposed. Je ne sais pas si elles existent vraiment sur le 
terrain.


Stf

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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)

[JeanMichel FRANCOIS]

-corpus.com/formation
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
  --
  Cordialement,
  Francescu GAROBY
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
  --
  Christian Quest - OpenStreetMap France
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-fr

 -- section suivante --
 Une pièce jointe HTML a été nettoyée...
 URL:

http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140716/8d72f7b9/attachment-0002.html
 -- section suivante --
 Une pièce jointe autre que texte a été nettoyée...
 Nom: non disponible
 Type: image/png
 Taille: 6926 octets
 Desc: non disponible
 URL:

http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140716/8d72f7b9/attachment-0002.png

 --

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


 Fin de Lot Talk-fr, Vol 96, Parution 81
 ***
 




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


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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Bruno Cortial]

Le 16 juillet 2014 10:14, Stéphane Péneau stephane.pen...@wanadoo.fr a
écrit :

 Par contre, je remarque qu'elles portent toutes les 2 les tags
 state=proposed. Je ne sais pas si elles existent vraiment sur le terrain.

 Bonjour

Les relations itinéraires (bus et vélo) de Nantes sont dans un état
déplorable. Il y a eu sur le terrain pas mal de modifs ces derniers temps,
et leur modification/maintenance n'a pas suivi. En ce qui me concerne le
schema transport fut un répulsif puissant !

Merci à Jean-Michel de mettre le sujet sur le tapis sur le fond (corriger
les relations) et sur la forme (nouvel éditeur de relation transport).

Bruno (qui se lance dans l'inventaire des relations)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Pieren]

2014-07-16 10:10 GMT+02:00 Francescu GAROBY windu...@gmail.com:

 Si tu veux regrouper les relations d'un même réseau/opérateur, utilise les
 tags 'network' et 'operator' et donne-leur la même valeur pour chaque
 relation, tout simplement...
 Ici, c'est 'network=TAN' et 'operator=SEMITAN', si j'en crois les
 relations déjà existantes.

 Francescu


Absolument. D'ailleurs j'ai mis le sujet de cette relation type=network sur
le tapis:
http://gis.19327.n5.nabble.com/quot-Relations-are-not-categories-quot-excepted-for-quot-type-network-quot-td5811467.html

Certains contributeurs ont une tendance naturelle à utiliser les relations
pour éviter de faire des requêtes spatiales un peu compliqué (surtout si
c'est pour collecter des relations de type route). Il faut y mettre un peu
le hola sinon tous les objets qui peuvent partager des caractéristiques
communes se retrouveront tôt ou tard dans des relations (comme certains qui
créent des tonnes de categories dans le wiki)

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

[OSM-talk-fr] Relation route et giratoire

[Stéphane Péneau]

Puisqu'on parle des relations, j'ai une question :

Est-ce qu'on est d'accord sur le fait que sur les relations route, il 
est inutile de découper les giratoires en plusieurs morceaux ?


Exemple :
https://www.openstreetmap.org/relation/1710434#map=19/47.21445/-1.53770

Je ne vois vraiment pas l'intérêt de ce morcelage qui complique vraiment 
l'édition.


Stf

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

Re: [OSM-talk-fr] Relation route et giratoire

[Pierre-Yves Berrard]

Bonjour,

Le 16 juillet 2014 11:26, Stéphane Péneau stephane.pen...@wanadoo.fr a
écrit :

 Est-ce qu'on est d'accord sur le fait que sur les relations route, il
 est inutile de découper les giratoires en plusieurs morceaux ?

Non. On coupe bien une rue empruntée seulement pour moitié par le véhicule,
alors pourquoi faire une distinction ?


 Je ne vois vraiment pas l'intérêt de ce morcelage qui complique vraiment
 l'édition.

Connaître le parcours exact du véhicule. C'est vrai que cela peut
compliquer l'édition, mais pas de façon insurmontable, selon moi.

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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[JeanMichel FRANCOIS]

Concernant state=proposed, ça fait un an que la C5 est opérationnelle 
(ainsi que tous les 'chronobus') et elle ne passe pas du tout par ici.
J'ai donc retiré les states=proposed des lignes que j'ai pu revoir et 
j'ai ajouté un state!=proposed dans ma query overpass.


Pour avoir des repères pour les lignes de bus j'ai créé à partir du 
fichier gtfs 'opendata' une série de geojson qui reprennent l'ensemble 
des arrêts par lignes de bus:


https://raw.githubusercontent.com/toutpt/opendata-nantes-geojson/master/static/geojson/mobilite-tanstops-C5.geo.json

C'est une donnée opendata je me suis donc basé dessus.

Sur le terrain cette relation ne correspond à rien d'existant, la gare 
sncf n'est pas la et le quai des antilles est plus loin.
Il manque des arrêts, certain sont faux et la route parcourue n'est pas 
la bonne ...


Bref une grosse envie de supprimer cette relation mais il y a eu de 
'petite' modification ces derniers jours par Clement50 (qui ne me répond 
pas).




Le 16/07/2014 10:14, Stéphane Péneau a écrit :

Le mercredi 16 juillet 2014 09:47:39, JeanMichel FRANCOIS a écrit :


Par exemple j'ai trouvé la relation suivante: C5 Quai des Antilles -
Gare SNCF Sud
http://www.openstreetmap.org/relation/1710435

hors cette relation existe déjà avec un autre identifiant et dans un
bien meilleur état :
https://openstreetmap.org/relation/1710434



Ces 2 relations sont très différentes, les terminus sont différents 
sur au moins un des côté, les trajets différents, et l'une est un 
chronobus et pas l'autre.


Par contre, je remarque qu'elles portent toutes les 2 les tags 
state=proposed. Je ne sais pas si elles existent vraiment sur le 
terrain.


Stf

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




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

Re: [OSM-talk-fr] Relation route et giratoire

[Pieren]

2014-07-16 11:26 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr:

 Est-ce qu'on est d'accord sur le fait que sur les relations route, il est
 inutile de découper les giratoires en plusieurs morceaux ?

Cette question a été soulevée plusieurs fois sur cette liste et
ailleurs. Il n'y a jamais eu de consensus à 100% mais mon sentiment
(que je ne peux pas étayer par des chiffres mais je peux chercher les
liens vers les archives) est qu'une majorité s'est exprimée contre ce
genre de découpage.
Il reste des cas où on ne peut pas faire autrement (comme avec les ponts).

 Connaître le parcours exact du véhicule. C'est vrai que cela peut
 compliquer l'édition, mais pas de façon insurmontable, selon moi.

Mouais, c'est en général la réponse de ceux qui font ces découpages
lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
changer quand il faut réparer plusieurs giratoires altérés par des
contributeurs peu attentifs. En plus, on pourrait se retrouver avec
des giratoires incohérents (une partie en tertiary, une autre en
secondary, etc).
Le parcours exact du véhicule peut se reconstituer par logiciel.
Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
veulent exploiter ces données. Mais il vaut mieux donner ce peu de
travail supplémentaire aux data consumers, aux experts plutôt qu'aux
contributeurs qui sont, pour leur immense majorité, des débutants.

Pieren

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

Re: [OSM-talk-fr] Relation route et giratoire

[JeanMichel FRANCOIS]

Je suis bien d'accord ! et je vois pas ce que ça a de plus 'réaliste'.
un rond point est bien une route fermée sur elle même, avec des entrées 
et des sorties.


Le 16/07/2014 11:26, Stéphane Péneau a écrit :

Puisqu'on parle des relations, j'ai une question :

Est-ce qu'on est d'accord sur le fait que sur les relations route, 
il est inutile de découper les giratoires en plusieurs morceaux ?


Exemple :
https://www.openstreetmap.org/relation/1710434#map=19/47.21445/-1.53770

Je ne vois vraiment pas l'intérêt de ce morcelage qui complique 
vraiment l'édition.


Stf

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




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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Pieren]

2014-07-16 11:32 GMT+02:00 JeanMichel FRANCOIS
jeanmichel.franc...@makina-corpus.com:

 Bref une grosse envie de supprimer cette relation mais il y a eu de 'petite'
 modification ces derniers jours par Clement50 (qui ne me répond pas).

Il faut voir la nature de ces modifications. Certaines sont faites
seulement pour clore des erreurs par des outils QA comme JOSM
validator ou osmose ou keepright par des gens qui ne sont pas
forcément au fait du terrain (comme l'ajout de rôles manquants par
exemple).
Si tu ne connais le terrain et que l'auteur ne répond pas (attend un
jour quand même), on peut dire que tu as pris toutes les précautions
avant d'effacer cette relation (d'autres seraient plus directs).

Pieren

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

Re: [OSM-talk-fr] Relation route et giratoire

[Stéphane Péneau]

Le mercredi 16 juillet 2014 11:52:11, Pieren a écrit :

Il n'y a jamais eu de consensus à 100% mais mon sentiment
(que je ne peux pas étayer par des chiffres mais je peux chercher les
liens vers les archives) est qu'une majorité s'est exprimée contre ce
genre de découpage.
Il reste des cas où on ne peut pas faire autrement (comme avec les ponts).


Moi qui avait parfois du remord à recoller les morceaux d'un giratoire, 
je suis rassuré.



Mouais, c'est en général la réponse de ceux qui font ces découpages
lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
changer quand il faut réparer plusieurs giratoires altérés par des
contributeurs peu attentifs.


C'est tout à fait ça, sans parler d'autres cas alambiqués où on 
souhaite ajouter la séparation des voies d'entrée et de sortie.
Ou alors, il faudrait que Josm sache faire un rond depuis une sélection 
de ways.



Le parcours exact du véhicule peut se reconstituer par logiciel.
Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
veulent exploiter ces données. Mais il vaut mieux donner ce peu de
travail supplémentaire aux data consumers, aux experts plutôt qu'aux
contributeurs qui sont, pour leur immense majorité, des débutants.


100% d'accord ! Les logiciels de navigation le font déjà très bien, je 
ne vois pas pourquoi ça serait plus compliqué lorsqu'on suit une 
relation route qui n'est finalement pas très différente d'un trajet 
avec des points de passages.


Stf

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

Re: [OSM-talk-fr] Relation route et giratoire

[Pierre-Yves Berrard]

Le 16 juillet 2014 11:52, Pieren pier...@gmail.com a écrit :

 2014-07-16 11:26 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr:

  Connaître le parcours exact du véhicule. C'est vrai que cela peut
  compliquer l'édition, mais pas de façon insurmontable, selon moi.

 Mouais, c'est en général la réponse de ceux qui font ces découpages
 lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
 changer quand il faut réparer plusieurs giratoires altérés par des
 contributeurs peu attentifs. En plus, on pourrait se retrouver avec
 des giratoires incohérents (une partie en tertiary, une autre en
 secondary, etc).


Les incohérences de tag sont faciles à détecter et à corriger. Et pour
redéssiner un giratoire éclaté bien rond, on peut créer un chemin
temporaire reprenant tous les points, faire un rond avec ce chemin, puis le
supprimer.

Le parcours exact du véhicule peut se reconstituer par logiciel.
 Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
 veulent exploiter ces données. Mais il vaut mieux donner ce peu de
 travail supplémentaire aux data consumers, aux experts plutôt qu'aux
 contributeurs qui sont, pour leur immense majorité, des débutants.


Cet argument me convainc davantage que celui de la difficulté d'édition.
Peut-être que je ne couperai plus les giratoires à l'avenir...

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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)

[Stéphane Péneau]

Le 16/07/2014 09:40, olivier delaune a écrit :


Heu pourquoi est ce qu'on reçoit tous les messages de Jean-Michel en
double, triple, quadruple exemplaires ?
Un problème de ton côté Jean-Michel ?


J'ai le même souci. Les messages semblent être envoyés plusieurs fois 
depuis le serveur de mail de makina-corpus


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

Re: [OSM-talk-fr] Relation route et giratoire

[Sylvain Maillard]

Surtout qu'on peut dire que la travail à été fait à moitié : si on veut
vraiment découper un rond-point, dans ce cas il faut aller au bout de la
démarche et le faire à chaque connexion de route, et pas seulement 2
sorties sur 4 ...


Sylvain


Le 16 juillet 2014 12:14, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Le 16 juillet 2014 11:52, Pieren pier...@gmail.com a écrit :

 2014-07-16 11:26 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr:

  Connaître le parcours exact du véhicule. C'est vrai que cela peut
  compliquer l'édition, mais pas de façon insurmontable, selon moi.

 Mouais, c'est en général la réponse de ceux qui font ces découpages
 lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
 changer quand il faut réparer plusieurs giratoires altérés par des
 contributeurs peu attentifs. En plus, on pourrait se retrouver avec
 des giratoires incohérents (une partie en tertiary, une autre en
 secondary, etc).


 Les incohérences de tag sont faciles à détecter et à corriger. Et pour
 redéssiner un giratoire éclaté bien rond, on peut créer un chemin
 temporaire reprenant tous les points, faire un rond avec ce chemin, puis le
 supprimer.

 Le parcours exact du véhicule peut se reconstituer par logiciel.
 Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
 veulent exploiter ces données. Mais il vaut mieux donner ce peu de
 travail supplémentaire aux data consumers, aux experts plutôt qu'aux
 contributeurs qui sont, pour leur immense majorité, des débutants.


 Cet argument me convainc davantage que celui de la difficulté d'édition.
 Peut-être que je ne couperai plus les giratoires à l'avenir...

 PY

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


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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)

[David Crochet]

Bonjour

Le 16/07/2014 09:40, olivier delaune a écrit :

Heu pourquoi est ce qu'on reçoit tous les messages de Jean-Michel en
double, triple, quadruple exemplaires ?
Un problème de ton côté Jean-Michel ?



J'ai le même souci, comme si le courriel était toujours dans la boite 
d'envoi


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Relation route et giratoire

[Christophe Merlet]

Le 16/07/2014 11:26, Stéphane Péneau a écrit :
 Puisqu'on parle des relations, j'ai une question :
 
 Est-ce qu'on est d'accord sur le fait que sur les relations route, il
 est inutile de découper les giratoires en plusieurs morceaux ?
 
 Exemple :
 https://www.openstreetmap.org/relation/1710434#map=19/47.21445/-1.53770
 
 Je ne vois vraiment pas l'intérêt de ce morcelage qui complique vraiment
 l'édition.


Je suis contre ce genre de morcelage.

Et dernièrement j'ai même constaté qu'on m'avait morcelé un rond-point
palois qui ne fait même pas partie d'une relation route avec comme
commentaire Amélioration giratoire

http://www.openstreetmap.org/way/222542759

Ça me laisse perplexe :/


Librement,
-- 
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Christophe Merlet]

Le 16/07/2014 10:10, Francescu GAROBY a écrit :
 Si tu veux regrouper les relations d'un même réseau/opérateur, utilise
 les tags 'network' et 'operator' et donne-leur la même valeur pour
 chaque relation, tout simplement...
 Ici, c'est 'network=TAN' et 'operator=SEMITAN', si j'en crois les
 relations déjà existantes.

Pas mieux !


Librement,
-- 
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Relation route et giratoire

[Paul Mallet]

Pas forcément, si le bus (ou n'importe quel autre trajet) ne concerne que
2 intersections, il n'y a aucune raison de séparer le rond point au niveau
des autres intersections... (pourquoi séparer une voie en 2 segments
partageant les mêmes tags et faisant partie des mêmes relations ?)

Paul MALLET


Le 16 juillet 2014 12:20, Sylvain Maillard sylvain.maill...@gmail.com a
écrit :

 Surtout qu'on peut dire que la travail à été fait à moitié : si on veut
 vraiment découper un rond-point, dans ce cas il faut aller au bout de la
 démarche et le faire à chaque connexion de route, et pas seulement 2
 sorties sur 4 ...


 Sylvain


 Le 16 juillet 2014 12:14, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Le 16 juillet 2014 11:52, Pieren pier...@gmail.com a écrit :

 2014-07-16 11:26 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr:

  Connaître le parcours exact du véhicule. C'est vrai que cela peut
  compliquer l'édition, mais pas de façon insurmontable, selon moi.

 Mouais, c'est en général la réponse de ceux qui font ces découpages
 lorsque le giratoire est déjà là et bien rond ;-) L'opinion peut
 changer quand il faut réparer plusieurs giratoires altérés par des
 contributeurs peu attentifs. En plus, on pourrait se retrouver avec
 des giratoires incohérents (une partie en tertiary, une autre en
 secondary, etc).


 Les incohérences de tag sont faciles à détecter et à corriger. Et pour
 redéssiner un giratoire éclaté bien rond, on peut créer un chemin
 temporaire reprenant tous les points, faire un rond avec ce chemin, puis le
 supprimer.

 Le parcours exact du véhicule peut se reconstituer par logiciel.
 Mais c'est vrai que ça nécessite un peu de travail pour ceux qui
 veulent exploiter ces données. Mais il vaut mieux donner ce peu de
 travail supplémentaire aux data consumers, aux experts plutôt qu'aux
 contributeurs qui sont, pour leur immense majorité, des débutants.


 Cet argument me convainc davantage que celui de la difficulté d'édition.
 Peut-être que je ne couperai plus les giratoires à l'avenir...

 PY

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



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


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

[OSM-talk-fr] centre de jeux pour enfants

[Pierre-Yves Berrard]

Comment renseigner un centre de jeux pour enfants ? (avec structure
gonflables, activités, anniversaires...)

leisure=playground ne me semble pas adapté car c'est pour l'extérieur,
public et en général gratuit.
Là, c'est aussi à l'intérieur et payant.

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

Re: [OSM-talk-fr] centre de jeux pour enfants

[Paul Mallet]

Juste une suggestion :

building=yes
leisure=playground
fee=yes

Paul MALLET


Le 16 juillet 2014 13:54, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Comment renseigner un centre de jeux pour enfants ? (avec structure
 gonflables, activités, anniversaires...)

 leisure=playground ne me semble pas adapté car c'est pour l'extérieur,
 public et en général gratuit.
 Là, c'est aussi à l'intérieur et payant.

 PY (the_knife)

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


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

Re: [OSM-talk-fr] Relation route et giratoire

[Marc SIBERT]

Halte à la vente à la découpe !
Mettez fin au charcutage des rond-points !

-1

PS : N'oubliez pas que dans les modèles routables, les RP sont généralement
réduit à un noeud. Les RP n'ont d'intérêt que pour le rendu alors il est
bien inutile de les découper. (et ça rend sa maintenance bien difficile).


Le 16 juillet 2014 11:39, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Bonjour,

 Le 16 juillet 2014 11:26, Stéphane Péneau stephane.pen...@wanadoo.fr a
 écrit :

 Est-ce qu'on est d'accord sur le fait que sur les relations route, il
 est inutile de découper les giratoires en plusieurs morceaux ?

 Non. On coupe bien une rue empruntée seulement pour moitié par le
 véhicule, alors pourquoi faire une distinction ?


 Je ne vois vraiment pas l'intérêt de ce morcelage qui complique vraiment
 l'édition.

 Connaître le parcours exact du véhicule. C'est vrai que cela peut
 compliquer l'édition, mais pas de façon insurmontable, selon moi.

 PY (the_knife)

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




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

Re: [OSM-talk-fr] Relation route et giratoire

[Sylvain Maillard]

Complètement d'accord avec Marc, pour moi il n'y a pas à découper un
rond-point, la clef junction indique bien que c'est un élément
particulier du réseau routier, c'est aux moteurs de calcul
d'itinéraire/autre de faire leurs calculs correctement, comme pour
n'importe quel autre croisement de routes  !

je voulais juste pointer l'incohérence dans l'exemple précédent (
http://www.openstreetmap.org/?mlat=47.21463mlon=-1.53777#map=18/47.21463/-1.53777)
avec une découpe en 2 seulement :  si on veut être cohérent il faut
découper en 4 morceaux, il n'y a pas de raison de faciliter le passage de
la Rue du progrès au Mail Pablo Picasso et pas de la Rue marcel Paul
à la Rue de l'Allier ...
le risque bien réel c'est d'en arriver à quelque chose comme
https://www.openstreetmap.org/way/161769125 (et donc
https://www.openstreetmap.org/relation/1807216#map=19/47.21359/-1.53976)


Sylvain


Le 16 juillet 2014 14:09, Marc SIBERT m...@sibert.fr a écrit :

 Halte à la vente à la découpe !
 Mettez fin au charcutage des rond-points !

 -1

 PS : N'oubliez pas que dans les modèles routables, les RP sont
 généralement réduit à un noeud. Les RP n'ont d'intérêt que pour le rendu
 alors il est bien inutile de les découper. (et ça rend sa maintenance bien
 difficile).


 Le 16 juillet 2014 11:39, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Bonjour,

 Le 16 juillet 2014 11:26, Stéphane Péneau stephane.pen...@wanadoo.fr a
 écrit :

 Est-ce qu'on est d'accord sur le fait que sur les relations route, il
 est inutile de découper les giratoires en plusieurs morceaux ?

 Non. On coupe bien une rue empruntée seulement pour moitié par le
 véhicule, alors pourquoi faire une distinction ?


 Je ne vois vraiment pas l'intérêt de ce morcelage qui complique vraiment
 l'édition.

 Connaître le parcours exact du véhicule. C'est vrai que cela peut
 compliquer l'édition, mais pas de façon insurmontable, selon moi.

 PY (the_knife)


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

Re: [OSM-talk-fr] Relation route et giratoire

[V de Chateau-Thierry]

Bonjour,

 PS : N'oubliez pas que dans les modèles routables, les RP sont généralement 
 réduit à un
 noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien inutile de 
 les
 découper. (et ça rend sa maintenance bien difficile).

Oh que non. C'était vrai au XXè siècle, ça :)
Aujourd'hui dans les BD du commerce, d'une échelle de saisie comparable à OSM 
(Here,
TomTom, Google) les rond-points sont décrits en détaillant chaque entrée, 
chaque sortie,
et toutes les portions qui forment la partie circulaire sont découpées à chaque
intersection. Donc dire (plus haut dans ce fil) : Les logiciels de navigation 
le font
déjà très bien c'est oublier qu'ils s'appuient sur un graphe où chaque 
croisement de
plus de 2 ways occasionne un découpage. Un rond-point basique à 4 entrées sera 
composé
de 8 ways.
Je suis d'accord qu'un enjeu est de garder la marche d'entrée la plus basse 
possible pour
la contribution. Mais pousser le curseur à l'extrême opposé en supposant que 
les
logiciels consommateurs sauront se dépatouiller seuls, ça n'est pas forcément 
non plus
nous rendre service pour la démocratisation de l'usage d'OSM.

vincent (découpeur de rond-points sauf quand le bus fait un tour complet...)

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

Re: [OSM-talk-fr] Relation route et giratoire

[Francescu GAROBY]

La question est alors : vaut-il mieux un rond-point complet (en 1 seule
way), que les logiciels de navigation découperont en autant de ways qu'il y
a d'E/S sur ledit rond-point, ou vaut-il mieux prémâcher le travail, au
risque de créer des erreurs comme celle signalée par Sylvain
https://www.openstreetmap.org/relation/1807216#map=19/47.21359/-1.53976 ?

Perso, je pense qu'il est plus facile, pour un logiciel, de découper
quelque chose de fermé selon des points bien précis, que de souder des ways
qui se touchent, car il pourrait ne pas souder les bons morceaux (les
ronds-points n'ont pas toujours de belles formes circulaires).
Du coup, je plaide pour les ronds-points en 1 seule way !

Francescu, qui a autrefois découpé les ronds-points de Caen, quand il y
traçait les lignes de bus


Le 16 juillet 2014 15:10, V de Chateau-Thierry v...@laposte.net a écrit :

 Bonjour,

  PS : N'oubliez pas que dans les modèles routables, les RP sont
 généralement réduit à un
  noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien
 inutile de les
  découper. (et ça rend sa maintenance bien difficile).

 Oh que non. C'était vrai au XXè siècle, ça :)
 Aujourd'hui dans les BD du commerce, d'une échelle de saisie comparable à
 OSM (Here,
 TomTom, Google) les rond-points sont décrits en détaillant chaque entrée,
 chaque sortie,
 et toutes les portions qui forment la partie circulaire sont découpées à
 chaque
 intersection. Donc dire (plus haut dans ce fil) : Les logiciels de
 navigation le font
 déjà très bien c'est oublier qu'ils s'appuient sur un graphe où chaque
 croisement de
 plus de 2 ways occasionne un découpage. Un rond-point basique à 4 entrées
 sera composé
 de 8 ways.
 Je suis d'accord qu'un enjeu est de garder la marche d'entrée la plus
 basse possible pour
 la contribution. Mais pousser le curseur à l'extrême opposé en supposant
 que les
 logiciels consommateurs sauront se dépatouiller seuls, ça n'est pas
 forcément non plus
 nous rendre service pour la démocratisation de l'usage d'OSM.

 vincent (découpeur de rond-points sauf quand le bus fait un tour
 complet...)

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




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

Re: [OSM-talk-fr] Relation route et giratoire

[Jo]

Moi je continuerai de les découper. Le bus n'emprunte le rond-point que du
chemin d'entrée jusqu'au chemin de sortie et pas le reste.

http://www.openstreetmap.org/#map=18/50.71124/4.60632layers=T
http://www.openstreetmap.org/#map=18/50.65964/4.61581layers=T


Pour rendre rond:

Ctrl-f:

inview child junction=roundabout
Shift-O

Aucun problème avec JOSM.

Jo


2014-07-16 15:10 GMT+02:00 V de Chateau-Thierry v...@laposte.net:

 Bonjour,

  PS : N'oubliez pas que dans les modèles routables, les RP sont
 généralement réduit à un
  noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien
 inutile de les
  découper. (et ça rend sa maintenance bien difficile).

 Oh que non. C'était vrai au XXè siècle, ça :)
 Aujourd'hui dans les BD du commerce, d'une échelle de saisie comparable à
 OSM (Here,
 TomTom, Google) les rond-points sont décrits en détaillant chaque entrée,
 chaque sortie,
 et toutes les portions qui forment la partie circulaire sont découpées à
 chaque
 intersection. Donc dire (plus haut dans ce fil) : Les logiciels de
 navigation le font
 déjà très bien c'est oublier qu'ils s'appuient sur un graphe où chaque
 croisement de
 plus de 2 ways occasionne un découpage. Un rond-point basique à 4 entrées
 sera composé
 de 8 ways.
 Je suis d'accord qu'un enjeu est de garder la marche d'entrée la plus
 basse possible pour
 la contribution. Mais pousser le curseur à l'extrême opposé en supposant
 que les
 logiciels consommateurs sauront se dépatouiller seuls, ça n'est pas
 forcément non plus
 nous rendre service pour la démocratisation de l'usage d'OSM.

 vincent (découpeur de rond-points sauf quand le bus fait un tour
 complet...)

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

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

Re: [OSM-talk-fr] Relation route et giratoire

[V de Chateau-Thierry]

 De : Francescu GAROBY

 La question est alors : vaut-il mieux un rond-point complet (en 1 seule way), 
 que les
 logiciels de navigation découperont en autant de ways qu'il y a d'E/S sur 
 ledit rond-
 point, ou vaut-il mieux prémâcher le travail, au risque de créer des erreurs 
 comme
 celle signalée par Sylvain ?

Les erreurs sur les rond-points ne sont pas cantonnées à un mauvais découpage :
http://osmose.openstreetmap.fr/fr/map/#zoom=9lat=47.674lon=0.666layer=Mapnikoverlays=
FFFTitem=1050%2C2010%2C4020level=1%2C2%2C3tags=fixable=bbox=-0.57025
90942382811%2C43.172133836120246%2C-0.1517486572265625%2C43.37211393444652

Donc oui bien sûr, en découpant les rond-point il y a un risque de provoquer 
des erreurs.
Mais c'est tellement vrai pour à peu près tout dans OSM que je n'en ferai pas 
un argument
spécifiquement sur notre sujet. 

 Perso, je pense qu'il est plus facile, pour un logiciel, de découper quelque 
 chose de 
 fermé selon des points bien précis, que de souder des ways qui se touchent, 
 car il 
 pourrait ne pas souder les bons morceaux (les ronds-points n'ont pas toujours 
 de belles
 formes circulaires).

Face à un rond-point découpé, quel besoin justifierait comme tu le dis de 
recoller les
morceaux ? Je ne dis pas qu'il n'y en a pas, mais pour les besoins les plus 
triviaux
(carto, calcul d'itinéraire) ça ne se justifie pas.

vincent

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

Re: [OSM-talk-fr] Relation route et giratoire

[Christophe Merlet]

Le 16/07/2014 15:31, Jo a écrit :
 Moi je continuerai de les découper. Le bus n'emprunte le rond-point que
 du chemin d'entrée jusqu'au chemin de sortie et pas le reste.
 
 http://www.openstreetmap.org/#map=18/50.71124/4.60632layers=T
 http://www.openstreetmap.org/#map=18/50.65964/4.61581layers=T

Dans la même logique, découpe toutes les routes en 2 car le bus
n'utilise qu'une seule voie sur les 2.

Là tu découpe le rond-point typiquement pour le rendu et non pas à cause
d'un logiciel de routage défaillant. Comme dit précédemment, un
rond-point est une jonction et peu facilement être traité comme tel.


 Pour rendre rond:
 
 Ctrl-f:
 
 inview child junction=roundabout
 Shift-O
 
 Aucun problème avec JOSM.
 
 Jo
 
 
 2014-07-16 15:10 GMT+02:00 V de Chateau-Thierry v...@laposte.net
 mailto:v...@laposte.net:
 
 Bonjour,
 
  PS : N'oubliez pas que dans les modèles routables, les RP sont
 généralement réduit à un
  noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien
 inutile de les
  découper. (et ça rend sa maintenance bien difficile).
 
 Oh que non. C'était vrai au XXè siècle, ça :)
 Aujourd'hui dans les BD du commerce, d'une échelle de saisie
 comparable à OSM (Here,
 TomTom, Google) les rond-points sont décrits en détaillant chaque
 entrée, chaque sortie,
 et toutes les portions qui forment la partie circulaire sont
 découpées à chaque
 intersection. Donc dire (plus haut dans ce fil) : Les logiciels de
 navigation le font
 déjà très bien c'est oublier qu'ils s'appuient sur un graphe où
 chaque croisement de
 plus de 2 ways occasionne un découpage. Un rond-point basique à 4
 entrées sera composé
 de 8 ways.
 Je suis d'accord qu'un enjeu est de garder la marche d'entrée la
 plus basse possible pour
 la contribution. Mais pousser le curseur à l'extrême opposé en
 supposant que les
 logiciels consommateurs sauront se dépatouiller seuls, ça n'est pas
 forcément non plus
 nous rendre service pour la démocratisation de l'usage d'OSM.
 
 vincent (découpeur de rond-points sauf quand le bus fait un tour
 complet...)
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 


-- 
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Relation route et giratoire

[Etienne Trimaille]

Le 16 juillet 2014 15:20, Francescu GAROBY windu...@gmail.com a écrit :

 La question est alors : vaut-il mieux un rond-point complet (en 1 seule
 way), que les logiciels de navigation découperont en autant de ways qu'il y
 a d'E/S sur ledit rond-point, ou vaut-il mieux prémâcher le travail, au
 risque de créer des erreurs comme celle signalée par Sylvain
 https://www.openstreetmap.org/relation/1807216#map=19/47.21359/-1.53976
 ?



OSM a toujours été de la donnée brute, qu'il faut raffiner avant
utilisation. Il y a tant d'hétérogénéité dans les descriptions tant
sémantiques que géométriques.
N'importe quel logiciel de routage peut découper un giratoire normalement,
pour reprendre l'exemple de Sylvain que j'ai tenté de refaire en quelques
points : http://osrm.at/8uI http://osrm.at/8uD
Oui c'est sur, cela empêche d'afficher directement les relations telles
quelles si il y a des pré-traitements à faire.

Il m'arrive plusieurs fois de vouloir éditer un carrefour et en
téléchargeant les données, je m'aperçois que j'ai plein de relations
route dans JOSM. Il devient fatiguant de prendre connaissance du réseau
de bus pour éviter de tout casser, juste pour ajouter une petite voie de
service.

Ceci dit, je comprends chez certains le point de vue pour découper un
giratoire. On le fait bien pour les rues quand le bus tourne, alors
pourquoi pas pour un giratoire ?

A saucissonner les voies en X morceaux juste pour faire tourner un bus dans
la rue adjacente, on complique de plus en plus l'édition.
Les relations type=route fonctionne en mode tronçon par tronçon pour
décrire l'itinéraire. Peut-être qu'il faut réfléchir à un mode point de
passage : indiquer les intersections/changements de direction du bus,
indépendamment du way (autrement dit de la géométrie de la rue)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation route et giratoire

[Frédéric Rodrigo]

Le 16/07/2014 15:41, V de Chateau-Thierry a écrit :



De : Francescu GAROBY

La question est alors : vaut-il mieux un rond-point complet (en 1 seule way), 
que les
logiciels de navigation découperont en autant de ways qu'il y a d'E/S sur ledit 
rond-
point, ou vaut-il mieux prémâcher le travail, au risque de créer des erreurs 
comme
celle signalée par Sylvain ?


Les erreurs sur les rond-points ne sont pas cantonnées à un mauvais découpage :
http://osmose.openstreetmap.fr/fr/map/#zoom=9lat=47.674lon=0.666layer=Mapnikoverlays=
FFFTitem=1050%2C2010%2C4020level=1%2C2%2C3tags=fixable=bbox=-0.57025
90942382811%2C43.172133836120246%2C-0.1517486572265625%2C43.37211393444652


Le bon lien pour les erreurs sur les giratoires, il y a un filtre osmose 
pour ça :

http://osmose.openstreetmap.fr/fr/map/#item=level=1%2C2%2C3tags=roundabout
(et oui ça en fait encore plus)


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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Christian Quest]

Le 16 juillet 2014 11:03, Pieren pier...@gmail.com a écrit :


 Absolument. D'ailleurs j'ai mis le sujet de cette relation type=network
 sur le tapis:

 http://gis.19327.n5.nabble.com/quot-Relations-are-not-categories-quot-excepted-for-quot-type-network-quot-td5811467.html

 Certains contributeurs ont une tendance naturelle à utiliser les relations
 pour éviter de faire des requêtes spatiales un peu compliqué (surtout si
 c'est pour collecter des relations de type route). Il faut y mettre un peu
 le hola sinon tous les objets qui peuvent partager des caractéristiques
 communes se retrouveront tôt ou tard dans des relations (comme certains qui
 créent des tonnes de categories dans le wiki)



Et là, la requête n'est même pas spatiale... reposer sur ces méta relations
c'est s'exposer à encore plus de problème. Plus on a d'indirections pour
accéder aux données utiles, plus on a de risque que ça soit cassé. C'est
beau mais fragile. A mon avis le schéma de transport public est déjà assez
complexe pour ne pas en rajouter une couche.

network + operator permettent de s'y retrouver.

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

Re: [OSM-talk-fr] centre de jeux pour enfants

[Christian Quest]

plutôt indoor=yes que building...


Le 16 juillet 2014 13:58, Paul Mallet cont...@paulmallet.net a écrit :

 Juste une suggestion :

 building=yes
 leisure=playground
 fee=yes

 Paul MALLET


 Le 16 juillet 2014 13:54, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Comment renseigner un centre de jeux pour enfants ? (avec structure
 gonflables, activités, anniversaires...)

 leisure=playground ne me semble pas adapté car c'est pour l'extérieur,
 public et en général gratuit.
 Là, c'est aussi à l'intérieur et payant.

 PY (the_knife)

 ___
 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




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

Re: [OSM-talk-fr] Relation route et giratoire

[Jo]

Dès le moment que tu trouveras quelqu'un qui peut rendre tes routes où
seulement les intersections/changements sont mappés, il y aura une chance
de proposer une telle façon de les mapper ainsi.

Pour moi il reste le problème: comment télécharger cela? Maintenant j'ai
une requête Overpass qui me donne une 'squelette' avec tous les arrêts,
chemins qui font partie des routes, abris, etc. Il faudrait déjà un noeud
'indicateur' de chaque chemin dans la relation route, mais si un chemin est
découpé, l'un des deux tronçons ne fera plus partie de la relation route.

Et puis, comment visualiser ces routes en JOSM avec du MAPCSS?

`Quant à ton problème de multitude de relations routes sur les chemins, il
y a une autre solution: rendre une hiërarchie de relations routes, c'est
dire que ces routes peuvent être composé de segments de routes plus
courtes. Mais tant que ces routes ne sont pas rendues, nous continuerons de
mapper ça de façon labourieuse et difficile à gérer.

Un avantage de la façon employée aujourd'hui: c'est clair. On a tout de
suite vu si la relation route est continue (si on groupe tous les chemins
ensemble, bien sûr, ce n'est pas le cas si les chemins, les stop_position
et les arrêts sont décrits dans l'ordre qu'on les passe). Mais c'est vrai
que c'est lourd.

Polyglot


2014-07-16 16:03 GMT+02:00 Etienne Trimaille etienne.trimai...@gmail.com:

 Le 16 juillet 2014 15:20, Francescu GAROBY windu...@gmail.com a écrit :

 La question est alors : vaut-il mieux un rond-point complet (en 1 seule
 way), que les logiciels de navigation découperont en autant de ways qu'il y
 a d'E/S sur ledit rond-point, ou vaut-il mieux prémâcher le travail, au
 risque de créer des erreurs comme celle signalée par Sylvain
 https://www.openstreetmap.org/relation/1807216#map=19/47.21359/-1.53976
 ?



 OSM a toujours été de la donnée brute, qu'il faut raffiner avant
 utilisation. Il y a tant d'hétérogénéité dans les descriptions tant
 sémantiques que géométriques.
 N'importe quel logiciel de routage peut découper un giratoire normalement,
 pour reprendre l'exemple de Sylvain que j'ai tenté de refaire en quelques
 points : http://osrm.at/8uI http://osrm.at/8uD
 Oui c'est sur, cela empêche d'afficher directement les relations telles
 quelles si il y a des pré-traitements à faire.

 Il m'arrive plusieurs fois de vouloir éditer un carrefour et en
 téléchargeant les données, je m'aperçois que j'ai plein de relations
 route dans JOSM. Il devient fatiguant de prendre connaissance du réseau
 de bus pour éviter de tout casser, juste pour ajouter une petite voie de
 service.

 Ceci dit, je comprends chez certains le point de vue pour découper un
 giratoire. On le fait bien pour les rues quand le bus tourne, alors
 pourquoi pas pour un giratoire ?

 A saucissonner les voies en X morceaux juste pour faire tourner un bus
 dans la rue adjacente, on complique de plus en plus l'édition.
 Les relations type=route fonctionne en mode tronçon par tronçon pour
 décrire l'itinéraire. Peut-être qu'il faut réfléchir à un mode point de
 passage : indiquer les intersections/changements de direction du bus,
 indépendamment du way (autrement dit de la géométrie de la rue)

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


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

Re: [OSM-talk-fr] Relation route et giratoire

[Francescu GAROBY]

 Un avantage de la façon employée aujourd'hui: c'est clair. On a tout de
 suite vu si la relation route est continue (si on groupe tous les chemins
 ensemble, *bien sûr, ce n'est pas le cas si les chemins, les
 stop_position et les arrêts sont décrits dans l'ordre qu'on les passe*).
 Mais c'est vrai que c'est lourd.

J'avais essayé de modifier JOSM, pour résoudre ce problème, justement. Mais
je n'ai pas encore réussi... :-/
(mais je ne désespère pas d'y arriver un jour)

Francescu

Le 16 juillet 2014 17:14, Jo winfi...@gmail.com a écrit :

 Dès le moment que tu trouveras quelqu'un qui peut rendre tes routes où
 seulement les intersections/changements sont mappés, il y aura une chance
 de proposer une telle façon de les mapper ainsi.

 Pour moi il reste le problème: comment télécharger cela? Maintenant j'ai
 une requête Overpass qui me donne une 'squelette' avec tous les arrêts,
 chemins qui font partie des routes, abris, etc. Il faudrait déjà un noeud
 'indicateur' de chaque chemin dans la relation route, mais si un chemin est
 découpé, l'un des deux tronçons ne fera plus partie de la relation route.

 Et puis, comment visualiser ces routes en JOSM avec du MAPCSS?

 `Quant à ton problème de multitude de relations routes sur les chemins, il
 y a une autre solution: rendre une hiërarchie de relations routes, c'est
 dire que ces routes peuvent être composé de segments de routes plus
 courtes. Mais tant que ces routes ne sont pas rendues, nous continuerons de
 mapper ça de façon labourieuse et difficile à gérer.

 Un avantage de la façon employée aujourd'hui: c'est clair. On a tout de
 suite vu si la relation route est continue (si on groupe tous les chemins
 ensemble, bien sûr, ce n'est pas le cas si les chemins, les stop_position
 et les arrêts sont décrits dans l'ordre qu'on les passe). Mais c'est vrai
 que c'est lourd.

 Polyglot


 2014-07-16 16:03 GMT+02:00 Etienne Trimaille etienne.trimai...@gmail.com
 :

 Le 16 juillet 2014 15:20, Francescu GAROBY windu...@gmail.com a écrit :

 La question est alors : vaut-il mieux un rond-point complet (en 1 seule
 way), que les logiciels de navigation découperont en autant de ways qu'il y
 a d'E/S sur ledit rond-point, ou vaut-il mieux prémâcher le travail, au
 risque de créer des erreurs comme celle signalée par Sylvain
 https://www.openstreetmap.org/relation/1807216#map=19/47.21359/-1.53976
 ?



 OSM a toujours été de la donnée brute, qu'il faut raffiner avant
 utilisation. Il y a tant d'hétérogénéité dans les descriptions tant
 sémantiques que géométriques.
  N'importe quel logiciel de routage peut découper un giratoire
 normalement, pour reprendre l'exemple de Sylvain que j'ai tenté de refaire
 en quelques points : http://osrm.at/8uI http://osrm.at/8uD
 Oui c'est sur, cela empêche d'afficher directement les relations telles
 quelles si il y a des pré-traitements à faire.

 Il m'arrive plusieurs fois de vouloir éditer un carrefour et en
 téléchargeant les données, je m'aperçois que j'ai plein de relations
 route dans JOSM. Il devient fatiguant de prendre connaissance du réseau
 de bus pour éviter de tout casser, juste pour ajouter une petite voie de
 service.

 Ceci dit, je comprends chez certains le point de vue pour découper un
 giratoire. On le fait bien pour les rues quand le bus tourne, alors
 pourquoi pas pour un giratoire ?

 A saucissonner les voies en X morceaux juste pour faire tourner un bus
 dans la rue adjacente, on complique de plus en plus l'édition.
 Les relations type=route fonctionne en mode tronçon par tronçon pour
 décrire l'itinéraire. Peut-être qu'il faut réfléchir à un mode point de
 passage : indiquer les intersections/changements de direction du bus,
 indépendamment du way (autrement dit de la géométrie de la rue)

 ___
 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




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

Re: [OSM-talk-fr] Edition des relations pour les transports en commun (ville de Nantes)

[Jo]

Je suis d'accord qu'il ne faut pas utiliser de relation network pour le PT,
les tags network/operator suffisen. Mais tu as attaqué l'usage de cette
relation pour des réseaux de noeuds numérotés cyclables/piétons, qui n'a
rien à voir avec le PT.

Jo


2014-07-16 11:03 GMT+02:00 Pieren pier...@gmail.com:


 2014-07-16 10:10 GMT+02:00 Francescu GAROBY windu...@gmail.com:

 Si tu veux regrouper les relations d'un même réseau/opérateur, utilise les
 tags 'network' et 'operator' et donne-leur la même valeur pour chaque
 relation, tout simplement...
 Ici, c'est 'network=TAN' et 'operator=SEMITAN', si j'en crois les
 relations déjà existantes.

 Francescu


 Absolument. D'ailleurs j'ai mis le sujet de cette relation type=network
 sur le tapis:

 http://gis.19327.n5.nabble.com/quot-Relations-are-not-categories-quot-excepted-for-quot-type-network-quot-td5811467.html

 Certains contributeurs ont une tendance naturelle à utiliser les relations
 pour éviter de faire des requêtes spatiales un peu compliqué (surtout si
 c'est pour collecter des relations de type route). Il faut y mettre un peu
 le hola sinon tous les objets qui peuvent partager des caractéristiques
 communes se retrouveront tôt ou tard dans des relations (comme certains qui
 créent des tonnes de categories dans le wiki)

 Pieren

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


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

Re: [OSM-talk-fr] Relation route et giratoire

[Philippe Verdy]

Je suis aussi d'accord. Même si pour un découpage cantonal du'une commune
on réutilise les axes des voies, le découpage indiqué dans les texte n'a
pas de précision métrique et rajouter un tracer ne sert pas à grand chose,
et en aucun cas il n'indique un découpage de rond-point.

Pour ce genre de cas, il suffit juste de tracer le morceau de frontière
cantonale qui manque pour traverser le rond-point et reprendre plus loin
sur la bonne voie. Il n'est jamais nécessaire de découper le rond-point.

--

Pour un routage il est même intéressant d'en garder l'intégrité pour que le
logiciel affiche correctement que c'est un rond-point (avec la priorité à
gauche au lieu de la droite et le placement du véhicule sur la voir
extérieure sauf pour tourner à gauche, et les règles d'usage du clignotant
pour se replacer sur la voie extérieure avant de sortir (le véhicule qui
fait cette maneuvre est normalement prioritaire. Un rond-point est une
entité à part d'une route normale. Ce n'est pas une simple place, il n'y a
pas de feux et c'est aménagé de façon qu'on n'a à surveiller en principe
que sa gauche pour entrer et que sa droite pour sortir, le tout avec une
vitesse nécessairement réduite, et pourtant c'est bien plus fluide qu'un
carrefour avec feux et moins accidentogène.

Nombre de villes suppriment tous les carrefours avec priorités à droite ou
route prioritaire, stops, feux etc.. pour remplacer par des ronds-points et
si au début les résidents sont réticents, ils voient tous qu'on roule plus
facilement et en meilleure sécurité, et les résidents à coté sont moins
gênés par le bruit et la pollution. la partie centrale permet aussi un
aménagement d'espace vert qui embellit. Tout le monde est content et on
évite aussi les coûteux radars (couteux à installer et entretenir, ou
coûteux en moyens humains pour la contrôles épisodiques que la gendarmerie
n'a pas les moyens de faire partout assez souvent).

La France est championne des ronds-points et des pays voisins qui n'en
mettaient qu'épisodiquement commencent eux aussi à en installer un peu
partout Et ces ronds-points qui étaient accusés d'être dangereux ne le sont
plus. Notre Tour de France diffusé dans le monde entier montre aussi que
c'est bien aussi pour les cyclistes, et plus protecteurs que les
intersections classiques. Certains villages en ont mis à tous leurs
carrefours en virant les anciens feux et tous les stops, il n'y a plus
aucune route prioritaire, et pas besoin non plus des dos d'âne très
dangereux pour les deux-roues qu'ils déséquilibrent facilement (et encore
plus facilement à vitesse réduite).

Un rond-point fonctionne comme un tout indivisible. Les rares cas où un
rond(point a été découpé en mettant une voie centrale par exemple pour les
bus, ont été défaits car c'était aussi dangereux pour les usagers obligés
de faire le tour. Ces voies accélérés sur une direction prioritaire sont
plutôt remplacées par des souterrains sur certains axes, parfois réservés
aux bus (ou véhicules d'urgence) qui les ont en site propre. Un rond-point
coûte cher à aménager une seule fois parce que l'emprise de terrain est un
peu supérieure (mais souvent su c'est pour remplacer un carrefour avec feux
les voies d'approche avaient déjà nécessité l'acquisition de ce terrain
pour les voies d'attente au feu. Son entretien n'est pas plus élevé que
lentetien des feux et panneaux d'un carrefour classique.

Ils sont même mieux et plus facilement représentés sur les rendus carto à
différents niveaux de zoom (et la plupart ont aussi un nom, seul le numéro
de référence est ambigu, on prend en général le numéro de la rue qui se
prolonge des deux côtés et qui est principale par rapport au autres, sinon
on prend les deux numéros su ce sont deux départementales; en ville où ce
ne sont que des rues communales, on ne peut pas mettre les deux noms, c'est
ne nom du rond-point qui remplace; ne pas découper un rond-point préserve
la continuité de la rue en assimilant le rond-point entier à un seul noeud
virtuel).

Ils sont un tout et même pour le routage on est parfois amené à ne pas
pouvoir sortir et refaire un tour pour ne pas s'arrêter au milieu, c'est
plus rapide, moins dangereux, et plus sûr que de tenter un demi-tour après
s'être trompé de chemin aux carrefours classiques (où la plupart du temps
il est même impossible de faire un demi-tour en sécurité (et souvent
interdit) alors que c'est très facile avec les ronds-points.

Bref, vive les ronds-points indivisibles, infranchissables au milieu. Ils
sont des éléments de repérage très identifiables sur une carte et le
terrain même sans en connaitre le nom, on les voit de loin.

Il reste cependant à convaincre les conducteurs de les emprunter comme il
faut (placement sur la voie centrale pour tourner à gauche et clignotant
gauche tant qu'on y est, et usage du clignotant à droite uniquement à
partie de la voie avant la sortie ou juste avant d'entrer dans le
rond-point dont on prend la première sortie à droite, sinon on laisse la
voie de droite à 

Re: [OSM-talk-fr] Relation route et giratoire

[Vincent Pottier]

Le 16/07/2014 15:10, V de Chateau-Thierry a écrit :

Bonjour,


PS : N'oubliez pas que dans les modèles routables, les RP sont généralement 
réduit à un
noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien inutile de les
découper. (et ça rend sa maintenance bien difficile).

Oh que non. C'était vrai au XXè siècle, ça :)
Aujourd'hui dans les BD du commerce, d'une échelle de saisie comparable à OSM 
(Here,
TomTom, Google) les rond-points sont décrits en détaillant chaque entrée, 
chaque sortie,
et toutes les portions qui forment la partie circulaire sont découpées à chaque
intersection. Donc dire (plus haut dans ce fil) : Les logiciels de navigation 
le font
déjà très bien c'est oublier qu'ils s'appuient sur un graphe où chaque 
croisement de
plus de 2 ways occasionne un découpage. Un rond-point basique à 4 entrées sera 
composé
de 8 ways.
Si les bases du commerce ont besoin de ronds-points éclatés, je dois 
avoir LE GPS intelligent.
Il sait fonctionner en navigation routière avec des ronds-points entiers 
issus d'OSM.

Il sait bien m'indiquer la sortie à prendre dans le rond-point.

Donc je ressoude les ronds-points parce que je suis contre le 
nivellement par le bas des données OSM.


Pour info, LE GPS en question est un Dakota 20.
--
FrViPofm

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

Re: [OSM-talk-fr] Relation route et giratoire

[Pierre-Yves Berrard]

Toutes ces considérations sur le routage seraient valables si on avait un
modèle de relation route avec des points de passage (comme exposé par
Étienne).
Or ce n'est pas le cas : la route est censée être entièrement déterminée
par des segments. À aucun moment je ne vois dans la doc, l'itinéraire est
défini par les segments de routes, *sauf sur les giratoires où il faudra
faire appel à un algorithme de routage*.
Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne vois
pas comment,* avec le modèle actuel*, faire sans tronçonner ces maudits
giratoires.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation route et giratoire

[Christian Quest]

Ne pas confondre les calcul d'itinéraires qui n'ont aucunement besoin de
cette segmentation (heureusement) et les relations type=route qui décrivent
les itinéraires de bus...

Je préfère moi aussi les rond-points d'un bloc pour les raisons exposées...
+1 pour le consensus sans le saucissonnage ;)


Le 16 juillet 2014 22:34, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :

 Toutes ces considérations sur le routage seraient valables si on avait un
 modèle de relation route avec des points de passage (comme exposé par
 Étienne).
 Or ce n'est pas le cas : la route est censée être entièrement déterminée
 par des segments. À aucun moment je ne vois dans la doc, l'itinéraire est
 défini par les segments de routes, *sauf sur les giratoires où il faudra
 faire appel à un algorithme de routage*.
 Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne vois
 pas comment,* avec le modèle actuel*, faire sans tronçonner ces maudits
 giratoires.

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




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

Re: [OSM-talk-fr] Relation route et giratoire

[Paul Mallet]

+1, on ne tag pas pour le rendu, mais on va tagger en fonction des algos de
routage ?

Si en vrai le bus ne fait pas le tour complet du rond point, alors c'est +
précis (et donc forcément + complexe, et alors ?) de spécifier la portion
empruntée par celui-ci !

Paul
Le 16 juil. 2014 22:34, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
a écrit :

 Toutes ces considérations sur le routage seraient valables si on avait un
 modèle de relation route avec des points de passage (comme exposé par
 Étienne).
 Or ce n'est pas le cas : la route est censée être entièrement déterminée
 par des segments. À aucun moment je ne vois dans la doc, l'itinéraire est
 défini par les segments de routes, *sauf sur les giratoires où il faudra
 faire appel à un algorithme de routage*.
 Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne vois
 pas comment,* avec le modèle actuel*, faire sans tronçonner ces maudits
 giratoires.

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


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

Re: [OSM-talk-fr] Relation route et giratoire

[Pierre-Yves Berrard]

Je ne confonds pas, je dis comme toi qu'on ne parle pas ici de routage mais
d'itineraires de type=route.

Le 16 juillet 2014 22:40, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Ne pas confondre les calcul d'itinéraires qui n'ont aucunement besoin de
 cette segmentation (heureusement) et les relations type=route qui décrivent
 les itinéraires de bus...

 Je préfère moi aussi les rond-points d'un bloc pour les raisons
 exposées... +1 pour le consensus sans le saucissonnage ;)


 Le 16 juillet 2014 22:34, Pierre-Yves Berrard 
 pierre.yves.berr...@gmail.com a écrit :

 Toutes ces considérations sur le routage seraient valables si on avait un
 modèle de relation route avec des points de passage (comme exposé par
 Étienne).
 Or ce n'est pas le cas : la route est censée être entièrement déterminée
 par des segments. À aucun moment je ne vois dans la doc, l'itinéraire est
 défini par les segments de routes, *sauf sur les giratoires où il faudra
 faire appel à un algorithme de routage*.
 Donc, bien que cela soit coûteux en nombre d'objets dans osm, je ne vois
 pas comment,* avec le modèle actuel*, faire sans tronçonner ces maudits
 giratoires.

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




 --
 Christian Quest - OpenStreetMap France

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


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

[OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)

[David Crochet]

Bonjour

Voici des extrait d'en-tête de 2 courriels doublonnés :


X-ProXaD-SC: state=HAM score=0
Received: from localhost ([::1]:60917 helo=shenron.openstreetmap.org)
by shenron.openstreetmap.org with esmtp (Exim 4.76)
(envelope-from talk-fr-boun...@openstreetmap.org)
id 1X7WI8-0008Si-Kl; Wed, 16 Jul 2014 20:59:09 +
Received: from mxrelay.makina-corpus.com ([212.129.7.19]:49405)
 by shenron.openstreetmap.org with esmtp (Exim 4.76)
 (envelope-from jeanmichel.franc...@makina-corpus.com)
 id 1X7W4V-0006Vs-1R
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 20:59:04 +
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mxrelay.makina-corpus.com (Postfix) with ESMTP id 104228131D
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:20:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at makina-corpus.com
Received: from mxrelay.makina-corpus.com ([127.0.0.1])
 by localhost (mxrelay.makina-corpus.com [127.0.0.1]) (amavisd-new, 
port 10024)

 with ESMTP id vidMKJEXV1Wn for talk-fr@openstreetmap.org;
 Wed, 16 Jul 2014 08:19:59 +0200 (CEST)
Received: from mail.makina-corpus.com (mail.makina-corpus.com 
[212.83.188.243])

 by mxrelay.makina-corpus.com (Postfix) with ESMTP id 2A4FE8129D
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:19:59 +0200 (CEST)
Received: from portinfo46.local (128-79-238-165.hfc.dyn.abo.bbox.fr
 [128.79.238.165]) (Authenticated sender: j...@makina-corpus.com)
 by mail.makina-corpus.com (Postfix) with ESMTPSA id DE2E922409
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:19:58 +0200 (CEST)
Message-ID: 53c6198e.4080...@makina-corpus.com
--




---
X-ProXaD-SC: state=HAM score=0
Received: from localhost ([::1]:54094 helo=shenron.openstreetmap.org)
by shenron.openstreetmap.org with esmtp (Exim 4.76)
(envelope-from talk-fr-boun...@openstreetmap.org)
id 1X7V2i-00075Q-PS; Wed, 16 Jul 2014 19:39:09 +
Received: from mxrelay.makina-corpus.com ([212.129.7.19]:48046)
 by shenron.openstreetmap.org with esmtp (Exim 4.76)
 (envelope-from jeanmichel.franc...@makina-corpus.com)
 id 1X7Up5-0005SF-0I
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 19:39:03 +
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mxrelay.makina-corpus.com (Postfix) with ESMTP id 104228131D
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:20:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at makina-corpus.com
Received: from mxrelay.makina-corpus.com ([127.0.0.1])
 by localhost (mxrelay.makina-corpus.com [127.0.0.1]) (amavisd-new, 
port 10024)

 with ESMTP id vidMKJEXV1Wn for talk-fr@openstreetmap.org;
 Wed, 16 Jul 2014 08:19:59 +0200 (CEST)
Received: from mail.makina-corpus.com (mail.makina-corpus.com 
[212.83.188.243])

 by mxrelay.makina-corpus.com (Postfix) with ESMTP id 2A4FE8129D
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:19:59 +0200 (CEST)
Received: from portinfo46.local (128-79-238-165.hfc.dyn.abo.bbox.fr
 [128.79.238.165]) (Authenticated sender: j...@makina-corpus.com)
 by mail.makina-corpus.com (Postfix) with ESMTPSA id DE2E922409
 for talk-fr@openstreetmap.org; Wed, 16 Jul 2014 08:19:58 +0200 (CEST)
Message-ID: 53c6198e.4080...@makina-corpus.com
-



Même Message-ID mais cela diffère entre mxrelay.makina-corpus.com 
(toujours à la même date : Wed, 16 Jul 2014 08:20:00 +0200 (CEST) ) et 
shenron.openstreetmap.org où la date diffère ensuite



Cordialement

--
David Crochet

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

[OSM-ja] 名古屋駅地下街のバリアフリーマッピングパーティー

[Shun SHIRAMATSU]

はじめまして，白松と申します．

まだ日程が確定していないのですが，8月5日か7日（あるいは，間に合えば7月末）ごろに，
名古屋駅地下街でWheelmapのようなバリアフリー情報をマッピングする
マッピングパーティーを開催したいと考えております．
名古屋駅の地下街の各店舗やそこに至る通路について，車椅子の可否や，
スロープ，手すり，盲導犬・聴導犬の可否，ベビーカーの可否など，
様々なバリアフリー情報を収集する予定です．

そこで，http://www.openstreetmap.org/way/172250247 のようにlayer=-1で
 店舗や段差等のPOIを入力していくことになると思うのですが，

(1) layer=-1で入力された店舗を地上のPOIと区別してレンダリングしたい
(2) 段差，スロープ，手すり等を適切にマッピングしたい

という要求があり，どなたかアドバイスを頂ければと思い，相談させて頂きました．

 また，技術的な要件以外にも，

(3) 現状で手元にある地下街の地図は，権利的にオープンにして良いものではなさそう
(4) マッピングパーティー後のアイディアソン・ハッカソンに繋げる課題抽出のやり方

という運用上の懸案もありまして，こちらに関しても過去の事例などご教示頂ければ幸いです．
なお，(3)に関しては，クローズドな別レイヤーの上でマッピングし，
権利上の問題やレンダリングの問題が解決されたら，OSMの方に移そうと考えております．
別レイヤーについては，現状ではeコミマップ（http://ecom-plat.jp/index.php?gid=10457）
のようなツールを使うのが簡単かと考えておりますが，
(3.1) もっとOSMとの親和性が高くて簡単なツールがあれば，お教え頂ければ幸いです．


どうぞ，よろしくお願い致します．

-- 
==
白松 俊 siram...@nitech.ac.jp
名古屋工業大学
工学部情報工学教育類／大学院情報工学専攻
新谷・大囿研究室 助教
Tel: 052-735-5129
Fax: 052-735-5584
URL: http://www-toralab.ics.nitech.ac.jp/~siramatu/
==
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 室蘭でのマッピング

[Shu Higashi]

ikiyaさん、ツールのご紹介ありがとうございます。
みやすくてよいですね。つい、あれこれ調べてしまいました。
アクティブに活動している方々をあちこちに発見して
嬉しくなりました。
東

2014/07/16 ikiya insidekiwi...@yahoo.co.jp:
 ikiyaです。

 ちょっと話題それますが、
 この地区、自分のまわりで編集してるマッパーは？と知りたいときのツール３点紹介します。


 １．「Who's around me?」
 まわりのマッパがお手軽に見れる
 http://resultmaps.neis-one.org/oooc?zoom=9lat=42.53395lon=141.11541layers=B00TFT


 ２．「WHO DID IT?」
 その地区の編集履歴をメッシュ単位で分析、メッシュ毎の編集セットとユーザーを表示してくれる
 （注意）メッシュの画面表示までやや時間かかります。

 こんな感じで見れます。
 http://2.bp.blogspot.com/-JDpLHc3eIl0/U8YIUIYNZ7I/EAo/Bl5R6dfK8Y4/s1600/WHODIDIT.png
 サイトはこちら。
 http://zverik.osm.rambler.ru/whodidit/?zoom=13lat=42.34871lon=140.96691layers=BTTage=1000


 ３．「ITO Mapper」
 マッパー別の色分け、編集の時系列表示ができる
 こんな感じで見れます。
 http://ikiya.shichihuku.com/osmmapper1/tokyo01.png
 サイトはこちら。
 http://www.itoworld.com/static/openstreetmap_tools/osm_mapper.html


 以上、参考まで。




 - Original Message -
From: Shu Higashi higa...@gmail.com
To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org
Date: 2014/7/16, Wed 10:37
Subject: [OSM-ja] 室蘭でのマッピング

東です。

仕事で室蘭市に行くついでがあり、7/26(土)に東室蘭駅近辺で
マッピングパーティを企画しています。
つきましては室蘭近辺をマッピングエリアとしておられる
マッパーさんはおられますでしょうか。
よろしければマッピングの進め方などご相談させて頂ければ
と思いまして。

今回はあまり大規模なイベントは想定していないのですが
室蘭市がオープンデータとして公開されたオルソ画像を
事前にトレースして、当日は主にPOIマッピングを行う予定です。
（インポートは行いません）
http://wiki.openstreetmap.org/wiki/Muroran
対象エリアとしては東室蘭駅周辺を想定しています。

___
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: [OSM-ja] 名古屋駅地下街のバリアフリーマッピングパーティー

[Hiroshi Omata]

小俣です。

あまり詳しくはないのですが、インドアマッピングはこのあたりが参考に
なるのではないかと思います。

Indoor Mapping
http://wiki.openstreetmap.org/wiki/Indoor

また以前、旧東急渋谷駅をテーマのこんなイベントも開催されたので
なにかの参考になればと思います。

JA:Shibuya Station
http://wiki.openstreetmap.org/wiki/JA:Shibuya_Station


Regards,
-- Omata


2014年7月17日 13:07 Shu Higashi higa...@gmail.com:
 東です。

 (1) layer=-1で入力された店舗を地上のPOIと区別してレンダリングしたい

 地下街の表現はイベント向けと言うよりも少し時間をかけて議論したほうが
 良さそうですね。
 すみませんが、この点どのようなタグ付けの方向なのか
 私自身はよく把握していないのでご存知の方がおられましたら
 ご紹介ください。

 (2) 段差，スロープ，手すり等を適切にマッピングしたい

 段差、スロープについてはこちらが
 https://lists.openstreetmap.org/pipermail/talk-ja/2010-July/003344.html
 階段、手すりについてはこちらが参考になるかもしれません。
 http://wiki.openstreetmap.org/wiki/JA:Tag:highway%3Dsteps

 障害のある方向けのタグ付け全般情報はこちらで何かしら見つかると思います。
 http://wiki.openstreetmap.org/wiki/Category:Disabilities

 (3) 現状で手元にある地下街の地図は，権利的にオープンにして良いものではなさそう

 はい。ここはお考えのようにひとまずOSMとは別が良いと思います。

 (4) マッピングパーティー後のアイディアソン・ハッカソンに繋げる課題抽出のやり方

 ここは私はあまりよく分かっていないのであまり参考にはならないかもしれませんが
 OSMのマッピングは、それ自体で結構頭と体を使うので
 あまりいろいろ詰め込まない方が良さそうな気はします。
 編集作業まで終わってから街で見つけた課題を自由討議するというくらいは
 ありかもしれませんね。

 (3.1) もっとOSMとの親和性が高くて簡単なツールがあれば，お教え頂ければ幸いです．

 私は使ったことが無いのですがuMapは使いやすそうです。
 http://umap.openstreetmap.fr/ja/
 sharemapはややとっつきにくですが、いろいろ細かいことができます。
 http://sharemap.org/site/index
 下記はsharemapを使ってoverpass apiで公園の木(natural=tree)を抜いて独自アイコンをかぶせた例です。
 http://sharemap.org/higa4/%E3%81%8A%E3%82%86%E3%81%BF%E9%87%8E#!flash


 どうぞ，よろしくお願い致します．

 --
 ==
 白松 俊 siram...@nitech.ac.jp
 名古屋工業大学
 工学部情報工学教育類／大学院情報工学専攻
 新谷・大囿研究室 助教
 Tel: 052-735-5129
 Fax: 052-735-5584
 URL: http://www-toralab.ics.nitech.ac.jp/~siramatu/
 ==


 ___
 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: [OSM-ja] 名古屋駅地下街のバリアフリーマッピングパーティー

[Madoka Nakajima]

中島です。

渋谷駅のイベントは、東急電鉄さん、古橋さんと一緒に企画しました。
http://creative-city.jp/news/2012/1207_154806.html

その時の資料はこちらに残っていますので、参考にしてください。
http://www.slideshare.net/mapconcierge/indoor-mappinghandbook-beta1

ちなみに、階層はlayerではなく、levelで統一して入力しました。

最新のIndoor OSMで議論は、飯田さんに教えて頂いたのですが、
こちらで行われています。
http://forum.openstreetmap.org/viewtopic.php?id=25961


(2014/07/17 13:31), Hiroshi Omata wrote:
 小俣です。

 あまり詳しくはないのですが、インドアマッピングはこのあたりが参考に
 なるのではないかと思います。

 Indoor Mapping
 http://wiki.openstreetmap.org/wiki/Indoor

 また以前、旧東急渋谷駅をテーマのこんなイベントも開催されたので
 なにかの参考になればと思います。

 JA:Shibuya Station
 http://wiki.openstreetmap.org/wiki/JA:Shibuya_Station


 Regards,
 -- Omata


 2014年7月17日 13:07 Shu Higashi higa...@gmail.com:
 東です。

 (1) layer=-1で入力された店舗を地上のPOIと区別してレンダリングしたい
 地下街の表現はイベント向けと言うよりも少し時間をかけて議論したほうが
 良さそうですね。
 すみませんが、この点どのようなタグ付けの方向なのか
 私自身はよく把握していないのでご存知の方がおられましたら
 ご紹介ください。

 (2) 段差，スロープ，手すり等を適切にマッピングしたい
 段差、スロープについてはこちらが
 https://lists.openstreetmap.org/pipermail/talk-ja/2010-July/003344.html
 階段、手すりについてはこちらが参考になるかもしれません。
 http://wiki.openstreetmap.org/wiki/JA:Tag:highway%3Dsteps

 障害のある方向けのタグ付け全般情報はこちらで何かしら見つかると思います。
 http://wiki.openstreetmap.org/wiki/Category:Disabilities

 (3) 現状で手元にある地下街の地図は，権利的にオープンにして良いものではなさそう
 はい。ここはお考えのようにひとまずOSMとは別が良いと思います。

 (4) マッピングパーティー後のアイディアソン・ハッカソンに繋げる課題抽出のやり方
 ここは私はあまりよく分かっていないのであまり参考にはならないかもしれませんが
 OSMのマッピングは、それ自体で結構頭と体を使うので
 あまりいろいろ詰め込まない方が良さそうな気はします。
 編集作業まで終わってから街で見つけた課題を自由討議するというくらいは
 ありかもしれませんね。

 (3.1) もっとOSMとの親和性が高くて簡単なツールがあれば，お教え頂ければ幸いです．
 私は使ったことが無いのですがuMapは使いやすそうです。
 http://umap.openstreetmap.fr/ja/
 sharemapはややとっつきにくですが、いろいろ細かいことができます。
 http://sharemap.org/site/index
 下記はsharemapを使ってoverpass apiで公園の木(natural=tree)を抜いて独自アイコンをかぶせた例です。
 http://sharemap.org/higa4/%E3%81%8A%E3%82%86%E3%81%BF%E9%87%8E#!flash

 どうぞ，よろしくお願い致します．

 --
 ==
 白松 俊 siram...@nitech.ac.jp
 名古屋工業大学
 工学部情報工学教育類／大学院情報工学専攻
 新谷・大囿研究室 助教
 Tel: 052-735-5129
 Fax: 052-735-5584
 URL: http://www-toralab.ics.nitech.ac.jp/~siramatu/
 ==

 ___
 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


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

[Talk-GB] Solarium vs. Sunbed Salon vs. Tanning Salon

[Andreas Goss]

What is usually used in British English? Or did I maybe even miss something?
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Talk-GB] Solarium vs. Sunbed Salon vs. Tanning Salon

[SK53]

I think all are acceptable. FWIW I've always followed Harry Wood's dictum
and lumped these in as shop=beauty (aka Beauty Salon) possibly with a
sub-tag beauty=tanning. But given the paucity of usage on taginfo.uk, I
suspect I haven't been consistent.

OSM Nottingham
http://osm-nottingham.org.uk/?z=11lon=-1.17884lat=52.95611bgl=OSM,1,17l=chemistshealthhairbeautylh=Pharmacies%28dispensing%29;Chemists;Opticans;Mobility;Hairdressers;Tattooists;Alternativemedicine;Other
shows that the shop=beauty tag works sufficiently well to provide a decent
consistent mapping. As many solaria/tanning salons offer other 'beauty'
treatments I think this is another reason why sub-tagging is the way to go.
Tattooists are surpisingly frequent and usually sufficiently distinct that
there is no need to stretch the beauty tag further than necessary.

We could certainly revisit the tagged nodes in Nottingham and ensure
suitable sub-tagging: tanning  nail salons are preponderant in the mapped
elements.

Jerry

PS. Keep up the good work, eliminating literal translations from other
languages ought to help everyone in tagging: although dont know that we can
do much about the en-gb, en-us split.


On 16 July 2014 18:28, Andreas Goss andi...@t-online.de wrote:

 What is usually used in British English? Or did I maybe even miss
 something?
 __
 openstreetmap.org/user/AndiG88
 wiki.openstreetmap.org/wiki/User:AndiG88‎


 ___
 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] Solarium vs. Sunbed Salon vs. Tanning Salon

[Steve Doerr]

I agree, but of the three I'd plump for 'tanning salon'.

Steve

On 16/07/2014 19:09, SK53 wrote:
I think all are acceptable. FWIW I've always followed Harry Wood's 
dictum and lumped these in as shop=beauty (aka Beauty Salon) possibly 
with a sub-tag beauty=tanning. But given the paucity of usage on 
taginfo.uk http://taginfo.uk, I suspect I haven't been consistent.


OSM Nottingham 
http://osm-nottingham.org.uk/?z=11lon=-1.17884lat=52.95611bgl=OSM,1,17l=chemistshealthhairbeautylh=Pharmacies%28dispensing%29;Chemists;Opticans;Mobility;Hairdressers;Tattooists;Alternativemedicine;Other 
shows that the shop=beauty tag works sufficiently well to provide a 
decent consistent mapping. As many solaria/tanning salons offer other 
'beauty' treatments I think this is another reason why sub-tagging is 
the way to go. Tattooists are surpisingly frequent and usually 
sufficiently distinct that there is no need to stretch the beauty tag 
further than necessary.


We could certainly revisit the tagged nodes in Nottingham and ensure 
suitable sub-tagging: tanning  nail salons are preponderant in the 
mapped elements.


Jerry

PS. Keep up the good work, eliminating literal translations from other 
languages ought to help everyone in tagging: although dont know that 
we can do much about the en-gb, en-us split.



On 16 July 2014 18:28, Andreas Goss andi...@t-online.de 
mailto:andi...@t-online.de wrote:


What is usually used in British English? Or did I maybe even miss
something?
__
openstreetmap.org/user/AndiG88 http://openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88
http://wiki.openstreetmap.org/wiki/User:AndiG88?


___
Talk-GB mailing list
Talk-GB@openstreetmap.org mailto: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




---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Solarium vs. Sunbed Salon vs. Tanning Salon

[Andreas Goss]

Am 7/16/14 20:09 , schrieb SK53:

I think all are acceptable. FWIW I've always followed Harry Wood's
dictum and lumped these in as shop=beauty (aka Beauty Salon) possibly
with a sub-tag beauty=tanning. But given the paucity of usage on
taginfo.uk http://taginfo.uk, I suspect I haven't been consistent.


I saw that in the German Forum. My main issue with this is that it is a 
shop in the first place.


So if at all I would think of somthing like amenity=beauty_salon, but...


 As many solaria/tanning salons offer other
'beauty' treatments I think this is another reason why sub-tagging is
the way to go.


While that is certainly true, there are also many which don't (e.g. 
http://www.goyellow.de/getimage/428694/2 )
If i tag that with beauty then the tag on its own becomes basically 
worthless and you will always need a beauty= or beauty:tanning=yes.



Tattooists are surpisingly frequent and usually
sufficiently distinct that there is no need to stretch the beauty tag
further than necessary.


Although again I don't think it is a shop, but should be craft=
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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