Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden Graham Stewart (GrahamS)
Not sure if this helps you or not, but there is another Bing Image Analyser
available at:
http://mvexel.dev.openstreetmap.org/bingimageanalyzer/

This one provides the date that each tile was provided.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Bing-Aerial-Imagery-Analyzer-for-OpenStreetMap-tp5738898p5738950.html
Sent from the General Discussion mailing list archive at Nabble.com.

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


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden hbogner
Thx, I know about that one, but I'm looking for script/application for 
the first one to update curent coverage.


On 4.12.2012. 10:52, Graham Stewart (GrahamS) wrote:

Not sure if this helps you or not, but there is another Bing Image Analyser
available at:
http://mvexel.dev.openstreetmap.org/bingimageanalyzer/

This one provides the date that each tile was provided.




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


Re: [OSM-talk] [HOT] Problem with an Etrex 20

2012-12-04 Diskussionsfäden Banick, Robert
Hi Sebastian,

It certainly sounds like your USB Controller is dead, but here's a thought: 
Garmins can be finicky about the cables they're used with. Are you using the 
USB cable that came with the Etrex 20? If not then it might not recognize the 
device when plugged in.

Cheers,
Robert

Robert Banick | GIS Coordinator| International Services | Ì American Red 
Crosshttp://www.redcross.org/
2025 E Street NW, Washington, DC 20006
Tel 202-303-5017 | Cell 404-964-3451 | Fax 202-303—052 | Skype robert.banick

From: Sébastien Pierrel 
sebastien.pier...@gmail.commailto:sebastien.pier...@gmail.com
Date: Saturday, November 17, 2012 5:04 AM
To: h...@openstreetmap.orgmailto:h...@openstreetmap.org 
h...@openstreetmap.orgmailto:h...@openstreetmap.org, 
talk-eurosha-...@googlegroups.commailto:talk-eurosha-...@googlegroups.com 
talk-eurosha-...@googlegroups.commailto:talk-eurosha-...@googlegroups.com, 
Talk Openstreetmap talk@openstreetmap.orgmailto:talk@openstreetmap.org
Subject: [HOT] Problem with an Etrex 20

Greetings from Burundi,

we have an issue with one of the Etrex20 of the Eurosha Burundi team. It's not 
recognized by any computer.
When connected to the USB port, the device is powered through USB but doesn't 
enter mass storage mode. In the system setup menu, I can change the USB mode 
between Garmin and mass storage but computers won't recognize it in either 
mode.

I've tried on a Mac, Windows and linux. It doesn't show up in `lsusb`. The 
other etrex work just fine on these machines.

I've just realised that one of the working etrex prompts a message usb cable 
detected. do you want to switch to mass storage mode when in Garmin mode. The 
faulty etrex doesn't prompt such a message.

My diagnosis is that the USB controller is dead.

Any hope to access the data on the internal storage?

Help appreciated.
Cheers,
Seb.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden ant
Hi,

due to popular request I've tweaked the Bing analyser so you can use it
with editors. The analyser can now work like a TMS that tunnels Bing
imagery through to your editor while the processing is done in the
background.

TMS URL:
http://ant.dev.openstreetmap.org/bingimageanalyzer/tile.php/{zoom}/{x}/{y}.png?returnaerial=1

Let me know if it works for you.

cheers
ant

Am 03.12.2012 21:21, schrieb Svavar Kjarrval:
 It would be quicker still if we'd get editor support. If a user would
 use the BING imagery within JOSM, for example, it would process the
 information and update the BING coverage analyser.
 
 - Svavar Kjarrval
 
 On 03/12/12 20:11, hbogner wrote:
 I know people are using scripts and some applications to check out for
 coverage.

 I found one application that follows border of high resolution
 imagery, but it's not good for small areas.

 I want to do a grid automation for a small area, like the ones at
 http://ant.dev.openstreetmap.org/bingimageanalyzer/

 Does anyone know how to do that?

 Btw just zoomed out and found this:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=21.007486201582424lon=6.359497070312483zoom=6



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

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


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden Martijn van Exel
That was forked from something I did earlier, maybe that helps:

http://mvexel.dev.openstreetmap.org/bingimageanalyzer/

It should be noted that the overlay tiles are cached and the cache is
not managed in any smart way, so the data may be up to a year old
(which is when I last cleaned the cache).

On Mon, Dec 3, 2012 at 1:11 PM, hbogner hbog...@gmail.com wrote:
 I know people are using scripts and some applications to check out for
 coverage.

 I found one application that follows border of high resolution imagery, but
 it's not good for small areas.

 I want to do a grid automation for a small area, like the ones at
 http://ant.dev.openstreetmap.org/bingimageanalyzer/

 Does anyone know how to do that?

 Btw just zoomed out and found this:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=21.007486201582424lon=6.359497070312483zoom=6


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



-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/

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


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden Martijn van Exel
Oh whoops, I didn't see the rest of the thread, excuse me for the
redundant info.

On Tue, Dec 4, 2012 at 3:52 PM, Martijn van Exel m...@rtijn.org wrote:
 That was forked from something I did earlier, maybe that helps:

 http://mvexel.dev.openstreetmap.org/bingimageanalyzer/

 It should be noted that the overlay tiles are cached and the cache is
 not managed in any smart way, so the data may be up to a year old
 (which is when I last cleaned the cache).

 On Mon, Dec 3, 2012 at 1:11 PM, hbogner hbog...@gmail.com wrote:
 I know people are using scripts and some applications to check out for
 coverage.

 I found one application that follows border of high resolution imagery, but
 it's not good for small areas.

 I want to do a grid automation for a small area, like the ones at
 http://ant.dev.openstreetmap.org/bingimageanalyzer/

 Does anyone know how to do that?

 Btw just zoomed out and found this:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=21.007486201582424lon=6.359497070312483zoom=6


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



 --
 Martijn van Exel
 http://oegeo.wordpress.com/
 http://openstreetmap.us/



-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/

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


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden Svavar Kjarrval
Excellent work! :)

It works for me. The tiles don't load as fast as before but I can live
with that.

- Svavar Kjarrval

On 04/12/12 22:38, ant wrote:
 Hi,

 due to popular request I've tweaked the Bing analyser so you can use it
 with editors. The analyser can now work like a TMS that tunnels Bing
 imagery through to your editor while the processing is done in the
 background.

 TMS URL:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/tile.php/{zoom}/{x}/{y}.png?returnaerial=1

 Let me know if it works for you.

 cheers
 ant

 Am 03.12.2012 21:21, schrieb Svavar Kjarrval:
 It would be quicker still if we'd get editor support. If a user would
 use the BING imagery within JOSM, for example, it would process the
 information and update the BING coverage analyser.

 - Svavar Kjarrval

 On 03/12/12 20:11, hbogner wrote:
 I know people are using scripts and some applications to check out for
 coverage.

 I found one application that follows border of high resolution
 imagery, but it's not good for small areas.

 I want to do a grid automation for a small area, like the ones at
 http://ant.dev.openstreetmap.org/bingimageanalyzer/

 Does anyone know how to do that?

 Btw just zoomed out and found this:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=21.007486201582424lon=6.359497070312483zoom=6



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



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

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




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


Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap

2012-12-04 Diskussionsfäden Pierre Béland
Works for me also but very slow.


 
Pierre 




 De : Svavar Kjarrval sva...@kjarrval.is
À : talk@openstreetmap.org 
Envoyé le : Mardi 4 décembre 2012 17h58
Objet : Re: [OSM-talk] Bing Aerial Imagery Analyzer for OpenStreetMap
 
Excellent work! :)

It works for me. The tiles don't load as fast as before but I can live
with that.

- Svavar Kjarrval

On 04/12/12 22:38, ant wrote:
 Hi,

 due to popular request I've tweaked the Bing analyser so you can use it
 with editors. The analyser can now work like a TMS that tunnels Bing
 imagery through to your editor while the processing is done in the
 background.

 TMS URL:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/tile.php/{zoom}/{x}/{y}.png?returnaerial=1

 Let me know if it works for you.

 cheers
 ant

 Am 03.12.2012 21:21, schrieb Svavar Kjarrval:
 It would be quicker still if we'd get editor support. If a user would
 use the BING imagery within JOSM, for example, it would process the
 information and update the BING coverage analyser.

 - Svavar Kjarrval

 On 03/12/12 20:11, hbogner wrote:
 I know people are using scripts and some applications to check out for
 coverage.

 I found one application that follows border of high resolution
 imagery, but it's not good for small areas.

 I want to do a grid automation for a small area, like the ones at
 http://ant.dev.openstreetmap.org/bingimageanalyzer/

 Does anyone know how to do that?

 Btw just zoomed out and found this:
 http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=21.007486201582424lon=6.359497070312483zoom=6



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



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

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



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


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


[OSM-talk] Role of the Wiki

2012-12-04 Diskussionsfäden Jeff Meyer
Hi - N00b question here:

What's the role of the wiki as a source of information in the OSM community?

In my brief period here, I've been told things like this:

- For tags: RTFW
- For relations: do NOT read the wiki  HELL YES read the wiki
- Imports: the wiki's out of date
(Also - I've received information off IRC that conflicts with both email 
wiki)

In general, is there a method to when the wiki is or is not relevant?

I'm hoping it's relevant as OSM continues to grow - reading through old
email archives isn't super efficient (or clarifying).

Thanks,
Jeff

-- 
Jeff Meyer
Global World History Atlas
www.gwhat.org
j...@gwhat.org
206-676-2347
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Role of the Wiki

2012-12-04 Diskussionsfäden Roland Olbricht
Hi,

 In general, is there a method to when the wiki is or is not relevant?

Yes, please have a look at
http://taginfo.openstreetmap.org/

If a tag appears there in quite large numbers, it is relevant. Otherwise it is 
not relevant. Whatever the wiki tells you is rather irrelevant.
 
 What's the role of the wiki as a source of information in the OSM community?

You need to be careful. Beside the people who do real mapping and often have 
left an initially useful description in the wiki, a lot of people care for 
their pet wiki page, with mixed results. Thus, the wiki is often far from 
reality, both leaving open real world problems and devoting broad space to 
things that simply never happen in reality.

In general: the wiki is only descriptive, but often it sounds normative.

It is a good idea to
- use tags or tag keys that have been used quite often
http://taginfo.openstreetmap.org/
- search the wiki for keywords of the thing to tag
- read the relevant pages and take them as advice, not as a law
- if the pages don't make sense to you or don't match, ask at
http://help.openstreetmap.org
- add an additional, new tag if the often used tags don't describe the 
situation appropriately

 I'm hoping it's relevant as OSM continues to grow - reading through old
 email archives isn't super efficient (or clarifying).

The general outline is
- discussion happens on the mailing list
- decision taking is ultimately done by the inidividual mapper
- documentation happens at the wiki
 
Cheers,

Roland


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


Re: [OSM-talk] Role of the Wiki

2012-12-04 Diskussionsfäden Russ Nelson
Roland Olbricht writes:
  In general: the wiki is only descriptive, but often it sounds normative.
  
  It is a good idea to
  - use tags or tag keys that have been used quite often
  http://taginfo.openstreetmap.org/
  - search the wiki for keywords of the thing to tag
  - read the relevant pages and take them as advice, not as a law
  - if the pages don't make sense to you or don't match, ask at
  http://help.openstreetmap.org
  - add an additional, new tag if the often used tags don't describe the 
  situation appropriately

My rule of thumb is:
 1) If the wiki describes a tag, tag according to the description.
 2) If the wiki is silent on a tag, then feel free to add it.
 3) If the wiki describes something, and you think there's a better
way, then feel free to tag that way, but follow rule #1 and #2.
 4) But never change what the wiki says, because the people who came
before you followed rules #1, #2, and #3.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   

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


Re: [OSM-talk] Role of the Wiki

2012-12-04 Diskussionsfäden Jeff Meyer
The info about tagging is helpful, but I'm also curious about the role of
other parts of the wiki, too. The sounding normative vs. being normative
distinctions is... subtle? to the under-initiated.


On Tue, Dec 4, 2012 at 9:56 PM, Russ Nelson nel...@crynwr.com wrote:

 Roland Olbricht writes:
   In general: the wiki is only descriptive, but often it sounds normative.
  
   It is a good idea to
   - use tags or tag keys that have been used quite often
   http://taginfo.openstreetmap.org/
   - search the wiki for keywords of the thing to tag
   - read the relevant pages and take them as advice, not as a law
   - if the pages don't make sense to you or don't match, ask at
   http://help.openstreetmap.org
   - add an additional, new tag if the often used tags don't describe the
   situation appropriately

 My rule of thumb is:
  1) If the wiki describes a tag, tag according to the description.
  2) If the wiki is silent on a tag, then feel free to add it.
  3) If the wiki describes something, and you think there's a better
 way, then feel free to tag that way, but follow rule #1 and #2.
  4) But never change what the wiki says, because the people who came
 before you followed rules #1, #2, and #3.

 --
 --my blog is athttp://blog.russnelson.com
 Crynwr supports open source software
 521 Pleasant Valley Rd. | +1 315-600-8815
 Potsdam, NY 13676-3213  | Sheepdog

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




-- 
Jeff Meyer
Global World History Atlas
www.gwhat.org
j...@gwhat.org
206-676-2347
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Role of the Wiki

2012-12-04 Diskussionsfäden bruno
On mer, 2012-12-05 at 05:49 +0100, Roland Olbricht wrote:
 - use tags or tag keys that have been used quite often
 http://taginfo.openstreetmap.org/ 

What if a new  way of tagging something gets approved? The moment it
becomes approved there will be probably 0 objects with the new tags,
and if someone follows this principle (from what I see, this is exactly
what happens) the new tags won't be used, rendering useless the
discussion and approving of the new tags*.
I'm probably a too novice mapper to appreciate the freedom this tag as
you see fit approach gives me, I usually feel like couldn't they just
compromise on ONE way of tagging this? what if I tag it wrong?, but
that's probably my fault...

/bruno

* Yes, I'm talking about public_transport
-- 
CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email br...@tracciabi.li
GNU/Linux registered user #121507 http://linuxcounter.net


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


Re: [OSM-talk-nl] Wie gaat er naar FOSDEM 2013?

2012-12-04 Diskussionsfäden Stefan de Konink

On Mon, 3 Dec 2012, Pander wrote:


Wie gaat er naar
 https://fosdem.org/2013/

Zie ook:
 https://nl.wikipedia.org/wiki/FOSDEM


Ik denk dat ik nog wel een keertje ga :-)

Stefan

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] Wie gaat er naar FOSDEM 2013?

2012-12-04 Diskussionsfäden Henk Hoff
Ik denk dat het me niet gaat lukken.

Ben wel bij de Geo Freedom Day in Amersfoort later deze maand.

Gr,
Henk Hoff

On Mon, Dec 3, 2012 at 9:03 AM, Pander pan...@opentaal.org wrote:

 Hoi allemaal,

 Wie gaat er naar
   https://fosdem.org/2013/

 Zie ook:
   https://nl.wikipedia.org/wiki/FOSDEM

 Groetjes,

 Pander



 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-nl

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl


Re: [talk-au] When is a road a cycle route?

2012-12-04 Diskussionsfäden Ian Sergeant

On 04/12/12 15:59, Steve Bennett wrote:
On Tue, Dec 4, 2012 at 2:43 PM, Ian Sergeant inas66+...@gmail.com 
mailto:inas66+...@gmail.com wrote:



We're heading towards a day when everybody will have a routing
application on their mobile device or accessible elsewhere.  So
navigation is a diminishing issue, and desirability for cycling is
an increasing one.


Interesting thought. I don't know if I totally agree - I tend to carry 
a smartphone, *and* I have a GPS mounted on the handlebars, yet 
neither of those things is convenient as following actual signs or 
markings.


And 5 years ago you may have said the same thing about in-car GPS. You 
can't have a sign or a route to everywhere you may want to go.




If there is no cycling amenity of any kind, then it is just a
route? How does it differ from any other just by being signed?


I'm not sure I understand your question. By definition, a route is an 
abstraction on top of the physical world. What route did you take to 
get there - there's nothing physically distinguishing about a route.




But in labelling a route we're usually making a choice.  The answer to 
what route you take, has an underlying question of why you took it.




Could you elaborate on what amenity means to you? Me, I'm assuming 
that if the council has put up bicycle route signs, it's because 
they've determined that that road is inherently better for bikes than 
some nearby street - both because it's safer and more comfortable, and 
because it goes somewhere mildly useful.


Generally the case, but not always.  My bicycle sign on Parramatta road 
being my best example so I'm sticking with it.  A cycle route down a 
narrow three lane road, carrying trucks who'd soon as take you out as 
look at you.


 However, I accept that things like railtrails, long distance cycle 
routes, etc are exceptions here - where even poor amenity may want to 
be included in the route.  I'm not quite sure how we distinguish these 
type of trails where people are trying to fill in the gaps, from some 
of the just plain stupid mapped/signed routes that pass for cycle 
routes in some council areas.


Well, I guess they seem stupid if you're focusing on where's good 
to ride. They're totally logical and sensible if you're focusing on 
how do I get to point B.


Well, I guess I'm focussed on being alive when I get to B.

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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Fabian Patzke
Eine völlig andere Möglichkeit wäre es, die Grenzen per WMS oder ähnlichem
darzustellen und nur die Hover-/Auswahl-Polygone als Vektoren zu laden. Für
Openlayers gitb es hier:
http://openlayers.org/dev/examples/getfeature-wfs.html
ein Beispiel. Allerdings brauchst du halt dafür die Ganzen Geo-Server
Geschichten zusätzlich.

Grüße,
Fabian



--
View this message in context: 
http://gis.19327.n5.nabble.com/Anzahl-der-Punkte-in-einem-Polygon-fur-einen-Zoom-Level-optimieren-tp5738871p5739032.html
Sent from the Germany mailing list archive at Nabble.com.

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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Adrian Stabiszewski
Vielen Dank für die Hinweise. 

Douglas-Peucker sieht vielversprechend aus. 
Werde wohl aber eine Implementierung für Java selber schreiben müssen ;)

Viele Grüße,
Adrian



 -Ursprüngliche Nachricht-
 Von: Ralf Klammer [mailto:ralf_klam...@gmx.de]
 Gesendet: Dienstag, 4. Dezember 2012 08:10
 An: Openstreetmap allgemeines in Deutsch
 Betreff: Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom
 Level optimieren
 
 Richtige Libraries gibt es dafür nicht...allerdings gibt es in PostGIS die
 Funktion ST_Simplify() in der Douglas-Peucker umgesetzt
 ist...http://postgis.org/docs/ST_Simplify.html
 
 Ebenso ist diese Funktion auch in gdal vorhanden...hier mal für Python:
 http://gdal.org/python/osgeo.ogr.Geometry-class.html#Simplify
 
 Laut Dokumentationen soll die Funktion ST_SimplifyPreserveTopology()
 speziell für Polygone geeignet sein...kann man aber nur bedingt empfehlen.
 
 Ich habe letztens auch mitbekommen, dass in den neuesten Mapnik
 Releases auch Linienvereinfachungsalgorithmen implementiert sind, finde
 aber gerade den spez. Link nicht mehr...nur das hier:
 https://github.com/mapnik/mapnik/pull/1385
 
 Grüße
 
 
 Am 03.12.2012 18:49, schrieb Adrian Stabiszewski:
  Am 03.12.2012 18:21, schrieb Adrian Stabiszewski:
  Das Ganze ist noch etwas langsam weil halt viele Punkte. Kennt
  jemand euch noch einen Algorithmus mit dem ich die Anzahl der Punkte
  in einem Polygon für einen bestimmten Zoom Level optimieren kann?
  Sprich: Punkte entfernen, wenn sie sowieso nicht mehr zur äußeren
  Form des Polygons beitragen.
  Ich würde die Abweichung in Pixeln zwischen drei benachbarten Punkten
  ausrechnen.
 
  Genauer gesagt den Abstand des mittleren Punktes von der Tangente
 von
  Start und Ziel. Dazu die Auflösung.
 
  Wenn der Abstand weniger als 1 Pixel brauchst Du Dir keine Gedanken
  machen. Du kannst natürlich auch einen Schwellwert bestimmen.
 
  Ansonsten: ggf. Mindestabstand in Pixeln bestimmen. Wenn Punkt nicht
  dargestellt wird, mit nächstem Zielpunkt weiter. Start beibehalten.
 
  Ja, genau.
  Gibt es sowas schon fertig als Library? ;)
 
 
 
 
  ___
  Talk-de mailing list
  Talk-de@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-de
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Jochen Topf
On Tue, Dec 04, 2012 at 03:59:06PM +0100, Adrian Stabiszewski wrote:
 Douglas-Peucker sieht vielversprechend aus. 
 Werde wohl aber eine Implementierung für Java selber schreiben müssen ;)

http://www.vividsolutions.com/jts/jtshome.htm

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298

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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Ralf Klammer
Brauchst du noch nicht einmal: 
http://www.vividsolutions.com/jts/javadoc/com/vividsolutions/jts/simplify/DouglasPeuckerSimplifier.html


Das ist so ein alter Hut...da haben sie schon genug die Hörner dran 
abgestoßen ;-)


Grüße

Am 04.12.2012 15:59, schrieb Adrian Stabiszewski:

Vielen Dank für die Hinweise.

Douglas-Peucker sieht vielversprechend aus.
Werde wohl aber eine Implementierung für Java selber schreiben müssen ;)

Viele Grüße,
Adrian




-Ursprüngliche Nachricht-
Von: Ralf Klammer [mailto:ralf_klam...@gmx.de]
Gesendet: Dienstag, 4. Dezember 2012 08:10
An: Openstreetmap allgemeines in Deutsch
Betreff: Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom
Level optimieren

Richtige Libraries gibt es dafür nicht...allerdings gibt es in PostGIS die
Funktion ST_Simplify() in der Douglas-Peucker umgesetzt
ist...http://postgis.org/docs/ST_Simplify.html

Ebenso ist diese Funktion auch in gdal vorhanden...hier mal für Python:
http://gdal.org/python/osgeo.ogr.Geometry-class.html#Simplify

Laut Dokumentationen soll die Funktion ST_SimplifyPreserveTopology()
speziell für Polygone geeignet sein...kann man aber nur bedingt empfehlen.

Ich habe letztens auch mitbekommen, dass in den neuesten Mapnik
Releases auch Linienvereinfachungsalgorithmen implementiert sind, finde
aber gerade den spez. Link nicht mehr...nur das hier:
https://github.com/mapnik/mapnik/pull/1385

Grüße


Am 03.12.2012 18:49, schrieb Adrian Stabiszewski:

Am 03.12.2012 18:21, schrieb Adrian Stabiszewski:

Das Ganze ist noch etwas langsam weil halt viele Punkte. Kennt
jemand euch noch einen Algorithmus mit dem ich die Anzahl der Punkte
in einem Polygon für einen bestimmten Zoom Level optimieren kann?
Sprich: Punkte entfernen, wenn sie sowieso nicht mehr zur äußeren
Form des Polygons beitragen.

Ich würde die Abweichung in Pixeln zwischen drei benachbarten Punkten
ausrechnen.

Genauer gesagt den Abstand des mittleren Punktes von der Tangente

von

Start und Ziel. Dazu die Auflösung.

Wenn der Abstand weniger als 1 Pixel brauchst Du Dir keine Gedanken
machen. Du kannst natürlich auch einen Schwellwert bestimmen.

Ansonsten: ggf. Mindestabstand in Pixeln bestimmen. Wenn Punkt nicht
dargestellt wird, mit nächstem Zielpunkt weiter. Start beibehalten.


Ja, genau.
Gibt es sowas schon fertig als Library? ;)




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


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


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



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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Fabian Patzke
Moin,
da hier schon wieder die alten JTS Quellen angegeben wurden, kurz der
Hinweis, dass JTS schon länger hier:
http://tsusiatsoftware.net/
zu finden ist. Da gibt es dann auch eine neuere Version, als auf der
veralteten Seite.

JavaDoc: http://tsusiatsoftware.net/jts/javadoc/
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/simplify/DouglasPeuckerSimplifier.html

Ändert am besten gleich alle Eure Links. Ich bin da auch schon drauf
reingefallen.

Grüße,
Fabian



--
View this message in context: 
http://gis.19327.n5.nabble.com/Anzahl-der-Punkte-in-einem-Polygon-fur-einen-Zoom-Level-optimieren-tp5738871p5739038.html
Sent from the Germany mailing list archive at Nabble.com.

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


Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren

2012-12-04 Diskussionsfäden Norbert Renner
Hab's selbst nicht ausprobiert, aber für Osmosis gibt es ein 
simplifyways Plugin:


https://github.com/podolsir/osmosis-simplifyways

Für JavaScript gibt es Simplify.js vom Leaflet-Autor:

http://mourner.github.com/simplify-js/

Laut Beschreibung aus Leaflet extrahiert, müsste also auch direkt in 
Leaflet zu finden sein.


Gruß,
Norbert


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


[Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Heinz-Jürgen Oertel
Hallo, was soll man damit tun?
Bisher building=yes und separate addr:* Angaben

 Heinz 

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


Re: [Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Olaf Kotzte
Hallo Heinz,

dasselbe was an der Erdoberfläche passiert ist, löschen und die neue Nutzung 
eintragen.

Viele Grüße

Olaf

Am 04.12.2012 um 19:32 schrieb Heinz-Jürgen Oertel hj.oer...@t-online.de:

 Hallo, was soll man damit tun?
 Bisher building=yes und separate addr:* Angaben
 
 Heinz 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de
 


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


Re: [Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Heinz-Jürgen Oertel
Am Dienstag 04 Dezember 2012, 19:40:45 schrieb Olaf Kotzte:
 Hallo Heinz,
 
 dasselbe was an der Erdoberfläche passiert ist, löschen und die neue Nutzung 
 eintragen.
 
 Viele Grüße
 
 Olaf

OK,
das ist der einfachste Weg.
Auch der beste?

 Heinz 


 Am 04.12.2012 um 19:32 schrieb Heinz-Jürgen Oertel hj.oer...@t-online.de:
 
  Hallo, was soll man damit tun?
  Bisher building=yes und separate addr:* Angaben
  
  Heinz 
  
  ___
  Talk-de mailing list
  Talk-de@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-de
  
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de

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


Re: [Talk-de] Demo mehrsprachige Karte

2012-12-04 Diskussionsfäden Andreas Labres
On 03.12.12 10:32, Henning Scholland wrote:
 dennoch würde ich als deutschen Namen der aktuellen Stadt Wolgograd nutzen,
 weil die Stadt 1961 unbenannt wurde

ACK, hier macht auch old_name:de wohl Sinn.

/al

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


Re: [Talk-de] RFC zum Proposal winter_service

2012-12-04 Diskussionsfäden Andreas Labres
On 03.12.12 18:04, malenki wrote:
 Dass vor November und nach dem April noch Schnee fallen könnte, ist mir
 bei der Diskussion über Wintersperrungen glatt entfallen...

IMO hat einfach beides Anwendungsfälle. Einmal eine Zeitsperre und einmal ein
dieser Weg wird bei Schneelage nicht geräumt (winter_service=no).

/al

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


Re: [Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Manuel Reimer
Heinz-Jürgen Oertel hj.oertel at t-online.de writes:
 Am Dienstag 04 Dezember 2012, 19:40:45 schrieb Olaf Kotzte:
  Hallo Heinz,
  
  dasselbe was an der Erdoberfläche passiert ist, löschen und die neue Nutzung
eintragen.
  
  Viele Grüße
  
  Olaf
 
 OK,
 das ist der einfachste Weg.
 Auch der beste?

Ja. Was denn sonst? Wenn das Haus weg ist, dann kannst du es auch aus der
Karte löschen.

Wenn wieder ein Haus gebaut werden sollte, dann könntest du das dann später (mit
seinem neuen Grundriss) wieder reinnehmen.

Gruß

Manuel


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


Re: [Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Bernd Wurst
Am 05.12.2012 07:41, schrieb Manuel Reimer:
 Ja. Was denn sonst?

Gebäude entfernen, Adresse auf einen Node kopieren.

Wenn ein Gebäude entfernt wird, bleibt die Adresse dennoch erhalten.

Gruß, Bernd

-- 
Verbesserung der Oberfläche hört sich an wie die Streichung
liebgewonnener Features - bei GNOME weiss man ja nie...
(gefunden auf www.prolinux.de)



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


Re: [Talk-de] Abgerissenes Haus

2012-12-04 Diskussionsfäden Andreas Schmidt
hallo alle,

JOSM bietet Baulücke an.
Die WP(de) definiert diese als
innerörtliche unbebaute von Gebäuden vollständig umgebene Areale, oft
Folge des II.Weltkriegs.

Das wird dann auf englisch der mir unbekannte Begriff
landuse=brownfield
und unverständlicherweise wird
building=yes
übersetzt.

Die WP(en) schreibt dazu
Brownfield sites are abandoned or underused industrial and commercial
facilities. (Also brown wegen Verschmutzung?)
und
In the United Kingdom and Australia, the term applies more generally to
previously used land

Und dict.leo.org übersetzt brownfield als
die Industriebrache / die Altlast.

Ich glaube, ich habe früher schon mal eine unbebaute Fläche in einem
Wohngebiet als Baulücke gemapt, ohne lange drüber nachzudenken.

Ist das falsch?
Sollte man in JOSM die Übersetzung von Baulücke zu Industriebrache
ändern?

Fragen über Fragen

Grüße, Andreas


Am 04.12.2012 19:32, schrieb Heinz-Jürgen Oertel:
 Hallo, was soll man damit tun?
 Bisher building=yes und separate addr:* Angaben


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


Re: [Talk-it] Contattare università

2012-12-04 Diskussionsfäden pierpiggi

Il 04/12/2012 00:31, Caterpillar ha scritto:

Il 03/12/2012 22:26, Daniele Palladino ha scritto:


Ma vuoi chiedere informazioni alle università o fornire delle 
informazioni?
Mi sembrava che volessi chiedere informazioni dalla prima email che 
hai scritto


Daniele Palladino
From Galaxy Nexus

Il giorno 03/dic/2012 17:45, Caterpillar caterpilla...@gmail.com 
mailto:caterpilla...@gmail.com ha scritto:


Il 01/12/2012 20:10, Daniele Palladino ha scritto:


Da ex Rappresentante di Ingegneria di Roma Tre posso dirti che
da noi si é sempre contattata la Facoltà per chiedere se
esistono percheggi per biciclette (ad esempio).

É questo il tipo di informazioni che avevi in mente?

Daniele Palladino
From Galaxy Nexus

Il giorno 01/dic/2012 07:56, Fabrizio Tambussa
ftambu...@gmail.com mailto:ftambu...@gmail.com ha scritto:

Prova a contattare l'ufficio relazioni col pubblico,
generalmente all'indirizzo:
urp@dominio.it
Magari ti smistano loro la richiesta a chi di dovere.
Saluti
Fabrizio


Il giorno 30 novembre 2012 22:47, Caterpillar
caterpilla...@gmail.com mailto:caterpilla...@gmail.com
ha scritto:

Vi è mai capitato di dover contattare una università per
chiedere
informazioni circa la sua stessa area? Se si, quale
dipartimento avete
contattato?

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



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



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

Non proprio, intendevo più che altro informare l'università circa
il fatto che esiste OSM e che ci sono utenti che la stanno
mappando :-)
Ieri sera ho mandato una e-mail all'ufficio relazioni con il
pubblico dell'università, vediamo che mi rispondono...

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



___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Si all'inizio volevo chiedere informazioni, ma per il momento ho 
preferito informarli del fatto che ci sono persone che stanno mappando 
l'università :-)


Ripeto che secondo me il riferimento corretto, sia per dare informazioni 
di questo tipo sia per ottenere informazioni riguardo planimetrie, etc. 
non è l'URP ma l'ufficio tecnico, che dovrebbe esistere in qualsiasi 
ente pubblico (se l'ufficio in questione ha già una planimetria corretta 
e disponibile per OSM mi pare inutile stare a rimappare; in caso 
contrario può essere interessato ad acquisire dati o può dirti se ci 
sono regolamenti di qualche tipo che devi seguire per la mappatura...).


ciao
P.
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Contattare università

2012-12-04 Diskussionsfäden Martin Koppenhöfer


Am 04/dic/2012 um 09:26 schrieb pierpiggi pierpi...@gmail.com:

 Ripeto che secondo me il riferimento corretto, sia per dare informazioni di 
 questo tipo sia per ottenere informazioni riguardo planimetrie, etc. non è 
 l'URP ma l'ufficio tecnico, che dovrebbe esistere in qualsiasi ente pubblico 
 (se l'ufficio in questione ha già una planimetria corretta e disponibile per 
 OSM mi pare inutile stare a rimappare;


Credo che abbiano una planimetria ma molto probabilmente non sarà adatta per 
OSM ( troppo dettagliata, formato diverso, forse non integrata (singoli pezzi), 
proiezione diversa, ecc.
Evventualmentente potrebbe servire come sfondo per tracciare (previa 
riproiezione).

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


Re: [Talk-it] ATAC e OSM

2012-12-04 Diskussionsfäden Caterpillar
Scusate se mi intrometto, volevo segnalare che da utente Carsharing
(prima Atac, ora Agenzia della mobilità) sto iniziando a mappare le
varie stazioni dove sono parcheggiate le auto disponibili all'utenza

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


Re: [Talk-it] ATAC e OSM

2012-12-04 Diskussionsfäden Fabri
Il 04/12/2012 12:27, Caterpillar ha scritto:
 Scusate se mi intrometto, volevo segnalare che da utente Carsharing
 (prima Atac, ora Agenzia della mobilità) sto iniziando a mappare le
 varie stazioni dove sono parcheggiate le auto disponibili all'utenza
Ottimo! Ne ho già aggiunte diverse, ma non sono tutte, aggiungi pure le
mancanti, o i vari tag, tipo capacity se mancano in quelle già mappate ;)


-- 
Animation of SVN activity for Navit: 
http://ikaria.informatik.uni-rostock.de/mm337/navit/navit%20svn%20history.webm


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


[Talk-it] Mappatura massiva nuove strade

2012-12-04 Diskussionsfäden Caterpillar
Verso Natale andrò in Molise per passare le vacanze. La mappatura di
tale regione è molto carente. Avendo un telefono con Android 4.2,
un'antenna GPS Royaltek Sirf Star III, e anche una macchina fotografica
seria, vorrei impiegare queste risorse per mappare le strade e
aggiungere i relativi nomi.
Che approccio utilizzare? Voglio dire, se passo con l'automobile a un
incrocio tenendo il cellulare attaccato con la ventosa al vetro, e
registro con la voce il nome di una strada, rischio di confondermi
quando poi vado a riversare tutto al computer, in quanto potrei
equivocare le strade che si intersecano. Tuttavia, un aiuto non
indifferente potrebbe essere un programma di mappatura per Android che
supporti la bussola del telefono.

Si accettano consigli!

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


Re: [Talk-it] Mappatura massiva nuove strade

2012-12-04 Diskussionsfäden Gianluca Boero

Il 04/12/2012 20:55, Caterpillar ha scritto:

Verso Natale andrò in Molise per passare le vacanze. La mappatura di
tale regione è molto carente. Avendo un telefono con Android 4.2,
un'antenna GPS Royaltek Sirf Star III, e anche una macchina fotografica
seria, vorrei impiegare queste risorse per mappare le strade e
aggiungere i relativi nomi.
Che approccio utilizzare? Voglio dire, se passo con l'automobile a un
incrocio tenendo il cellulare attaccato con la ventosa al vetro, e
registro con la voce il nome di una strada, rischio di confondermi
quando poi vado a riversare tutto al computer, in quanto potrei
equivocare le strade che si intersecano. Tuttavia, un aiuto non
indifferente potrebbe essere un programma di mappatura per Android che
supporti la bussola del telefono.

Si accettano consigli!

Un consiglio che ti posso dare per non confonderti è di non strafare. 
Non mappare un'intero paese in un'ora per poi dimenticarti i nomi delle 
vie :-)
Eventualmente incomincia dalle strade più importanti di un paese e poi 
se hai tempo fai quelle minori. E' già un grande risultato credo :-)


--
Gianluca Boero


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


Re: [Talk-it] Mappatura massiva nuove strade

2012-12-04 Diskussionsfäden Francesco Pelullo
Ben venga qualunque contributo, io mi concentrerei sui dettagli che non
possono essere desunti da una foto satellitare: toponomastica e POI.

Impara a georeferenziare le foto, per quanto riguarda la direzione del
soggetto non è indispensabile utilizzare la bussola del telefono, puo'
essere sufficiente una normale fotocamera, qualche semplice regola e la
traccia GPS del tuo percorso.

Io faccio così:
- attivo la registrazione della traccia, georeferenzio la prima immagine
scattando una foto al display del GPS mentre visualizza l'orologio;
- inizio a muovermi nella direzione che mi interessa, a piedi o in auto;
- se il POI/soggetto della foto si trova di fronte a me (rispetto alla
direzione dalla quale provengo) scatto la foto con l'inquadratura normale
(landscape);
- se è alla mia destra, sempre rispetto alla direzione di marcia, ruoto la
fotocamera di 90° a destra (scatto la foto con l'inquadratura in verticale,
portrait);
- viceversa, se è alla mia sinistra, scatto la foto ruotando di 90° a
sinistra (inquadratura verticale, portrait capovolta rispetto al caso
precedente);
- infine, nel caso improbabile che il soggetto sia alle mie spalle (sempre
rispetto alla direz. di marcia) scatto con l'inquadratura landscape ma
sottosopra.

A spiegarlo è un casino, ma è molto semplice ed efficace. Permette di
distinguere i nomi delle vie agli incroci, la qualità delle immagini è
migliore rispetto a quelle del cellulare (beh, quantomeno del mio) ed il
telefono non rimane senza batteria.

Detto questo, ricordati di inserire almeno un POI per ogni categoria
(almeno una farmacia, almeno una scuola, un bar, un tourism=guidepost etc),
saranno di esempio (e di stimolo) per i locals che si sentiranno motivati a
completare la mappa della propria città.

Ciao e buone vacanze.
/niubii/
Il giorno 04/dic/2012 20:56, Caterpillar caterpilla...@gmail.com ha
scritto:

 Verso Natale andrò in Molise per passare le vacanze. La mappatura di
 tale regione è molto carente. Avendo un telefono con Android 4.2,
 un'antenna GPS Royaltek Sirf Star III, e anche una macchina fotografica
 seria, vorrei impiegare queste risorse per mappare le strade e
 aggiungere i relativi nomi.
 Che approccio utilizzare? Voglio dire, se passo con l'automobile a un
 incrocio tenendo il cellulare attaccato con la ventosa al vetro, e
 registro con la voce il nome di una strada, rischio di confondermi
 quando poi vado a riversare tutto al computer, in quanto potrei
 equivocare le strade che si intersecano. Tuttavia, un aiuto non
 indifferente potrebbe essere un programma di mappatura per Android che
 supporti la bussola del telefono.

 Si accettano consigli!

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

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


Re: [Talk-it] Mappatura massiva nuove strade

2012-12-04 Diskussionsfäden Caterpillar
Leggendo la tua risposta mi è venuto in mente che siccome le tracce GPS
registrate tengono conto della direzione di marcia, potrei fermarmi e
dire a voce: alla mia sinistra c'è Via tal de tali , alla mia destra
Via Y, e così via... In tal maniera ci metterei la metà del tempo
rispetto a fare le foto. Poi fotografie si possono sempre aggiungere in
seguito
Il 05/12/2012 00:10, Francesco Pelullo ha scritto:

 Ben venga qualunque contributo, io mi concentrerei sui dettagli che
 non possono essere desunti da una foto satellitare: toponomastica e POI.

 Impara a georeferenziare le foto, per quanto riguarda la direzione del
 soggetto non è indispensabile utilizzare la bussola del telefono, puo'
 essere sufficiente una normale fotocamera, qualche semplice regola e
 la traccia GPS del tuo percorso.

 Io faccio così:
 - attivo la registrazione della traccia, georeferenzio la prima
 immagine scattando una foto al display del GPS mentre visualizza
 l'orologio;
 - inizio a muovermi nella direzione che mi interessa, a piedi o in auto;
 - se il POI/soggetto della foto si trova di fronte a me (rispetto alla
 direzione dalla quale provengo) scatto la foto con l'inquadratura
 normale (landscape);
 - se è alla mia destra, sempre rispetto alla direzione di marcia,
 ruoto la fotocamera di 90° a destra (scatto la foto con l'inquadratura
 in verticale, portrait);
 - viceversa, se è alla mia sinistra, scatto la foto ruotando di 90° a
 sinistra (inquadratura verticale, portrait capovolta rispetto al caso
 precedente);
 - infine, nel caso improbabile che il soggetto sia alle mie spalle
 (sempre rispetto alla direz. di marcia) scatto con l'inquadratura
 landscape ma sottosopra.

 A spiegarlo è un casino, ma è molto semplice ed efficace. Permette di
 distinguere i nomi delle vie agli incroci, la qualità delle immagini è
 migliore rispetto a quelle del cellulare (beh, quantomeno del mio) ed
 il telefono non rimane senza batteria.

 Detto questo, ricordati di inserire almeno un POI per ogni categoria
 (almeno una farmacia, almeno una scuola, un bar, un tourism=guidepost
 etc), saranno di esempio (e di stimolo) per i locals che si sentiranno
 motivati a completare la mappa della propria città.

 Ciao e buone vacanze.
 /niubii/

 Il giorno 04/dic/2012 20:56, Caterpillar caterpilla...@gmail.com
 mailto:caterpilla...@gmail.com ha scritto:

 Verso Natale andrò in Molise per passare le vacanze. La mappatura di
 tale regione è molto carente. Avendo un telefono con Android 4.2,
 un'antenna GPS Royaltek Sirf Star III, e anche una macchina
 fotografica
 seria, vorrei impiegare queste risorse per mappare le strade e
 aggiungere i relativi nomi.
 Che approccio utilizzare? Voglio dire, se passo con l'automobile a un
 incrocio tenendo il cellulare attaccato con la ventosa al vetro, e
 registro con la voce il nome di una strada, rischio di confondermi
 quando poi vado a riversare tutto al computer, in quanto potrei
 equivocare le strade che si intersecano. Tuttavia, un aiuto non
 indifferente potrebbe essere un programma di mappatura per Android che
 supporti la bussola del telefono.

 Si accettano consigli!

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



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

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


[Talk-se] forest vs wood

2012-12-04 Diskussionsfäden Petri Salmela

Hallå allihopa!

Finns det några nyheter på skogsfronten? Det jag tänker på är taggarna 
landuse=forest samt natural=wood.

Vad jag förstått så vill man använda landuse=forest där man på något sätt 
brukar skogen, fäller/gallrar osv. wood skall användas vid orörd skog, vilt 
växande och där kommer ju frågan som HAR ställts innan: -Hur mycket orörd, vilt 
växande skog har vi t ex i sverige egentligen? 

Själv kör jag vidare på forest, i alla fall här runt motalatrakterna.

/Petri





---
http://piiloairo.com

  ___
Talk-se mailing list
Talk-se@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-se


[Talk-es] highway

2012-12-04 Diskussionsfäden Ricardo Sanz
Buenas,

quiero preguntar, ya que me he dado cuenta hace unos días editando, por qué
no se normalizó según los iconos/imágenes del OSM, es decir:

Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con limitación
de acceso a y desde las propiedades colindantes)
Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a
nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
etc.)
Primary (Carreteras importantes de un carril por sentido)
Secundary (Carreteras menos importantes de un carril por sentido)
Terciary (Carreteras de muchas curvas)
Minor Road (Resto carreteras interurbanas)


no se qué os parece..
así evitamos la normalización por administración autonómica, ya que cada
una le da el interés que cada una quiere y a veces es ilógico.

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


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden Xuacu
Hola Ricardo; hola, resto de OSMeros...

La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu
propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas son
muchas? ;)

Creo que nos conviene tener un criterio objetivo, como puede ser la
clasificación oficial, que nos evitará discusiones sobre apreciaciones
personales: en caso de duda, ¡mira la placa!

Un saludo


El 4 de diciembre de 2012 16:13, Ricardo Sanz
ricardosanz1...@gmail.comescribió:

 Buenas,

 quiero preguntar, ya que me he dado cuenta hace unos días editando, por
 qué no se normalizó según los iconos/imágenes del OSM, es decir:

 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con limitación
 de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)


 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada
 una le da el interés que cada una quiere y a veces es ilógico.

 Saludos

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


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


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden Antonio Navarro
Hola,

Yo creo que es más clara la clasificación según sus características
físicas, que, como en todo, puede haber dudas o interpretaciones diferentes
en casos concretos, pero en general me parece más correcta que la
administrativa (o al menos debería ser más homogénea).

De todas formas que después de 50 mensajes 'discutiendo' si una calle es
una calle o es una carretera, que ahora plantees usar las características
físicas... ;-)

Un saludo,
-- 
Antonio Navarro

mailto:anto...@hunos.net
mailto:antonio.navarro...@gmail.com
mailto:antonio.nava...@hispalinux.es



El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:

 Hola Ricardo; hola, resto de OSMeros...

 La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu
 propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas son
 muchas? ;)

 Creo que nos conviene tener un criterio objetivo, como puede ser la
 clasificación oficial, que nos evitará discusiones sobre apreciaciones
 personales: en caso de duda, ¡mira la placa!

 Un saludo


 El 4 de diciembre de 2012 16:13, Ricardo Sanz 
 ricardosanz1...@gmail.comescribió:

 Buenas,

 quiero preguntar, ya que me he dado cuenta hace unos días editando, por
 qué no se normalizó según los iconos/imágenes del OSM, es decir:

 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación
 de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)


 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada
 una le da el interés que cada una quiere y a veces es ilógico.

 Saludos

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



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


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


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden Ricardo
Lo digo mas que nada para diferenciar bien trunk y primary. O al menos segun 
las autonomias, ya que hay muchas diferencias entre comunidades




Ricardo Sanz Moreno


El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:

 Hola,
 
 Yo creo que es más clara la clasificación según sus características físicas, 
 que, como en todo, puede haber dudas o interpretaciones diferentes en casos 
 concretos, pero en general me parece más correcta que la administrativa (o al 
 menos debería ser más homogénea).
 
 De todas formas que después de 50 mensajes 'discutiendo' si una calle es una 
 calle o es una carretera, que ahora plantees usar las características 
 físicas... ;-)
 
 Un saludo,
 -- 
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 
 
 
 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:
 Hola Ricardo; hola, resto de OSMeros...
 
 La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu 
 propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas son 
 muchas? ;)
 
 Creo que nos conviene tener un criterio objetivo, como puede ser la 
 clasificación oficial, que nos evitará discusiones sobre apreciaciones 
 personales: en caso de duda, ¡mira la placa!
 
 Un saludo
 
 
 El 4 de diciembre de 2012 16:13, Ricardo Sanz ricardosanz1...@gmail.com 
 escribió:
 Buenas,
 
 quiero preguntar, ya que me he dado cuenta hace unos días editando, por qué 
 no se normalizó según los iconos/imágenes del OSM, es decir:
 
 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a 
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes, 
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)
 
 
 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada 
 una le da el interés que cada una quiere y a veces es ilógico.
 
 Saludos
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden David Marín Carreño
Quien quiera añadir las características físicas a una carretera, tiene tags
para ello.

La clasificación administrativa denota la importancia de una carretera
dentro de su clasificación administrativa. Y las características físicas *
suelen* venir acordes a dicha importancia. Como todo, hay y habrá
excepciones.

Y sobre todo, es un criterio fijo y no subjetivo.


El 4 de diciembre de 2012 18:47, Ricardo ricardosanz1...@gmail.comescribió:

 Lo digo mas que nada para diferenciar bien trunk y primary. O al menos
 segun las autonomias, ya que hay muchas diferencias entre comunidades




 Ricardo Sanz Moreno


 El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:

 Hola,

 Yo creo que es más clara la clasificación según sus características
 físicas, que, como en todo, puede haber dudas o interpretaciones diferentes
 en casos concretos, pero en general me parece más correcta que la
 administrativa (o al menos debería ser más homogénea).

 De todas formas que después de 50 mensajes 'discutiendo' si una calle es
 una calle o es una carretera, que ahora plantees usar las características
 físicas... ;-)

 Un saludo,
 --
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 


 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:

 Hola Ricardo; hola, resto de OSMeros...

 La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu
 propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas son
 muchas? ;)

 Creo que nos conviene tener un criterio objetivo, como puede ser la
 clasificación oficial, que nos evitará discusiones sobre apreciaciones
 personales: en caso de duda, ¡mira la placa!

 Un saludo


 El 4 de diciembre de 2012 16:13, Ricardo Sanz 
 ricardosanz1...@gmail.comescribió:

 Buenas,

 quiero preguntar, ya que me he dado cuenta hace unos días editando, por
 qué no se normalizó según los iconos/imágenes del OSM, es decir:

 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación
 de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)


 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada
 una le da el interés que cada una quiere y a veces es ilógico.

 Saludos

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



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


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


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




-- 
David Marín Carreño dav...@gmail.com
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden David Marín Carreño
Sobre lo de diferencias trunk y primary, habría que darse un paseo por las
distintas comunidades y quizá subir alguna categoría en algunas, como en
aquellas en las que todas las que caerían en la categoría trunk (red
básica) son autovías.


El 4 de diciembre de 2012 18:47, Ricardo ricardosanz1...@gmail.comescribió:

 Lo digo mas que nada para diferenciar bien trunk y primary. O al menos
 segun las autonomias, ya que hay muchas diferencias entre comunidades




 Ricardo Sanz Moreno


 El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:

 Hola,

 Yo creo que es más clara la clasificación según sus características
 físicas, que, como en todo, puede haber dudas o interpretaciones diferentes
 en casos concretos, pero en general me parece más correcta que la
 administrativa (o al menos debería ser más homogénea).

 De todas formas que después de 50 mensajes 'discutiendo' si una calle es
 una calle o es una carretera, que ahora plantees usar las características
 físicas... ;-)

 Un saludo,
 --
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 


 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:

 Hola Ricardo; hola, resto de OSMeros...

 La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu
 propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas son
 muchas? ;)

 Creo que nos conviene tener un criterio objetivo, como puede ser la
 clasificación oficial, que nos evitará discusiones sobre apreciaciones
 personales: en caso de duda, ¡mira la placa!

 Un saludo


 El 4 de diciembre de 2012 16:13, Ricardo Sanz 
 ricardosanz1...@gmail.comescribió:

 Buenas,

 quiero preguntar, ya que me he dado cuenta hace unos días editando, por
 qué no se normalizó según los iconos/imágenes del OSM, es decir:

 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación
 de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)


 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada
 una le da el interés que cada una quiere y a veces es ilógico.

 Saludos

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



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


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


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




-- 
David Marín Carreño dav...@gmail.com
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden Ricardo Sanz
No estaría mejor que las nacionales y autonómicas de un solo carril por sentido 
fueran primary y las carreteras nacionales y autonómicas de doble calzada con o 
sin rotondas (autovías no) fueran trunk?

---

Ricardo Sanz Moreno

El 04/12/2012, a las 20:34, David Marín Carreño dav...@gmail.com escribió:

 Sobre lo de diferencias trunk y primary, habría que darse un paseo por las 
 distintas comunidades y quizá subir alguna categoría en algunas, como en 
 aquellas en las que todas las que caerían en la categoría trunk (red 
 básica) son autovías.
 
 
 El 4 de diciembre de 2012 18:47, Ricardo ricardosanz1...@gmail.com escribió:
 Lo digo mas que nada para diferenciar bien trunk y primary. O al menos segun 
 las autonomias, ya que hay muchas diferencias entre comunidades
 
 
 
 
 Ricardo Sanz Moreno
 
 
 El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:
 
 Hola,
 
 Yo creo que es más clara la clasificación según sus características 
 físicas, que, como en todo, puede haber dudas o interpretaciones diferentes 
 en casos concretos, pero en general me parece más correcta que la 
 administrativa (o al menos debería ser más homogénea).
 
 De todas formas que después de 50 mensajes 'discutiendo' si una calle es 
 una calle o es una carretera, que ahora plantees usar las características 
 físicas... ;-)
 
 Un saludo,
 -- 
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 
 
 
 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:
 Hola Ricardo; hola, resto de OSMeros...
 
 La clasificación de carreteras no es una ciencia exacta. Fíjate que en tu 
 propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas 
 son muchas? ;)
 
 Creo que nos conviene tener un criterio objetivo, como puede ser la 
 clasificación oficial, que nos evitará discusiones sobre apreciaciones 
 personales: en caso de duda, ¡mira la placa!
 
 Un saludo
 
 
 El 4 de diciembre de 2012 16:13, Ricardo Sanz ricardosanz1...@gmail.com 
 escribió:
 Buenas,
 
 quiero preguntar, ya que me he dado cuenta hace unos días editando, por 
 qué no se normalizó según los iconos/imágenes del OSM, es decir:
 
 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas a 
 nivel por otras carreteras, rotondas, acceso a propiedades colindantes, 
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)
 
 
 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que cada 
 una le da el interés que cada una quiere y a veces es ilógico.
 
 Saludos
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 
 -- 
 David Marín Carreño dav...@gmail.com
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden David Marín Carreño
Hay vías rápidas de un sólo carril por sentido, mucho más rápidas y de
mejor calidad (arcenes, velocidad máxima) que numerosas carreteras
rotonderas de dos carriles por sentido...

En mi opinión, no termino de verlo...


El 4 de diciembre de 2012 21:28, Ricardo Sanz
ricardosanz1...@gmail.comescribió:

 No estaría mejor que las nacionales y autonómicas de un solo carril por
 sentido fueran primary y las carreteras nacionales y autonómicas de doble
 calzada con o sin rotondas (autovías no) fueran trunk?

 ---

 Ricardo Sanz Moreno

 El 04/12/2012, a las 20:34, David Marín Carreño dav...@gmail.com
 escribió:

 Sobre lo de diferencias trunk y primary, habría que darse un paseo por las
 distintas comunidades y quizá subir alguna categoría en algunas, como en
 aquellas en las que todas las que caerían en la categoría trunk (red
 básica) son autovías.


 El 4 de diciembre de 2012 18:47, Ricardo ricardosanz1...@gmail.comescribió:

 Lo digo mas que nada para diferenciar bien trunk y primary. O al menos
 segun las autonomias, ya que hay muchas diferencias entre comunidades




 Ricardo Sanz Moreno


 El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:

 Hola,

 Yo creo que es más clara la clasificación según sus características
 físicas, que, como en todo, puede haber dudas o interpretaciones diferentes
 en casos concretos, pero en general me parece más correcta que la
 administrativa (o al menos debería ser más homogénea).

 De todas formas que después de 50 mensajes 'discutiendo' si una calle es
 una calle o es una carretera, que ahora plantees usar las características
 físicas... ;-)

 Un saludo,
 --
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 


 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:

 Hola Ricardo; hola, resto de OSMeros...

 La clasificación de carreteras no es una ciencia exacta. Fíjate que en
 tu propuesta introduces criterios subjetivos como «muchas curvas» ¿Cuántas
 son muchas? ;)

 Creo que nos conviene tener un criterio objetivo, como puede ser la
 clasificación oficial, que nos evitará discusiones sobre apreciaciones
 personales: en caso de duda, ¡mira la placa!

 Un saludo


 El 4 de diciembre de 2012 16:13, Ricardo Sanz ricardosanz1...@gmail.com
  escribió:

 Buenas,

 quiero preguntar, ya que me he dado cuenta hace unos días editando, por
 qué no se normalizó según los iconos/imágenes del OSM, es decir:

 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación
 de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas
 a nivel por otras carreteras, rotondas, acceso a propiedades colindantes,
 etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)


 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que
 cada una le da el interés que cada una quiere y a veces es ilógico.

 Saludos

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



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


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


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




 --
 David Marín Carreño dav...@gmail.com

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


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




-- 
David Marín Carreño dav...@gmail.com
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es


Re: [Talk-es] highway

2012-12-04 Diskussionsfäden Ricardo Sanz
Pero para la definir la velocidad también hay etiquetas, no?
También podemos coger el mapa de velocidades medias y aforos de trafico y a 
partir de ahí poner los highway. 

Por ejemplo, 
trunk velocidades medias 90-100
Primary 70-90
Secundary 50-70
Terciary 30-50
Minor road 10-30

Y asi el que tenga dudas de qué highway es una vía que lo mire en el mapa y así 
no habria ambigüedades 

Mapas: 

http://www.fomento.gob.es/MFOM/LANG_CASTELLANO/DIRECCIONES_GENERALES/CARRETERAS/TRAFICO_VELOCIDADES/MAPAS/2011/

http://www.fomento.gob.es/NR/rdonlyres/C9FEF2C7-F76C-4D4A-9070-FC6BF735B287/112740/MapaVelocidad2011.pdf


---

Ricardo Sanz Moreno

El 04/12/2012, a las 22:13, David Marín Carreño dav...@gmail.com escribió:

 Hay vías rápidas de un sólo carril por sentido, mucho más rápidas y de mejor 
 calidad (arcenes, velocidad máxima) que numerosas carreteras rotonderas de 
 dos carriles por sentido... 
 
 En mi opinión, no termino de verlo...
 
 
 El 4 de diciembre de 2012 21:28, Ricardo Sanz ricardosanz1...@gmail.com 
 escribió:
 No estaría mejor que las nacionales y autonómicas de un solo carril por 
 sentido fueran primary y las carreteras nacionales y autonómicas de doble 
 calzada con o sin rotondas (autovías no) fueran trunk?
 
 ---
 
 Ricardo Sanz Moreno
 
 El 04/12/2012, a las 20:34, David Marín Carreño dav...@gmail.com escribió:
 
 Sobre lo de diferencias trunk y primary, habría que darse un paseo por las 
 distintas comunidades y quizá subir alguna categoría en algunas, como en 
 aquellas en las que todas las que caerían en la categoría trunk (red 
 básica) son autovías.
 
 
 El 4 de diciembre de 2012 18:47, Ricardo ricardosanz1...@gmail.com 
 escribió:
 Lo digo mas que nada para diferenciar bien trunk y primary. O al menos 
 segun las autonomias, ya que hay muchas diferencias entre comunidades
 
 
 
 
 Ricardo Sanz Moreno
 
 
 El 04/12/2012, a las 17:48, Antonio Navarro anto...@hunos.net escribió:
 
 Hola,
 
 Yo creo que es más clara la clasificación según sus características 
 físicas, que, como en todo, puede haber dudas o interpretaciones 
 diferentes en casos concretos, pero en general me parece más correcta que 
 la administrativa (o al menos debería ser más homogénea).
 
 De todas formas que después de 50 mensajes 'discutiendo' si una calle es 
 una calle o es una carretera, que ahora plantees usar las características 
 físicas... ;-)
 
 Un saludo,
 -- 
 Antonio Navarro
 
 mailto:anto...@hunos.net
 mailto:antonio.navarro...@gmail.com
 mailto:antonio.nava...@hispalinux.es
 
 
 
 El 4 de diciembre de 2012 17:38, Xuacu xuacu...@gmail.com escribió:
 Hola Ricardo; hola, resto de OSMeros...
 
 La clasificación de carreteras no es una ciencia exacta. Fíjate que en 
 tu propuesta introduces criterios subjetivos como «muchas curvas» 
 ¿Cuántas son muchas? ;)
 
 Creo que nos conviene tener un criterio objetivo, como puede ser la 
 clasificación oficial, que nos evitará discusiones sobre apreciaciones 
 personales: en caso de duda, ¡mira la placa!
 
 Un saludo
 
 
 El 4 de diciembre de 2012 16:13, Ricardo Sanz 
 ricardosanz1...@gmail.com escribió:
 Buenas,
 
 quiero preguntar, ya que me he dado cuenta hace unos días editando, por 
 qué no se normalizó según los iconos/imágenes del OSM, es decir:
 
 Motorway (autovías/autopistas de 2,3 ó 4 carriles por sentido y con 
 limitación de acceso a y desde las propiedades colindantes)
 Trunk (Carreteras de 2 carriles por sentido que sí pueden ser cruzadas 
 a nivel por otras carreteras, rotondas, acceso a propiedades 
 colindantes, etc.)
 Primary (Carreteras importantes de un carril por sentido)
 Secundary (Carreteras menos importantes de un carril por sentido)
 Terciary (Carreteras de muchas curvas)
 Minor Road (Resto carreteras interurbanas)
 
 
 no se qué os parece..
 así evitamos la normalización por administración autonómica, ya que 
 cada una le da el interés que cada una quiere y a veces es ilógico.
 
 Saludos
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 
 
 
 -- 
 David Marín Carreño dav...@gmail.com
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es
 
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 

Re: [Talk-at] POImap / Straßenbahnnetz Innsbruck

2012-12-04 Diskussionsfäden Simon Legner

Hallo Stephan,


Was ich daran nicht ideal finde ist, dass Parallelführungen von Linien zu
einem übermalen der anderen Linie(n) führt. Zumindest deutet das dunkle Eck
beim Hauptbahnhof an, dass die STB nicht dort im Süden endet (ich kenn
Innsbruck nicht gut).


Ich finde das auch nicht ideal. Allerdings möchte ich – aus optischen 
Gründen – die Segmente nicht mit den Liniennummern beschriften. Abhilfe 
würde wohl die Implementierung eines Verdrängungs-Algorithmus schaffen.
Nachdem die Stubaitalbahn einen separaten Artikel hat, finde ich die 
derzeitige Lösung akzeptabel.



Die Beschriftung der Haltestellennamen solltest Du auch noch größer machen.


Das ist einen Versuch wert. :-)

Grüße
Simon

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


Re: [Talk-at] Radwege in Wien

2012-12-04 Diskussionsfäden Markus Straub

Hi,

ich hab mal den inneren Teil des 1. Bezirks überarbeitet und folgendes 
gemacht:


- Basisnetz in Relation
- Grundnetz ohne Relation als lcn=yes an den Highways
- Alles was jetzt als lcn=yes getaggt ist und nicht zu den beiden obigen 
gehört lösche ich.


War das so gedacht?

Ich verwende im commit-kommentar #verkehrsradwege-wien, vielleicht will 
das ja mal wer auswerten :)


LG,
Markus


On 11/27/2012 11:02 PM, Stefan Tauner wrote:

On Tue, 27 Nov 2012 22:52:15 +0100
Markus Straub markus.straub...@gmail.com wrote:


.. irgendwie fehlt das #Verkehrs-Radwege auf der Wiki-Seite?


cache problem? :)



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


Re: [Talk-at] Radwege in Wien

2012-12-04 Diskussionsfäden Stefan Tauner
On Tue, 04 Dec 2012 23:03:45 +0100
Markus Straub markus.straub...@gmail.com wrote:

 Hi,
 
 ich hab mal den inneren Teil des 1. Bezirks überarbeitet und folgendes 
 gemacht:
 
 - Basisnetz in Relation
war da noch was zu tun (bis auf hinnige relationen vl)?

 - Grundnetz ohne Relation als lcn=yes an den Highways
 - Alles was jetzt als lcn=yes getaggt ist und nicht zu den beiden obigen 
 gehört lösche ich.
 
 War das so gedacht?

soweit ich das sehe, schauts gut/so wie ich es gemeint hab aus, bis auf
die fußgängerzone tuchlauben + bognergasse (sollte lcn, hat aber nicht)
vs steindlgasse + seitzergasse (btw ganz fürchterliches kopfstein-
pflaster, das sich anfühlt als wärs 1000 jahre alt. sollte nicht lcn
sein, ist es aber)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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


Re: [Talk-ca] OSM PEI Canada

2012-12-04 Diskussionsfäden Bruno Remy
For Android, you can use several tools:
-*Vespucci *works like JOSM : Download of a defined area, editing, then
upload the set of data
*-OS Map Tunner *: unlike Vespucci, this tools is *really *designed for
mobiles: very friendly and easy editing of items on the current Map. You
can also add new POI with categories of tags, just like Potlach.



2012/12/3 Robert Shand b...@shand.org.uk

 Hi Danny,

 The apps you mention could be doing a variety of things with the data….
 they may have old data, and as you say they may only be rendering certain
 things to their tiles (I'm assuming that they're rendering their own tile
 data).  The beauty of OSM is that the data can be there in the OSM db - but
 you get to pick and choose what to render for your use case.

 PEI is probably missing lots of data, which could equally be true for any
 other location.  That's part of the the fun  - adding useful stuff to it.

 I'm not aware of great tools for Android - but JOSM (
 http://josm.openstreetmap.de ) on a PC/Mac is a great tool for seeing
 what's actually available in the OSM data.  It can be fairly complex.

 As for the province having lots of data - yes it does.  But we have to be
 careful what data we import into OSM - that's a fairly complex thing.  I
 wouldn't go importing things into the database until the community has
 reached a consensus on the data you wish to import.

 It's great that you want to get involved, and it's great that you're
 asking questions.

 Perhaps we could go for a coffee and I can help point you in the right
 direction for a bunch of OSM stuff.

 Best wishes

 Bob

 On 2012-12-03, at 8:44 PM, Danny Lane lane...@gmail.com wrote:

 Hi Folks

 I'm new to the OSM - using my Nexus 7 Android device I find that depending
 on the program you use, you get different results. All these programs are
 using the Open Street Map - some have no POI, City name, etc while others
 appear to be better. My observation are for Prince Edward Island, Canada.

 Free Android Apps
 *NavFree *- with OSM Canada 2012  Postcodes Canada
  -Is really poor, few city name's, no POI, missing lots of streets, etc

 *OSMAnd* - using OSM prince-edward-island northamerica OSM map
 - has alot of POI, street names, etc...

 So my assumption that OSM for PEI Canada was missing alot of data may not
 be correct - just that some companies maybe using only a subset of the
 available data.

 What is the best tool on Andriod or Windows to do some verification of the
 OSM maps for Prince Edward Island? The Province has alot of GIS data that
 could be imported into OSM - but they use a different format ie: NTX and I
 don't know how to convert NTX to OSM format?

 Danny

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



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




-- 
Bruno Remy
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


Re: [OSM-talk-fr] Numéroter les maisons d'un hameau ?

2012-12-04 Diskussionsfäden Christian Quest
Pourquoi ne pas avoir une relation associatedStreet sans street dans
ce cas particulier ?

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Numéroter les maisons d'un hameau ?

2012-12-04 Diskussionsfäden Mickaël Guéret
Le mardi 04 décembre 2012 à 09:08 +0100, Christian Quest a écrit :
 Pourquoi ne pas avoir une relation associatedStreet sans street dans
 ce cas particulier ?
 
Sinon il y a le tag addr:hamlet, à mettre sur le point portant le
numéro, cf le wiki : http://wiki.openstreetmap.org/wiki/Key:addr:hamlet
et cette discussion :
http://forum.openstreetmap.org/viewtopic.php?id=16968 parle de la même
chose...

Mika_Gueret


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


Re: [OSM-talk-fr] Numéroter les maisons d'un hameau ?

2012-12-04 Diskussionsfäden PhQ
Bonjour,

Toute proportion gardée, ça ressemble à la pratique de  nos amis tchèques
dans leurs communes.
Les contributeurs tchèques ont peut être mis en place une procédure.

Cordialement




--
View this message in context: 
http://gis.19327.n5.nabble.com/Numeroter-les-maisons-d-un-hameau-tp5738931p5738936.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Suppression des tirets cadratins

2012-12-04 Diskussionsfäden Guilhem Bonnefille
Le 3 décembre 2012 19:40,  te...@free.fr a écrit :
 Une frontière ça sépare deux pays, à priori sur un pied d'égalité. Il 
 faudrait donc surtout stocker les deux informations et puis c'est le rendu 
 qui décide comment nommer la frontière.

 À ce sujet, tout à fait d'accord.
 - Faut-il donner un nom à une frontière ?
 - Si oui, alors s'il y a un nom différent de chaque côté (c'est-à-dire qu'il 
 n'y a pas consensus), alors pas de name=* mais un name:LANG=* pour toutes les 
 langues LANG qu'on veut, et écrit de la façon la plus appropriée qui soit 
 (selon le niveau des contributeurs).

Voilà, on est d'accord : pourquoi diable donner un nom à une
frontière, ou plutôt, pourquoi demander le nom de la frontière à un
contributeur, surtout si au final le nom se limite à énumérer les deux
régions (au sens large, voire géométrique) en utilisant un caractère
de séparation.

J'ai le sentiment qu'il serait plus pertinent de proposer le ou les
tags ou les règles nécessaires pour saisir les deux noms des deux
régions. La difficulté : porter une attention particulière à
l'objectivité de la saisie de l'information pour ne pas froisser des
susceptibilités et déclencher des guerres d'édition. Par exemple,
éviter name1 et name2 car de chaque coté on se trouverait lésé. Ca
serait quand même plus simple si le schéma de la BD OSM permettait le
multivalué sans nécessiter le moindre artifice (un peu comme LDAP).

Sur ce, bon troll^Wdiscussion ;-)
-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

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


Re: [OSM-talk-fr] Suppression des tirets cadratins

2012-12-04 Diskussionsfäden Pieren
2012/12/3 Jo winfi...@gmail.com:

 Pour chaque niveau nous faisons une relation et dans la relation il y
 l'indication des deux entités géographiques qui sont séparées par cette
 frontière. Donc pas besoin de name et encore moins de name:xx.

Quand tu auras réparé quelques frontières cassées par des débutants
qui ne comprennent pas les 'relations', on en reparlera ;-) Soit on
supprime tous les tags (option Sly), soit on garde les tags avec des
informations suffisament pertinentes pour les mappeurs.
Paradoxalement, je ne pensais même pas au rendu lorsque j'ai lancé
cette discussion. Ce qui me gêne, c'est la présence de ce caractère
spécial que je suis incapable de reproduire dans un tag 'name',
affiché ou pas sur la carte (ça fait longtemps que j'ai dépassé cette
problématique de l'affichage).

 Quant au sujet des caractères spéciaux et spécifiques à certaines langues:
 c'est pour cette raison-là que unicode a été développé; profitons-en.

Oui pour les caractères spéciaux comme é, è, ë, œ qui sont de vrais
informations spécifiques à la langue. Mais pas le tiret long,
indépendant des langues et qui n'est que pure cosmétique alors qu'il
existe d'autres séparateurs plus simples.

Pieren

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


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Vincent Privat
Le 4 décembre 2012 06:29, Vincent de Chateau-Thierry v...@laposte.net a
écrit :


 La BD parcellaire, c'est (en version courte) le cadastre remanié par l'IGN
 : 
 http://professionnels.ign.fr/**bdparcellairehttp://professionnels.ign.fr/bdparcellaire.
  Mais la question portait sur le Registre Parcellaire Graphique, c'est à
 dire les déclarations de cultures, par parcelles, dessinées par les
 agriculteurs sur fond photo. Ces données sont disponibles en format
 Shapefile sur data.gouv.fr, donc à défaut d'un service WMS, il doit y
 avoir matière à
 les afficher en fond dans JOSM via le plugin OpenData.


Yep. le module installe d'ailleurs une feuille de style pour ce jeu de
données afin de visualiser les différentes cultures.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Stand OpenStreetMap FOSDEM 2013

2012-12-04 Diskussionsfäden RatZilla$
Bonjour à tou[te]s,

J'ai réservé un stand OSM au FOSDEM 2013 qui se déroulera le samedi 2 et
dimanche 3 février 2013 à Bruxelles.


https://fosdem.org/2013/

Qui y va ?

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction en cours

2012-12-04 Diskussionsfäden Christian Quest
Le premier changeset de redaction est ici:
http://www.openstreetmap.org/browse/changeset/14138736

J'ai retracé d'après bing la zone couverte par ce premier changeset
(et un peu autour).
Il faut compléter avec le cadastre pour les noms...

Les noeuds orphelins restant sont parfois réutilisables, mais souvent
pas trop bien placés par rapport aux images bing actuelles. J'en ai
réutilisé certains, mais laissé d'autres temporairement. On pourra
toujours les supprimer par la suite mais ils laissent pour l'instant
une trace utile des zones touchées.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


[OSM-talk-fr] [forum-osm-fr] Talus

2012-12-04 Diskussionsfäden forum
Le message suivant de :
##
Bonjour à Tous



Je suis dans le Morbihan et j'ai un souci pour tagger les talus car ceux-ci 
sont plantés d'arbres qui n'ont rien à voir  avec une haie. Comment dois- 
procéder

Merci pour vos réponses

Bonne journée

Hervé

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum-liste
peuvent être posées à sylvainaletuffe.org

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


[OSM-talk-fr] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden RatZilla$
Bonjour à tou[te]s

Je participerai le 6 décembre à la table ronde:

Langues de France et numérique

à La Cantine organisée par


La Délégation Générale à la langue française et aux langues de France et
Silicon Sentier en coopération avec Chroniqu.es, Wikimedia, Ubimix, le
LIMSI, Mondeca et le Dico du futur

Inscription et programme ici:

http://lacantine.org/events/numerique-investissons-dans-la-diversite-des-langues-tables-rondes-langues-de-france-et-numerique

J'évoquerai le support linguistique dans OpenStreetMap et les initiatives
en cours.

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Suppression des tirets cadratins

2012-12-04 Diskussionsfäden Vincent de Chateau-Thierry

 De : Pieren 

 2012/12/3 Jo :
 
  Pour chaque niveau nous faisons une relation et dans la relation il y
  l'indication des deux entités géographiques qui sont séparées par cette
  frontière. Donc pas besoin de name et encore moins de name:xx.

+1

 Quand tu auras réparé quelques frontières cassées par des débutants
 qui ne comprennent pas les 'relations', on en reparlera ;-) Soit on
 supprime tous les tags (option Sly), soit on garde les tags avec des
 informations suffisament pertinentes pour les mappeurs.

Je rajoute une 3e alternative : soit on se contente des tags nécessaires et 
jusque là
consensuels (admin_level  boundary) sans chercher à tagguer en fonction de 
l'éditeur.
Ce qui me gêne c'est avant tout le recours au tag name, qui n'est pas anodin, 
pour
une info qui relève de la note, du post-it, bref, d'une commodité d'édition et 
surtout
pas d'un nom. Dans l'éditeur de relations de JOSM, en laissant son curseur sur 
une ligne,
on a dans une bulle la liste des tags de l'objet en question. En convertissant 
les
'name=*' en 'note=*' (par exemple), on garde l'info, mais on ne squatte pas 
'name'.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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


Re: [OSM-talk-fr] Stand OpenStreetMap FOSDEM 2013

2012-12-04 Diskussionsfäden Jo
2012/12/4 RatZilla$ ratzil...@gmail.com

 Bonjour à tou[te]s,

 J'ai réservé un stand OSM au FOSDEM 2013 qui se déroulera le samedi 2 et
 dimanche 3 février 2013 à Bruxelles.


 https://fosdem.org/2013/

 Qui y va ?


Salut Gaël,

Moi j'irai. Si tu veux je l'annoncerai sur les listes talk, talk-be,
talk-nl et talk-de. Mais je voulais attendre le 15/12 ou même le nouvel an
pour être certain que l'on aura une table/ un stand. C'est fort probable,
mais pas encore absolument certain.

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


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Pieren
2012/12/4 Vincent Privat vincent.pri...@gmail.com:

Okay, parlé trop vite. Le pire, c'est que j'ai déjà vu cette source
mais j'ai des doutes sur son exploitation. On ne fait pas de
différence dans OSM entre blé, orge ou colza. Mais ça pourrait servir
pour distinguer vignoble, vergers et autres cultures moins
permanentes.

Pieren

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


Re: [OSM-talk-fr] Stand OpenStreetMap FOSDEM 2013

2012-12-04 Diskussionsfäden Philippe Pary
Le 04/12/2012 10:48, RatZilla$ a écrit :
 Bonjour à tou[te]s,
 
 J'ai réservé un stand OSM au FOSDEM 2013 qui se déroulera le samedi 2 et
 dimanche 3 février 2013 à Bruxelles.
 
 
 https://fosdem.org/2013/
 
 Qui y va ?

J'y serai une journée comme tous les ans.
Je peux prévoir une demi-journée pour aider à tenir le stand.

Philippe



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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Christophe Merlet
Le mardi 04 décembre 2012 à 11:07 +0100, RatZilla$ a écrit :
 Bonjour à tou[te]s
 
 Je participerai le 6 décembre à la table ronde:
 
 Langues de France et numérique 
 
 à La Cantine organisée par
  
 
 La Délégation Générale à la langue française et aux langues de France
 et Silicon Sentier en coopération avec Chroniqu.es, Wikimedia, Ubimix,
 le LIMSI, Mondeca et le Dico du futur
 
 Inscription et programme ici:
 
 http://lacantine.org/events/numerique-investissons-dans-la-diversite-des-langues-tables-rondes-langues-de-france-et-numerique
 
 J'évoquerai le support linguistique dans OpenStreetMap et les
 initiatives en cours.

Pour les tuiles internationales il y a bien sûr le serveur
https://toolserver.org/~osm/locale/__all.html
avec toutes les langues du monde.
Il a l'inconvénient d'utiliser plusieurs calques distincts qui limite la
facilité d'utilisation offline des tuiles.

C'est pour ça que j'ai mis en place un serveur de tuiles localisées
monocouche
http://tile.paulla.asso.fr/openlayers.html
Français, breton, Catalan, Basque et Occitan (Auvergnat, Gascon,
Languedocien, Limousin, Provencal et Vivaro-alpin)
Faut le faire monter en charge maintenant... :o)


Reste à développer la traduction de ces cartes en s'appuyant sur
Wikipedia...


Librement,
-- 
Christophe Merlet (RedFox)


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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Nolwenn
Le mardi 4 décembre 2012 11:58:03 Christophe Merlet a écrit :
 
 Reste à développer la traduction de ces cartes en s'appuyant sur
 Wikipedia...

Et de nomino http://nomino.comptoir.net/ (http://gitorious.org/nomino/nomino)

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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Christophe Merlet
Le mardi 04 décembre 2012 à 12:01 +0100, Nolwenn a écrit :
 Le mardi 4 décembre 2012 11:58:03 Christophe Merlet a écrit :
  
  Reste à développer la traduction de ces cartes en s'appuyant sur
  Wikipedia...
 
 Et de nomino http://nomino.comptoir.net/ (http://gitorious.org/nomino/nomino)

Pas mal comme appli. Simple et efficace.
Par contre, je viens de me rendre compte que nominatim sortait la
relation de la commune, mais pas le nœud place, et c'est sur ce nœud
place que j'avais pris l'habitude de mettre les traductions...

Bon, après tout, ce n'est pas insensé de remonter les traductions au
niveau supérieur...


Librement,
-- 
Christophe Merlet (RedFox)


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


Re: [OSM-talk-fr] Stand OpenStreetMap FOSDEM 2013

2012-12-04 Diskussionsfäden [Famille] Pierre WILLOT
Je pense aussi être présent

@+
Pierre  (Fosses-La-Ville en Belgique)


Le 04/12/12 10:48, RatZilla$ a écrit :
 Bonjour à tou[te]s,

 J'ai réservé un stand OSM au FOSDEM 2013 qui se déroulera le samedi 2 et
 dimanche 3 février 2013 à Bruxelles.


 https://fosdem.org/2013/

 Qui y va ?

 Gaël



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



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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Philippe Verdy
Tu oublies au moins :
- le néerlandais (ou flamand) et l'allémanique (y compris l'alsacien).
- le picard (inclut le ch'ti : rien à voir avec le wallon, même si ce sont
des langues d'oïl),
- le corse et les dialectes frontaliers de l'italien (par exemple le
monégasque, hérité de l'influence génoise comme peut l'être encore de façon
plus éloignée le corse), et qu'on ne peut classer comme des langues d'oc
(ils sont beaucoup plus latins que francs).
- le catalan (oui, en France, pas qu'en Espagne).

Parmi les langues d'oc, il y a plusieurs formes stabilisées effectivement
dans ce continuum que tu as détaillées (uniquement dans le cas de ce qu'on
appelle 'occitan, mais qui comprend aussi le catalan un peu à part étant
donné le nombre de locuteurs actifs de l'autre côté des Pyrénées, mais avec
un renouveau aussi du côté français).

Les autres langues régionales d'oïl (par exemple le lorrain, à mi-chemin
entre français et wallon, considéré comme dialecte du français en France,
ou comme dialecte du wallon en Belgique... le gallo, l'angevin, le
poitevin, le santongeais, le maraichin... le francilien c-à-d celui des
campagnes, et même le titi parisien un peu oublié sauf dans les vieux
films, l'occitan parisien des Auvergnats lui aussi oublié, et le parisien
celui très populaire des banlieues qui se répand dans toute la France) sont
soit très minoritaires, soit difficiles à distinguer du français standard
(ils se mélangent facilement), car elles forment ensemble un continuum
(tant linguistique que géographique).

Ce continuum est aussi le cas entre les langues germaniques modernes ou
anciennes, dont l'allemand, le bavarois, l'allémanique, le
luxembourgeois, le limbourgeois et le néerlandais, le bas-saxon, qui n'en
sont que des formes stabilisées chacune par un(?) standard — tout comme le
français dit standard) — avec de très larges compréhensions mutuelles, et
une domination de plus en plus grande de l'allemand standard et du
néerlandais standard (et même de gros imports de l'allemand et de l'anglais
sur le néerlandais dit standard).

On a moins d'influence sur les langues d'oc qui ont gardé une spécificité
par rapport au français standard, en s'en écartant de plus en plus.



Méfiance tout de même avec la toponymie de Wikipédia, il y a de nombreuses
erreurs ou grossières approximations orthographiques (ou des transcriptions
 multiples (avec des redirections sur les noms d'articles, pas toujours
mentionnées dans le texte de l'article lui-même qui a pu être renommé
abusivement vers une forme non préférée), ou des translittérations sans
aucune norme

(Chacun des auteurs sur Wikipédia invente sa propre norme de transcription
des langues et écritures étrangères, et parfois certains vont même
l'imposer aux autres sur la base du premier arrivé premier gardé,
certains voulant bloquer les renommages en créant tout de suite des pages
de redirection depuis les noms alternatifs, et en créant tout se suite des
trucs difficiles à renommer comme des catégories ou des images, histoire de
bien compliquer la tâche aux correcteurs qui vont se retrouver avec des
liens en double redirection et des tonnes de pages à corriger par Bot, ce
que beaucoup ne savent pas faire ! Du coup le consensus communautaire est
souvent de ne pas toucher à ces noms d'articles même s'ils sont faux).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden PierreV
Je pense que l'on pourrait l'utiliser pour affiner aussi le CLC qui
confondais trop souvent les prairies pour les betes et champs pour
cultiver...

En tout cas si on arriverais a en faire un flux WMS pour l'afficher en fond
sur JOSM ca serait génial si c'est bien  en licence LO/OL



--
View this message in context: 
http://gis.19327.n5.nabble.com/registre-parcellaire-graphique-WMS-et-JOSM-tp5738863p5738999.html
Sent from the France mailing list archive at Nabble.com.

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


[OSM-talk-fr] [forum-osm-fr] Indiquer les anciens nom ou histoire locale

2012-12-04 Diskussionsfäden forum
Le message suivant de :
##
Bonjour,





J'aimerai savoir si il est possible d'indiquer certaines spécificité locale 
correspondant à la vie du village. Par exemple :



[quote]Pont des caprices : nom donné après qu'il fut démoli 6 fois de nuit par 
un propriétaire le refusant sur son terrain.[/quote]



Ou sinon les anciens nom des champs, chemin (avec explication parfois), ruines 
qui n'existe plus… etc

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum-liste
peuvent être posées à sylvainaletuffe.org

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


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Mickaël Guéret
Le mardi 04 décembre 2012 à 04:18 -0800, PierreV a écrit :
 Je pense que l'on pourrait l'utiliser pour affiner aussi le CLC qui
 confondais trop souvent les prairies pour les betes et champs pour
 cultiver...
 
Je l'ai utilisé pour affiner les landuses. Le RPG est aussi intéressant
par ses trous, qui permettent de savoir ou se trouve les zones
naturelles (forêts, étangs, ...) les zones résidentielles, les cours de
fermes (farmyard), les zones industrielles...

Je n'utilise pas de wms, mais plutôt le fichier shapefile fournit sur le
site http://www.data.gouv.fr/ que je redécoupe avec les limites d'une
commune (pour des raisons de taille de fichier). Les données de cultures
peuvent être intéressantes, je sépare les cultures annuelles - céréales
à pailles, maïs, oléoprotéagineux, prairies temporaires... -
(landuse=farmland) des prairies permanentes, estives et landes (landuse
= meadow ou natural = scrub, parfois je redécoupe), vergers (landuse =
orchard), vignes (landuse = vineyard), etc... 

Attention, le polygones du RPG sont des ilots, qui ne correspondent
pas aux parcelles de culture (1 ilot = 1 ou plusieurs parcelles). Le
code de culture associé à l'ilot correspond à la culture de la parcelle
la plus grande. Autre limite quand on regarde sur Geoportail, certaines
prairies permanentes ne le sont plus l'année suivante, et vice-versa...

Les polygones du RPG sont très moches, je les fusionne,
simplifie/affine/corrige avec Bing. La commune de Moutiers-sous-Argenton
est presque terminée :
http://www.openstreetmap.org/?lat=46.961lon=-0.3692zoom=14layers=M

Le shapefile d'origine est là :
http://demo.ovh.net/fr/620c58e1c97a2395b98a379bf12315a9/

C'est un boulot de fourmi... j'estimerais à plus de 25h pour cette seule
commune... Je voulais voir si je pouvais y arriver...

Et désolé pour la longueur du message !

Mika_Gueret


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


[OSM-talk-fr] Re : registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Apamée
J'avais beaucoup d'espoir pour cette donnée. Mes tests personnels sont 
décevants.

- surabondance d'information (résolu pas trop mal par un script),
- imperfection de classement: la différence entre des terres de culture 
et prairie n'est pas toujours réaliste.
- problème d'échantillonage: une parcelle qui contient une part de 
prairie et une part de bois serra classée en prairie ou pas classée du 
tout.

Il faudrait:
- une donnée précise sur le forestier pour contraindre la donnée.
-  plus de retour d'expérience.

Le nouveau cru serra peut-être plus intéressant? Derrière c'est 
opportunité d'avoir une sacrement belle donnée d'occupation du sol.

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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden HELFER Denis
Pas d'alsacien ? Pourtant : http://taginfo.openstreetmap.fr/search?q=name%3Agsw

Denis

 -Message d'origine-
 De : Christophe Merlet [mailto:red...@redfoxcenter.org]
 Envoyé : mardi 4 décembre 2012 11:58
 À : RatZilla$
 Cc : c...@listes.openstreetmap.fr; Discussions sur OSM en français
 Objet : Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et
 numérique
 
 Le mardi 04 décembre 2012 à 11:07 +0100, RatZilla$ a écrit :
  Bonjour à tou[te]s
 
  Je participerai le 6 décembre à la table ronde:
 
  Langues de France et numérique
 
  à La Cantine organisée par
 
 
  La Délégation Générale à la langue française et aux langues de France
  et Silicon Sentier en coopération avec Chroniqu.es, Wikimedia,
 Ubimix,
  le LIMSI, Mondeca et le Dico du futur
 
  Inscription et programme ici:
 
  http://lacantine.org/events/numerique-investissons-dans-la-diversite-
 des-langues-tables-rondes-langues-de-france-et-numerique
 
  J'évoquerai le support linguistique dans OpenStreetMap et les
  initiatives en cours.
 
 Pour les tuiles internationales il y a bien sûr le serveur
 https://toolserver.org/~osm/locale/__all.html
 avec toutes les langues du monde.
 Il a l'inconvénient d'utiliser plusieurs calques distincts qui limite
 la
 facilité d'utilisation offline des tuiles.
 
 C'est pour ça que j'ai mis en place un serveur de tuiles localisées
 monocouche
 http://tile.paulla.asso.fr/openlayers.html
 Français, breton, Catalan, Basque et Occitan (Auvergnat, Gascon,
 Languedocien, Limousin, Provencal et Vivaro-alpin)
 Faut le faire monter en charge maintenant... :o)
 
 
 Reste à développer la traduction de ces cartes en s'appuyant sur
 Wikipedia...
 
 
   Librement,
 --
 Christophe Merlet (RedFox)
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Philippe Verdy
Ce qui est défini pour le nœud s'applique au nœud indépendamment des
relations qui peuvent les utiliser en admin_center (il peut y en voir
plusieurs).
Le nom d'une commune est celui de la relation, pas du nœud ni celui
d'aucune autre relation...

Bref pour nommer une commune entière il vaut mieux le faire dans la
relation (le nœud a un nom beaucoup plus local). En principe même le
ref:INSEE de commune sur le nœud est inutile et nuisible. Il est inutile
car la relation mentionne déjà le noeud comme admin_centre.

De même la population sur les nœuds n'a pas beaucoup de sens. Cela a du
sens sur la relation communale, ou celle du canton, ou celle de
l'agglomération. Malheuresement on veut encore appllquer un place=* aux
noeuds uniquement pour pouvoir afficher des symboles plsu grands ou des
libellés plus importants que d'autres (ce qu'on pourrait déduire en
comparant les admin_level des relations parentes, puis leur population dans
ces mêmes relations).

Plus utile est le code postal du nœud (sauf si on a cartographié les
frontières de secteurs postaux dans des relations, comme en Allemagne, ce
qui évite alors d'avoir à taguer toutes les nœuds d'adresses et même
souvent les rues), surtout si la commune a plusieurs codes postaux (dans la
relation on ne peut alors mettre qu'une liste de code postaux séparés par
points-virgules), mais sur le nœud on n'en a plus qu'un seul : la zone
postale est définie.

Si on dénormalise quelquechose sur le nœud c'est le plus haut statut de la
ville nommée comme le nœud (mais si la commune n'a pas le même nom que le
lieu désigné par son admin_centre, la solution est d'utiliser un autre nœud
dans la commune avec le rôle label, et dans ce cas c'est ce noeud qu'on
traduira).

Le nœud label est aussi utile quand le noeud admin_centre est très
décentré par rapport à la commune — voire parfois il est même situé HORS de
la surface de la relation (ce qui n'est nécessairement faux)

Parfois Osmose râle (en fait c'est juste une alerte qui demande de
vérifier, et de laisser une note dans les données pour dire que ce n'est
pas une erreur et l'expliquer, au cas où ce serait signalé à nouveau plus
tard) sur des points géodésiques ou des admin_centre situés hors de des
frontières de la  commune, ou nommés différemment, il ne faut pas le
prendre à la lettre (souvent les points géodésiques peuvent avoir une
orthographe abrégés, ce n'est qu'une désignation résumée dans les fichiers
IGN, et depuis les limites d'une commune ou son nom ont pu bouger aussi,
sans que la borne soit déplacée ni renommée) ! Le nom d'un nœud géodésique
n'est pas nécessairement celui de la commune où il est situé (c'est un nom
descriptif correct pour le repéter à la date où il a été défini et contrôlé
la dernière fois, plus qu'une réelle adresse), mais celui de la *planche*
cartographique de repérage ou bien il est à une position qui permet
d'observer le village le plus proche (les points géodésiques n'étant jamais
utilisés seuls mais toujours en réseau avec d'autres points géodésiques
pour régler les alignements et permettre de mesurer les distances par
triangulation).

Bref, pour chercher les noms par défaut et traductions de toponymes on a en
priorité :
 - 1. le nom du nœud de rôle label (s'il est défini) dans la langue
cherchée, sinon dans sa langue par défaut
 - 2. le nom de la relation dans la langue cherchée, sinon dans sa langue
par défaut
 - 3. le nom du nœud de rôle admin_centre dans la langue cherchée, sinon
dans sa langue par défaut

De plus les noms alternatifs (alt_name, short_name, official_name,
local_name, old_name...) devraient être cherchés dans le même objet dans la
même langue trouvée, sinon dans la langue par défaut si le nom principal
n'est trouvé que dans la langue par défaut : tous les *_name=* d'un même
sont liés ensemble dans le même objet, on ne peut en prendre certains dans
un objet et certains dans d'autres (mais les outils actuels oublient cela,
ce qui conduit parfois à des mélanges trompeurs entre ces noms alternatifs
sélectionnés définis en fait dans des langues différentes)  Quand ces
outils se trompent avec un mélange indésirable (est-ce une réelle anomalie
quand les clés sont différentes et que rien n'indique formellement la
dépendance mutuelle entre ces noms alternatifs et le nom principal), on est
parfois amené à forcer la sélection d'une langue dans le bon objet, en y
ajoutant une copie des noms alternatifs par défaut (tout ça car on a omis
de mentionner à quelle(s) langue(s) s'appliquent un nom alternatif par
défaut).

Attention dans certains cas, le nom admin_centre pourrait être juste nommé
Mairie ou nommé du nom d'un des villages de la commune.

On a parfois des cas où le membre admin_centre n'est pas un simple nœud,
mais un chemin fermé désignant (ou une relation multipolygone) couvrant un
bâtiment ou toute une zone administrative, voire même plusieurs zones
exclavées comprenant des mairies annexes et dépendances directes de la
collectivité locale : par exemple un bâtiment pour 

Re: [OSM-talk-fr] Re : registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Romain MEHUT
Le 4 décembre 2012 14:13, Apamée apa...@laposte.net a écrit :


 Il faudrait:
 - une donnée précise sur le forestier pour contraindre la donnée.


A croiser avec
http://lists.openstreetmap.org/pipermail/talk-fr/2012-August/046904.html ?
Pieren et Nicolas Dumoulin estimaient qu'il y aurait moyen d'en faire
quelque chose mais tu disais le contraire...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Philippe Verdy
A mon avis il cherchait alsacien sous le code als (mauvais code encore
utilisé par Wikipédia pour son nom de domaine et ses liens interwikis, et
qui est en conflit avec une autre langue définie dans ISO 639-3) et ne sait
pas que gsw=alémanique inclut l'alsacien.



Le 4 décembre 2012 14:17, HELFER Denis denis.hel...@region-alsace.eu a
écrit :

 Pas d'alsacien ? Pourtant :
 http://taginfo.openstreetmap.fr/search?q=name%3Agsw

 Denis

  -Message d'origine-
  De : Christophe Merlet [mailto:red...@redfoxcenter.org]
  Envoyé : mardi 4 décembre 2012 11:58
  À : RatZilla$
  Cc : c...@listes.openstreetmap.fr; Discussions sur OSM en français
  Objet : Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et
  numérique
 
  Le mardi 04 décembre 2012 à 11:07 +0100, RatZilla$ a écrit :
   Bonjour à tou[te]s
  
   Je participerai le 6 décembre à la table ronde:
  
   Langues de France et numérique
  
   à La Cantine organisée par
  
  
   La Délégation Générale à la langue française et aux langues de France
   et Silicon Sentier en coopération avec Chroniqu.es, Wikimedia,
  Ubimix,
   le LIMSI, Mondeca et le Dico du futur
  
   Inscription et programme ici:
  
   http://lacantine.org/events/numerique-investissons-dans-la-diversite-
  des-langues-tables-rondes-langues-de-france-et-numerique
  
   J'évoquerai le support linguistique dans OpenStreetMap et les
   initiatives en cours.
 
  Pour les tuiles internationales il y a bien sûr le serveur
  https://toolserver.org/~osm/locale/__all.html
  avec toutes les langues du monde.
  Il a l'inconvénient d'utiliser plusieurs calques distincts qui limite
  la
  facilité d'utilisation offline des tuiles.
 
  C'est pour ça que j'ai mis en place un serveur de tuiles localisées
  monocouche
  http://tile.paulla.asso.fr/openlayers.html
  Français, breton, Catalan, Basque et Occitan (Auvergnat, Gascon,
  Languedocien, Limousin, Provencal et Vivaro-alpin)
  Faut le faire monter en charge maintenant... :o)
 
 
  Reste à développer la traduction de ces cartes en s'appuyant sur
  Wikipedia...
 
 
Librement,
  --
  Christophe Merlet (RedFox)
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr

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

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


[OSM-talk-fr] parking ou parking_space?

2012-12-04 Diskussionsfäden Romain MEHUT
Bonjour,

Je ne saisis pas la distinction entre amenity=parking et
amenity=parking_space.
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Doit-on comprendre qu'il s'agit de dessiner le contour des emplacements de
stationnements dans l'emprise plus grande d'un parking?

Auriez-vous des exemples à montrer?

Merci.

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


[OSM-talk-fr] Ouverture prochaine des données de cyclabilité sur Nantes Métropole

2012-12-04 Diskussionsfäden Romain MEHUT
Bonjour,

Pour info vu ici:
http://data.nantes.fr/actualites/?tx_ttnews[tt_news]=2017cHash=2ad1ebaffcf24615f587096db1b30de2

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


Re: [OSM-talk-fr] parking ou parking_space?

2012-12-04 Diskussionsfäden Francescu GAROBY
Bonjour,
Je n'ai jamais utilisé parking_space mais, tel que je comprends la chose,
je vois bien ce tag pour faire du micro-mapping, afin de faire ressortir
les places pour handicapés, numérotées/attribuées, familiales, ...
Après, qu'il faille détailler chaque place par un point ou par une surface,
j'ai pas d'avis tranché. Si ce n'est que ça m'a l'air chiant de tracer
chaque surface une à une.

Francescu

Le 4 décembre 2012 14:27, Romain MEHUT romain.me...@gmail.com a écrit :

 Bonjour,

 Je ne saisis pas la distinction entre amenity=parking et
 amenity=parking_space.
 http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

 Doit-on comprendre qu'il s'agit de dessiner le contour des emplacements de
 stationnements dans l'emprise plus grande d'un parking?

 Auriez-vous des exemples à montrer?

 Merci.

 Romain

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




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


Re: [OSM-talk-fr] parking ou parking_space?

2012-12-04 Diskussionsfäden HELFER Denis
Perso, j'utilise parking_space (depuis peu) pour localiser sous forme de point, 
un emplacement handicapé (avec capacity :disabled=1|2|n) et parking pour 
localiser sous forme de point ou surface des parkings plus étendus ; j'indique, 
quand j'ai l'info, capacity :disabled=n). C'est ma pratique actuelle 
susceptible de changer.

Denis

De : Romain MEHUT [mailto:romain.me...@gmail.com]
Envoyé : mardi 4 décembre 2012 14:27
À : Discussions sur OSM en français
Objet : [OSM-talk-fr] parking ou parking_space?

Bonjour,

Je ne saisis pas la distinction entre amenity=parking et amenity=parking_space.
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Doit-on comprendre qu'il s'agit de dessiner le contour des emplacements de 
stationnements dans l'emprise plus grande d'un parking?

Auriez-vous des exemples à montrer?

Merci.

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


[OSM-talk-fr] OSM mapper Haute Savoie et Bassin Genevois + Fablab

2012-12-04 Diskussionsfäden frmone

Bonjour,

Un tour de table pour savoir si il y des Mappers OSM en haute savoie et 
bassin Genevois pour organiser une rencontre.


J 'en profite aussi pour une demande d'information sur les Fablab.
En janvier avec des amis ayant ou travaillant au Cern nous voulions 
monter un dossier pour la création d'un  fab lab 
http://www.artilect.fr/index.php?page=fablab.php  au alentour du Cern 
côté français. (il y a un fablab en construction sur Genève).


Donc si il y a des informations sur le sujet, des contacts, ou personnes 
intéressées.


Bon mapping a + fred

frmoine at gmail.com



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


Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction en cours

2012-12-04 Diskussionsfäden sly (sylvain letuffe)
On lundi 3 décembre 2012, Vincent Privat wrote:
 Peut-être que Sly pourrait demander à passer admin en tant que membre du
 DWG ?

Je ne suis pas intéressé par prendre en charge ce type d'opérations, mais je 
pense que n'importe qui peut en faire la demande à simon, peut-être 
re-contactera-t-il alors le DWG pour demander leur avis, auquel cas 
j'indiquerais être favorable (pour peu que mon opinion ait un sens)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Philippe Verdy
Note: gsw=alémanique inclue aussi l'alémanique helvétique (parlé en
Suisse), qu'on ne doit pas confondre avec l'allemand helvétique, ni les
Suisses allemands (les habitants de Suisse parlant une des variétés de
l'allemand) On entend souvent l'expression « la Suisse alémanique » pour
désigner toute la région de Suisse où une variété de l'allemand est parlée
majoritairement sans pour autant que ce soit l'alémanique).

La langue officielle allemande parlée en Suisse est codée de-CH mais
diffère en fait très peu de l'allemand standard (de) tel qu'il est parlé en
Allemagne (de-DE) ou en Autriche (de-AT).

Les différences mineures entre l'allemand de Suisse et l'allemand
d'Allemagne, sont sur des règles de capitalisation parfois différentes, des
conventions différentes pour formater les dates ou écrire des nombres, sur
la capitalisation ou non du “Ess-Tsett” (nom donné en allemand pour ce
qu'on appele en français « S dur », en anglais « sharp S », mais qu'on
traduit littéralement en français « SZ », bien que le “Ess-Tsett” allemand
a le plus souvent valeur de double S, contrairement au hongrois où c'est
plutôt l'inverse) L'Allemand du Tyrol (au Sud-Est de la Suisse au nord-est
de l'Italie et en majeure partie en Autriche) est en fait difficile à
distinguer de l'allemand d'Autriche (de-AT), hormi quelques particularismes
lexicaux (et quelques contractions ou simplifications grammaticales dans
les déclinaisons ou termes composés accolés où une mutation de consonnes
morphémiques s'est produite, plus souvent d'ailleurs dans la partie
italienne sous l'influence justement de l'italien : la fréquence des
emprunts latins est un peu plus importante dans le Tyrol que le reste de la
Suisse, de l'Allemagne ou de l'Autriche, et on a aussi des emprunts plus
nombreux de langues d'Europe centrale, y compris des racines slaves, via le
hongrois, le tchèque, le slovène).

L'alémanique suisse est parfois aussi appelé suisse allemand (à tord), ce
qui prète à confusion ; c'est pourtant l'origine du code ISO 639 gsw =
German Switzerland alors que ce nom anglophone devrait être codé de-CH
selon BCP 47, le code de désignant en fait langue unique avec des
particulariités seukement régionales qui ne créent pas de problèmes de
compréhensio nmutuelle, les emprunts allant librement d'une variété
régionale à l'autre (il ne faut PAS lire les codes langues comme si c'était
des abréviations signifiantes, ce sont JUSTE des codes correspondant à une
classification linguistique). Mais la norme ISO 639-2 (et encore plus la
norme ISO 639-1 plus ancienne) n'est pas exempt de certaines approximations
historiques, que seule la norme ISO 639-3 a corrigées en apportant plus de
précision d'abord aux familles des langues et en raffinant les anciens
codes collectifs considérés comme macro-langiues en plan terminologique,
mais composées de plusieurs langues au plan lexical et grammatical

(Ces améliorations de ISO 639-3 ne pas prises en compte dans BCP 47 qui
continue d'utiliser les codes ISO639-1 plus courts pour raison de
compatibilité, quitte à leur ajouter des codes pays, même si BCP 47 accepte
maintenant les nouveaux codes ISO 639-3, tant qu'ils ne sont pas considérés
comme des alias des codes plus courts... ou parfois plus longs aussi quand
ils ajoutent un code pays non nécessaire, par exemple quand BCP 47 a crû
traduire au début gsw comme un alias de de-CH, cela a été bloqué de
justesse, mais le nom synonyme « suisse allemand » n'a pas été évité, il
est juste non reommandé et on préfère lire gsw comme « alémanique ».si gsw
avait été défini avec le nom principal « suisse allemand », comme de-CH
alors que cela n'a rien à voir, cela aurait été faux pour l'alsacien, et
même l'alémanique du Rhénanie allemande, les deux variantes majeures non
suisses de l'alémanique auraient alors du être recodés à part dans ISO
639-3).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] parking ou parking_space?

2012-12-04 Diskussionsfäden Philippe Verdy
Si on considère le stationnement latéral le long des rues, cela n'en fait
pas des parkings pour autant (un parking a une réglementation de
circulation différente avec des piétons qui traversent n'importe où : la
vitesse est limitée, et aujourd'hui souvent renforcée par des gendarmes
couchés des panneaux de limitation à 30 et des chicanes imposées).

On n'a pas ça pour les places de stationnement des rues où on ne peut pas
sortir à gauche du véhicule sans danger immédiat, si les places sont
parallèles à la rue. En revanche si les places le long de la rue sont en
épi, on pourrait les désigner l'ensemble de ces places comme parking
(sauf qu'il n'y aura pas de voie de service pour y aller, ce sera la rue
normale.

Bref parking_space serait plutôt pour désigner ces places de stationnement,
qui ne sont pas à proprement parler des parkings. On est loin du
micro-mapping car souvent cela concerne des bandes assez étendues (un
parking space pourrait être limité à un seul trait parallèle à la route)
même si parmi elles on a des places réservées pour handicapés.

Et c'est indépendant du fait que le parkinf ou les places de stationnement
soient payants ou non.

Maintenant si certains veulent aussi tracer avec parking_space les places
disponibles dans un parking, une à une en un point ou avec un rectangle,
pourquoi pas, ce n'est pas incompatible avec le fait qu'elles sont déjà
regroupés dans l'espace parking — qui inclue aussi dans sa surface les
voies de service et la réglementation de circulation, les chemins piétons
éventuels, des poubelles, des arrêts de bus, des vendeurs itinérants, des
places de livraison ou d'arrêt-minute, des emplacements pour deux-roues ou
vélo, des rangements pour caddies, des arbres ou massifs centraux, des
îlots directionnels ou protecteurs, des buttoirs latéraux, et même des
carrefours et rond-points entre voies de service, avoir avec une rue
normale, cependant limitée en vitesse même s'il y a des passages piétons
protégés, la rue traversant le parking comme dans les centres commerciaux
en bordure d'une nationale : souvent pour protéger les traversées piétons
dans le parking, des ronds-points sont maintenant créés juste à l'entrée de
la rue dans la zone du parking, ce qui oblige tous les véhicules à ralentir
et observer facilement la priorité des piétons encombrés sur les passages
protégés.



Le 4 décembre 2012 14:35, Francescu GAROBY windu...@gmail.com a écrit :

 Bonjour,
 Je n'ai jamais utilisé parking_space mais, tel que je comprends la chose,
 je vois bien ce tag pour faire du micro-mapping, afin de faire ressortir
 les places pour handicapés, numérotées/attribuées, familiales, ...
 Après, qu'il faille détailler chaque place par un point ou par une
 surface, j'ai pas d'avis tranché. Si ce n'est que ça m'a l'air chiant de
 tracer chaque surface une à une.

 Francescu

 Le 4 décembre 2012 14:27, Romain MEHUT romain.me...@gmail.com a écrit :

  Bonjour,

 Je ne saisis pas la distinction entre amenity=parking et
 amenity=parking_space.
 http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

 Doit-on comprendre qu'il s'agit de dessiner le contour des emplacements
 de stationnements dans l'emprise plus grande d'un parking?

 Auriez-vous des exemples à montrer?

 Merci.

 Romain

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




 --
 Cordialement,
 Francescu GAROBY


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


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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden RatZilla$
Sans oublier le petit dernier:
http://mlm.jochentopf.com/
Gael
On Dec 4, 2012 12:21 PM, Christophe Merlet red...@redfoxcenter.org
wrote:

 Le mardi 04 décembre 2012 à 12:01 +0100, Nolwenn a écrit :
  Le mardi 4 décembre 2012 11:58:03 Christophe Merlet a écrit :
  
   Reste à développer la traduction de ces cartes en s'appuyant sur
   Wikipedia...
 
  Et de nomino http://nomino.comptoir.net/ (
 http://gitorious.org/nomino/nomino)

 Pas mal comme appli. Simple et efficace.
 Par contre, je viens de me rendre compte que nominatim sortait la
 relation de la commune, mais pas le nœud place, et c'est sur ce nœud
 place que j'avais pris l'habitude de mettre les traductions...

 Bon, après tout, ce n'est pas insensé de remonter les traductions au
 niveau supérieur...


 Librement,
 --
 Christophe Merlet (RedFox)


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

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


Re: [OSM-talk-fr] parking ou parking_space?

2012-12-04 Diskussionsfäden Francescu GAROBY
Pour les places de parking le long d'une rue, il existe
parking:lanehttp://wiki.openstreetmap.org/wiki/Key:parking:lane,
avec plusieurs avantages : ces tags sont associés à la route qui longe les
places de parking, permet de différencier le coté gauche et le coté droit
(par rapport à l'orientation de la way qui représente la route), prévoit
les différents types de parkings (épis, perpendiculaires à la route, ...).

Francescu

Le 4 décembre 2012 15:31, Philippe Verdy verd...@wanadoo.fr a écrit :

 Si on considère le stationnement latéral le long des rues, cela n'en fait
 pas des parkings pour autant (un parking a une réglementation de
 circulation différente avec des piétons qui traversent n'importe où : la
 vitesse est limitée, et aujourd'hui souvent renforcée par des gendarmes
 couchés des panneaux de limitation à 30 et des chicanes imposées).

 On n'a pas ça pour les places de stationnement des rues où on ne peut pas
 sortir à gauche du véhicule sans danger immédiat, si les places sont
 parallèles à la rue. En revanche si les places le long de la rue sont en
 épi, on pourrait les désigner l'ensemble de ces places comme parking
 (sauf qu'il n'y aura pas de voie de service pour y aller, ce sera la rue
 normale.

 Bref parking_space serait plutôt pour désigner ces places de
 stationnement, qui ne sont pas à proprement parler des parkings. On est
 loin du micro-mapping car souvent cela concerne des bandes assez étendues
 (un parking space pourrait être limité à un seul trait parallèle à la
 route) même si parmi elles on a des places réservées pour handicapés.

 Et c'est indépendant du fait que le parkinf ou les places de stationnement
 soient payants ou non.

 Maintenant si certains veulent aussi tracer avec parking_space les places
 disponibles dans un parking, une à une en un point ou avec un rectangle,
 pourquoi pas, ce n'est pas incompatible avec le fait qu'elles sont déjà
 regroupés dans l'espace parking — qui inclue aussi dans sa surface les
 voies de service et la réglementation de circulation, les chemins piétons
 éventuels, des poubelles, des arrêts de bus, des vendeurs itinérants, des
 places de livraison ou d'arrêt-minute, des emplacements pour deux-roues ou
 vélo, des rangements pour caddies, des arbres ou massifs centraux, des
 îlots directionnels ou protecteurs, des buttoirs latéraux, et même des
 carrefours et rond-points entre voies de service, avoir avec une rue
 normale, cependant limitée en vitesse même s'il y a des passages piétons
 protégés, la rue traversant le parking comme dans les centres commerciaux
 en bordure d'une nationale : souvent pour protéger les traversées piétons
 dans le parking, des ronds-points sont maintenant créés juste à l'entrée de
 la rue dans la zone du parking, ce qui oblige tous les véhicules à ralentir
 et observer facilement la priorité des piétons encombrés sur les passages
 protégés.



 Le 4 décembre 2012 14:35, Francescu GAROBY windu...@gmail.com a écrit :

 Bonjour,
 Je n'ai jamais utilisé parking_space mais, tel que je comprends la chose,
 je vois bien ce tag pour faire du micro-mapping, afin de faire ressortir
 les places pour handicapés, numérotées/attribuées, familiales, ...
 Après, qu'il faille détailler chaque place par un point ou par une
 surface, j'ai pas d'avis tranché. Si ce n'est que ça m'a l'air chiant de
 tracer chaque surface une à une.

 Francescu

 Le 4 décembre 2012 14:27, Romain MEHUT romain.me...@gmail.com a écrit :

  Bonjour,

 Je ne saisis pas la distinction entre amenity=parking et
 amenity=parking_space.
 http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

 Doit-on comprendre qu'il s'agit de dessiner le contour des emplacements
 de stationnements dans l'emprise plus grande d'un parking?

 Auriez-vous des exemples à montrer?

 Merci.

 Romain

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




 --
 Cordialement,
 Francescu GAROBY


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



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




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


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Philippe Verdy
Les prairies pour faire paître les animaux et les champs de culture ne sont
pas distinguables : les agriculteurs les font tourner car la culture du
maïs par exemple épuise les sols. Ensuite il cultive de l'herbe pour
l'ensilage, et à la fin du cycle ils y mettent leurs bêtes. Ça s'appelle la
jachère et c'est mieux que de faire les cultures toujours dans le même
champ quand ils sont de toute façon à réserver des terres en jachère...

Bref Corine n'a pas tord sur ce sujet.

Le gros des cultures sert justement à produire de l'alimentation pour
bétail, mais les agriculteurs font assez souvent paître leurs animaux après
une récolte : les restes sur pieds (notamment certains vergers) sont vite
nettoyés et cela diversifie aussi leur alimentation et améliore la qualité
de la viande.

Qui n'a jamais vu des vaches se régaler dans un champ de pommiers, au point
de s'en rendre saoules avec les pommes qu'elles mangent qui ont déjà
commencé à fermenter et monter en alcool ? (Pour éviter des accidents comme
des vaches qui se cassent une patte, les agriculteurs ne laissent pas
longtemps les vaches : après les pommes qui restent sont trop avancées et
trop hautes en alcool). Gare aux vaches qui entrent dans un champ de
pommiers, elles vont jusqu'à bousculer l'arbre pour faire tomber les
fruits, tirer les branches basses pour les casser et bouffer tout ce qu'il
y a dessus, même le petit bois, arracher l'écorce des arbres pour lécher la
résine sucrée... Et ce n'est pas un filet ou 3 poteaux grillagés autour du
pommier qui va les empêcher d'approcher trop près. C'est pareil dans les
champs de betterave, de maïs, et tout ce qui est en fleur. Elles
s'intéressent particulièrement aux dernières pousses de l'année, les plus
riches en sucre et les moins ligneuses, qui leur économise des heures de
mastication.

Les oviculteurs font la même choses avec chèvres et brebis pour nettoyer
les champs après une culture : pas besoin de désherbant, elles arrachent
absolument tout ce qui dépasse, et mangent les racines avec ! Et pendant ce
temps-là l'agriculteur prépare son ensilage pour l'hiver dans un autre
champ, après le passage du troupeau il pourra labourer et resemer sans
désherber avant.

Le seul cas où la rotation ne se produit pas c'est dans les champs trop
accidentés pour les bêtes ou dont les cultures sont persistantes mais
fragiles (la vigne par exemple). Mais si un tracteur peut semer, le champ
connaîtra aussi la jachère et sera utilisé pour les animaux. Il arrive même
que l'agriculteur ne sème QUE pour faire paître son troupeau (aucune
récolte donc), ou en fin de période de jachère pour augmenter la production
azotée (pas de récolte non plus, cette culture légère sera labourée avec),
et donc enrichir le terrain sans avoir à ajouter des doses énormes
d'engrais azotés juste avant une culture (dont une bonne partie est
lessivée et est jetée en pure perte, tout en polluant les nappes).

Le 4 décembre 2012 13:18, PierreV belett...@hotmail.fr a écrit :

 Je pense que l'on pourrait l'utiliser pour affiner aussi le CLC qui
 confondais trop souvent les prairies pour les betes et champs pour
 cultiver...

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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Christian Rogel

Le 4 déc. 2012 à 12:21, Christophe Merlet a écrit :
 Pas mal comme appli. Simple et efficace.
 Par contre, je viens de me rendre compte que nominatim sortait la
 relation de la commune, mais pas le nœud place, et c'est sur ce nœud
 place que j'avais pris l'habitude de mettre les traductions...
 
 Bon, après tout, ce n'est pas insensé de remonter les traductions au
 niveau supérieur…

Pour rappel, les noms en breton des communes (1500) et des groupements
de communes de Bretagne sont sur les relations de limite, ce qui fait qu'on 
peut 
interroger ces noms sur un navigateur localisé en breton (Firefox).

L'ordre du jour pour la séance à la Cantine ne prévoit aucune participation de
l'Office public de la langue bretonne qui est pourtant à la pointe des usages
dans les TIC.

Grâce à lui et à des chercheurs de Lannion, des correcteurs orthographiques
existent sur LibreOffice, etc
Il y a aussi le moteur libre de traduction automatique Apertium qu'on peut voir
fonctionner (avec d'autres) sur le site de la Généralité de Catalogue 
(generalitat.cat)

Si certains veulent bien compléter la page FR:Noms multilingues sur le wiki, 
qu'ils se
sentent libres de le faire.


Christian Rogel




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


Re: [OSM-talk-fr] [osm-fr CA] Table ronde Langues de France et numérique

2012-12-04 Diskussionsfäden Philippe Verdy
Là encore le Wiki d'OSM se trompe: ISO 639-1 n'est pas directement un code
destiné à la traduction. ISO 639-1 est terminologique à la base, pas
lexicologique. ISO 639-2 est surtout destiné à la classification
bibliographique et inclut la classification terminologique dedans mais pour
faire certeines distinctions, les codes bibliographiques non destinés à
coder la langue ou la terminologie sont parfois distingués, surtout pour
les langues majeures qui ont des tonnes de variantes ignorées dans la
classification bibliographique.

ISO 639-3 ne contient AUCUN code de classification bibliographique, ni
terminologique, leur usage est bien lexicologique et grammatical (mais pas
lexicographique, l'écriture utilisée ou la convention orthographique
n'étant pas utilisée). De plus il n'y a AUCUN code spécial, ou réservé, ni
nouvelle macrolangue (pas au départ), ni collections de langues dans ISO
639-3, mais ISO 639-3 reprend les autres codes ISO 639-2 terminologiques
des langues considérées comme individuelles). ISO 639-3 peut aussi être
amené à changer une langue individuelle en macro-langue, pour coder de
nouvelles distinctions lexicologiques ou grammaticales.

Pour réunir tout ça pour la localisation et les traductions, la référence
c'est BCP 47 qui fait le tri et retient les codes à utiliser (mais avec une
interprétation NON exclusive des groupes de langues ISO 639-2 dits «
résiduels », contrairement à ISO 639-5 qui n'est pas utilisé dans ISO
639-3, ni dans BCP 47 (sauf pour BCP 47 pour les codes collectifs
ISO-639-2, résiduels ou inclusifs, pour des raisons de compatibilité
ascendante).

Plus aucune nouvelle famille de langue ne sera codée comme un « groupe
résiduel » dans ISO 639-5, elles seront toutes inclusives, et jamais codées
dans ISO 639-3, ni ISO-639-2 et même ISO 639-1 dont les registres sont clos
(sauf correction nécessaire pour en faire SOIT des collections de langues
selon ISO 639-5 rassemblant des langues individuelles (non précisées) de
l'ISO 639-3, SOIT des macro-langues restant dans ISO 639-3 mais dont ISO
639-3 énumère la liste exhaustive des langues individuelles codées aussi
dans l'ISO 639-3).

A l'heure actuelle, les collections inclusives ou résiduelles de l'ISO
639-5 ne sont pas énumérées, la classification des familles étant encore
sujète à débat. Ce n'est pas le cas des macro-langues qui sont créées ad
hoc dans ISO 639-3 justement pour distinguer des langues individuelles
auparavant considérées comme une seule (avec des variétés dialectales alors
non distinguées, qu'elles soient régionales, ou selon l'âge, le sexe, le
rang social... mais qui deviennent des langues à part entière, mais encore
sans distinction de l'écriture et de l'orthographe).

Il n'existe pratiquement aucun logiciel à se servir DIRECTEMENT de l'ISO
639 (sauf ceux qui se basent encore uniquement sur ISO 639-1 et se limitent
aux codes à 2 lettres et utilisent encore les distinctions régionales avec
les codes pays, par exemple zh-TW ou zh-CN, une pratique qui n'est PLUS DU
TOUT recommandée et remplacée par la codification des macrolangues dans ISO
639-3).

La norme actuelle pour la localisation des logiciels et les traductions
cela reste BCP 47 (actuellement RFC 4646 ou suivants) qui décrit en détail
l'utilisation du registre IANA des étiquettes de langues pour BCP 47. Pas
d'inquiétude : tous les codes ISO 639-3 et ISO 639-5 y sont décrits, au
moins en tant qu'alias vers les codes plus courts recommandés quand ils
existent dans ISO 639-1 (c'est même le cas des cods ISO 639 qui ont été
supprimés ou remplacés/fusionnés : BCP 47 les redéfinit alors comme alias,
si possible, ou les laisse dans leur forme ambiguë si aucun remapping vers
un code préféré n'est clair.

Avantage : les traductions codées avec BCP 47 restent stables, même si la
norme ISO 639 change ou retire des codes (ils sont bien retirés de l'ISO
639 mais encore utilisables dans BCP47 même s'ils ne sont plus recommandés
pour les nouveaux documents).

BCP 47 rend également stable les codes d'écriture à 4 lettres de l'ISO
15924, et les codes géographiques à 2 lettres de pays et territoires de
l'ISO 3166-1 ou les codes géographiques à 3 chiffres pour les continents et
sous-continent d'UN M.59, et BCP 47 permet AUSSI des distinctions de
variétés dialectales non codées directement dans ISO 639 (ce projet prévu
de codification des dialectes dans futur un volet 6 de l'ISO 639, avec des
codes à 5 lettres ou plus n'est pas encore abouti, il va falloir des énnées
pour ça. les codes à 5 lettres ou plus restent TOUS réservés dans ISO 639,
comme dans BCP 47, les codes à 4 lettres servant à autre chose : la
maintenance des codes ISO 639-1/2/3/5 retirés, objet du volet 4 de l'ISO
639).

Le 4 décembre 2012 15:34, Christophe Merlet red...@redfoxcenter.org a
écrit :

 Le mardi 04 décembre 2012 à 14:23 +0100, Philippe Verdy a écrit :
  A mon avis il cherchait alsacien sous le code als (mauvais code
  encore utilisé par Wikipédia pour son nom de domaine et ses liens
  interwikis, et 

Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction terminée

2012-12-04 Diskussionsfäden sly (sylvain letuffe)
On dimanche 2 décembre 2012, Eric SIBERT wrote:
  Je fais la demande pour la rédaction dans la soirée ou demain.
 
 Tu nous tiens au courant quand c'est terminé, qu'on lâche les termites...

RIP données, voilà qui est fait.
Le 1ere changeset est le 14138736 et le dernier le 14152442.
Tout ça visible ici :
http://www.openstreetmap.org/user/pnorman%20redaction%20revert/edits

Bon courage aux termites (bizarre, à l'écrire, ça fait un peu moins noble que 
fourmis) pour la suite.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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


Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction terminée

2012-12-04 Diskussionsfäden Philippe Verdy
Les termites sont déjà passés. En fait il n'y a eu qu'un seul gros termite
qui a fait des trous partout sur la place à dessin.

Les fourmis dispersées vont patiemment les reboucher et faire le ménage des
poussières qui traînent : observez une fourmilière c'est propre et net tout
au tour, les tracés sont bien marqués et ça circule vite et bien sans se
tromper de chemin et sans se disperser (contrairement aux termites qui sont
peu pressés, vont partout même si ça ne leur est pas très profitable, mais
font de gros dégâts sans qu'on les voit, et ne nettoient rien derrière eux
quand ils sont déjà passés sur leur chantier).

Mais dans les deux cas termites et fourmis sont organisés, les fourmis
étant toutefois beaucoup plus sociales : le termite travaille le plus
souvent tout seul, même si pour une reine à plusieurs ils peuvent aussi
construire des cathédrales (mais quels lambins, en plus il bouffe autant
leur cathédrale qu'ils la construisent, ce qui fait de la termitière
surtout un tas d'ordure pour leur déchets et une halte garde-manger avant
l'étape suivante, quand les ressources à proximité commencent à s'épuiser :
ils fécondent leur reine, meurent sur place (la reine enfermée dans le tas
d'ordure se fera bouffer par les petits qui repartiront à l'aventure en
abandonnant la termitière pour en fonder une autre plus loin à la limite de
leur zone d'exploration).

Dans les villes et forêts, les termites n'ont pas besoin de faire de
termitière : les ressources sont là à profusion (les fourmis ont aussi
leurs petites fourmilières mais bien planquées, si on repère facilement là
où elles passent difficile de savoir où elles se regroupent ; mais on peut
difficilement piéger la fourmi : elle communique et invente toujours un
moyen pour contourner un obstacle, pas le termite). Le termite peut se
reproduire sur place dans son garde manger et ne se soucie pas de la
propreté : le termite est donc facile à trouver, ce qui ne veut pas dire
qu'il soit très accessible : en général il se fait discret et on ne le voit
pas, quand on le voit on ne voit plus que lui, partout. La fourmi elle
ramène toujours la nourriture chez elle et en évacue ses déchets. Si on en
a trouvé une ou même un grand nombre, on ne sait pas où sont les autres.

On sait qu'une fourmi est passée par les trous qu'elles ont laissé là où
elle a découpé sa nourriture, mais aussi parce que ses vas-et-viens a tracé
un chemin où passe encore ses consœurs. Il est rare qu'une fourmi massacre
son garde-manger, elle fait en sorte qu'il puisse encore produire pour
elle. On trouvera donc des plantes rabougries mais toujours vivantes. Le
termite lui tue don hôte s'il est vivant, en lui ôtant sa protection et sa
solidité. Rien ne l'arrêtera tant qu'il ne se sera pas effondré ou aura été
réduit en un tas de déchets.

Mais le termite est vagabond, il reviendra tôt ou tard si on y a remis de
quoi manger, et il suit toujours le chemin de la nourriture, ce qui le rend
facile à piéger. La fourmi elle se fait oublier et ne va que là où c'est le
plus intéressant pour elle, elle apprend de ses erreurs et le transmet aux
autres. Elle laisse derrière elle une trace chimique indélébile qu'on peut
trouver si on  regarde (le termite lui ne laisse pas grand chose derrière
puisqu'il ne déplace pratiquement pas la matière, il utilise ses déchets
comme refuge pour se cacher et rester encore plus invisible, ou rendre
invisible la trace de ses dégâts).

On se débarrasse donc plus facilement de la fourmi (qui ira facilement
faire ses emplettes ailleurs) que du termite qui reste sur place et a de
quoi tenir si rien ne vient ! il s'endort, laisse une petite succession
peu exigeante derrière lui, qui aura tôt fait de redevenir nombreuse à la
première occasion.

Sur OSM donc qui est le gros termite, qui sont les petites fourmis ?


Le 4 décembre 2012 16:35, sly (sylvain letuffe) li...@letuffe.org a écrit
:

 On dimanche 2 décembre 2012, Eric SIBERT wrote:
   Je fais la demande pour la rédaction dans la soirée ou demain.
 
  Tu nous tiens au courant quand c'est terminé, qu'on lâche les termites...

 RIP données, voilà qui est fait.
 Le 1ere changeset est le 14138736 et le dernier le 14152442.
 Tout ça visible ici :
 http://www.openstreetmap.org/user/pnorman%20redaction%20revert/edits

 Bon courage aux termites (bizarre, à l'écrire, ça fait un peu moins noble
 que
 fourmis) pour la suite.

 --
 sly
 qui suis-je : http://sly.letuffe.org
 email perso : sylvain chez letuffe un point org

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

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


Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction terminée

2012-12-04 Diskussionsfäden Ab_fab
Ouuuhhh, Philippe a fait une blague ... et je l'ai comprise !!

Le 4 décembre 2012 17:16, Philippe Verdy verd...@wanadoo.fr a écrit :



 Sur OSM donc qui est le gros termite, qui sont les petites fourmis ?


 Le 4 décembre 2012 16:35, sly (sylvain letuffe) li...@letuffe.org a
 écrit :

 On dimanche 2 décembre 2012, Eric SIBERT wrote:
   Je fais la demande pour la rédaction dans la soirée ou demain.
 
  Tu nous tiens au courant quand c'est terminé, qu'on lâche les
 termites...

 RIP données, voilà qui est fait.
 Le 1ere changeset est le 14138736 et le dernier le 14152442.
 Tout ça visible ici :
 http://www.openstreetmap.org/user/pnorman%20redaction%20revert/edits

 Bon courage aux termites (bizarre, à l'écrire, ça fait un peu moins noble
 que
 fourmis) pour la suite.

 --
 sly
 qui suis-je : http://sly.letuffe.org
 email perso : sylvain chez letuffe un point org

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



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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Suppression des tirets cadratins

2012-12-04 Diskussionsfäden Philippe Verdy
Le 4 décembre 2012 09:50, Pieren pier...@gmail.com a écrit :

 Quand tu auras réparé quelques frontières cassées par des débutants
 qui ne comprennent pas les 'relations', on en reparlera ;-)


Je te rejoins là dessus ! Combien de fois j'ai déjà vu un commentaire de
modification dans la base par quelqu'un qui supprime un chemin de frontière
avec l'idée suivante : il n'y a aucune route à cet endroit là, ce trait me
gène pour retracer autre chose qui est bien visible, allez hop ! je vire ce
truc qui ne sert à rien !

Et voilà il envoie SES objets et n'a rien à faire des autres relations que
de toute façon il n'a même pas chargées; il vagabonde sur la carte dans
JOSM en ne chargeant presque rien de la base (il ne pouvait donc rien voir
du tout, la seule chose qui l'intéresse c'est l'image Bing, et ce ne sont
pas les hacuures par dessus l'image qui le gênent, il sait très bien qu'il
n'a pas chargé toutes les données de la zone mais n'a pas non plus chargé
les relations dépendantes des objets qu'il supprime ou scinde en plusieurs
parties, ou bien qu'il remplace par d'autres en traçant d'abord SON chemin,
puis en virant l'autre).

Et cela ne concerne pas QUE les débutants, un oubli est vite arrivé. Un
champ name en revanche est toujours visible, partout chaque fois qu'on
sélectionne le moindre objet. Sur un chemin frontière il n'indique aucune
priorité droite-gauche, juste une association de deux noms, même si pour
clarifier les choses et stabiliser la présentation on peut fixer une règle
simple : l'objet le plus peuplé vient en premier.

Pour rendre les modifs claires, également, on trie les objets, même si dans
la base ou pour le rendu ce n'est pas nécessaire. On précise aussi les
rôles inner/outer afin aussi de permettre de recoller les morceaux en cas
de casse ultérieure : on voit vite ce qui a été cassé et comment réparer,
et on laisse un schéma propre (ceux qui utilisent Potlatch n'ont pas cette
option de tri, mais eux ils voient TOUS les objets dépendants (mais sont
contraints de travailler sur des zones de plus en plus petites : ils sont
incapables de regarder quelquechose de la taille d'une commune entière, les
relations frontalières plus grandes qu'un quartier ou un petit village ne
sont donc pas créées par eux, ni même les routes les plus longues, ils ont
même du mal à charger et voir toute une rue dans une ville dense).

Bref Potlatch c'est bien pour des modifs très locales (c'est même plus
précis et plus facile et rapide à faire dans Potlatch que dans JOSM : par
exemple affiner un tracé pour justement ajouter d'autres détails autour).
Les deux éditeurs sont donc complémentaires plutôt que concurrents. Mais la
plupart des utilisateurs ne savent utiliser que l'un ou l'autre et ont du
mal à se faire à la différence d'interface.

Mais même dans Potlatch, il est difficile de savoir à quoi correspond un
trait : tous les traits se ressemblent, et le dialogue affichant un nom est
souvent masqué. Si quelquechose apparait dans la vue Simplifiée, ce ne
sera JAMAIS une note=, mais le name= au moins y sera. On ne verra pas
les types de boundary ou admin_level.

Le name est la meilleure balise permettant de savoir qu'il y a quelquechose
et que c'est une frontière. De plus l'éditeur de relations de Potlatch est
très pénible à utilisé tellement il est minimaliste et mal foutu : on a tôt
fait de se tromper car on ne voit que des identifiants numériques et pas
grand chose d'autre (aucune analyse de connexité ou des membres en doublons
ou manquants).

Il n'y a pas d'outil idéal, mais JOSM maitrisé permet d'aller plus loin que
Potlatch. JOSM fonctionnera bien pour tracer rapidement la structure de
quelque chose qu'on affinera ensuite dans Potlatch. Et j'utilise aussi
rawedit pour certaines modifs directes en XML (dans Osmose), limitées
seulement à quelques attributs (non géométriques et non relationnels comme
les listes de membres, mais éventuellement pour corriger un rôle erroné)
dans le même objet et faciles à éditer sans erreur dans le XML (Osmose
revérifiera derrière si on marque même si on marque corrigé, car l'ovjet
a changé alors de version, Osmose ne signale plus rien sur un objet marqué
faux positif tant que l'objet lui-même n'a pas changé de version depuis
l'analyse qui l'avait signalé).

Osmose est rapide : quelques minutes après la modif (avec les minute diffs
quand elles sont actives), l'objet est à nouveau analysé (mais les erreurs
non marquées corrigées dessus persistent toutes car la modif peut avoir été
faite sans tenir compte de l'anomalie précédente, ce qui peut là encore
induire en erreur les modificateurs (qui vont alors aggraver le problème en
supposant que c'était correct avant leur passage et que si erreurs ils font
ce n'est pas de leur faute). si on a corrigé comme il fallait, il ne
signalera rien derrière la modif.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM

2012-12-04 Diskussionsfäden Ab_fab
Message long, mais sujet intéressant, en particulier pour ta réflexion sur
le regroupement des classes du RPG dans quelque chose de raisonnable pour
osm.

Pourrais-tu mettre ça à plat dans le wiki ?

Pour la suite, un outil qui simplifierait à l'échelle d'une commune (ou un
peu plus vaste)
_ la fusion de parcelles proches de même nature,
_ en tenant compte de ce qui existe déjà dans OSM en terme de landuse,
_ tout en gardant des polygones de taille raisonnable,

ce serait super

Le 4 décembre 2012 14:01, Mickaël Guéret m.gue...@free.fr a écrit :

 Le mardi 04 décembre 2012 à 04:18 -0800, PierreV a écrit :
  Je pense que l'on pourrait l'utiliser pour affiner aussi le CLC qui
  confondais trop souvent les prairies pour les betes et champs pour
  cultiver...
 
 Je l'ai utilisé pour affiner les landuses. Le RPG est aussi intéressant
 par ses trous, qui permettent de savoir ou se trouve les zones
 naturelles (forêts, étangs, ...) les zones résidentielles, les cours de
 fermes (farmyard), les zones industrielles...

 Je n'utilise pas de wms, mais plutôt le fichier shapefile fournit sur le
 site http://www.data.gouv.fr/ que je redécoupe avec les limites d'une
 commune (pour des raisons de taille de fichier). Les données de cultures
 peuvent être intéressantes, je sépare les cultures annuelles - céréales
 à pailles, maïs, oléoprotéagineux, prairies temporaires... -
 (landuse=farmland) des prairies permanentes, estives et landes (landuse
 = meadow ou natural = scrub, parfois je redécoupe), vergers (landuse =
 orchard), vignes (landuse = vineyard), etc...

 Attention, le polygones du RPG sont des ilots, qui ne correspondent
 pas aux parcelles de culture (1 ilot = 1 ou plusieurs parcelles). Le
 code de culture associé à l'ilot correspond à la culture de la parcelle
 la plus grande. Autre limite quand on regarde sur Geoportail, certaines
 prairies permanentes ne le sont plus l'année suivante, et vice-versa...

 Les polygones du RPG sont très moches, je les fusionne,
 simplifie/affine/corrige avec Bing. La commune de Moutiers-sous-Argenton
 est presque terminée :
 http://www.openstreetmap.org/?lat=46.961lon=-0.3692zoom=14layers=M

 Le shapefile d'origine est là :
 http://demo.ovh.net/fr/620c58e1c97a2395b98a379bf12315a9/

 C'est un boulot de fourmi... j'estimerais à plus de 25h pour cette seule
 commune... Je voulais voir si je pouvais y arriver...

 Et désolé pour la longueur du message !

 Mika_Gueret


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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Grosse suppression de données autour de valenciennes - rédaction terminée

2012-12-04 Diskussionsfäden Philippe Verdy
Attention les premières fourmis qui sortent de leur œuds dans la
fourmilière qu ileur apportait toute la nourriture, et qui commencent à
partir à l'aventure ne reconnaissent pas encore les chemins tracés par
leurs sœurs.

La fourmi a alors tendance à aller au hasard dans tous les
sens. Heureusement la fourmilière veille et aura tôt fait de ramener
l'aventurière et à savoir où elle est passée (car l'aventurière raconte son
aventure et a aussi laissé une foule de traces derrière elle: on la repère
vite).

Elle ne sait pas non plus ce qu'elle mange et peut piquer et vouloir tuer
son garde-manger (elle le fait surtout si elle se sent attaquée et
elle-même en danger, et peut alors ameuter des cohortes de nouvelles venues
pour tout saccager). On ne laisse pas une aventurière errer sans la
surveiller ou la guider. Cette aventurière peut apprendre mais il faut lui
montrer qu'elle n'est pas en danger et peut tirer encore profit de la
cohésion de la fourmilière. La fourmi aventurière aussi ne saura pas
comment se battre efficacement. Pas de retraite, elle commencera pas piquer
tout ce qui bouge ou pase à portée de ses mandibules.

Si l'action de la fourmilière ne suffit pas, il restera le termite pour lui
barrer la route. il engloutira goulûment les petites provisions disséminées
par l'aventurière il ne restera que quelques déchets épars. Aucune autre
fourmi ne reproduira le même chemin, les fourmis nettoieront et
réensemenceront le terrain qui redeviendra fertile, et entre temps
l'aventurière aura appris ce qu'il faut pour agir dans le sens de la
fourmilière.

Les fourmis aventurières sont à peine sorties de leur restau à domicile et
qui croient que ce sera ailleurs le même repas gratuit et offert à elles
comme à ses autres petites sœurs encore dans leurs œufs. Du temps de la
fourmilière, on leur apportait même la climatisation, il n'y avait aucun
vent mauvais. Maintenant qu'elles sont dehors, les voilà à devoir apprendre
comment tracer leur chemin pour retrouver la fourmilière et pour indiquer
aux autres comment la suivre. Et aussi elles vont apprendre à participer à
la ventilation de la fourmilière pour permettre l'éclosion de la génération
suivante.

Si une jeune fourmi a bien fait son travail et si la mère meure, la fourmi
sera désignée comme nouvelle reine et alors passera son temps à pondre
ses successeurs, elle ne participera plus aux travaux des champs mais
regardera le travail des ouvrières et organisera les défenses en cas
d'attaque. Mais imbue d'elle-même, elle se gavera dans la complaisance et
l'autosatisfaction, en racontant combien on l'a félicitée pour son travail
passé. Mais attention, si la reine se prélasse trop, elle risque d'oublier
de pondre ses œufs et les ouvrières qui attendaient cela partiront à
l'aventure pour créer une nouvelle fourmilkère, élire une nouvelle reine
parmi elles, et plus pressée de développer la nouvelle colonie et organiser
ses défenses. On aura alors deux fourmilières en guerre l'une contre
l'autre pour concqérir un même territoire commun, la seconde remplaçant
vite la première où se prélasse encore la reine qui a oublié de renouveler
la génération suivante.

Sur OSM, qui est la fourmilière ? Qui sont les jeunes fourmis aventurières ?


Le 4 décembre 2012 17:26, Ab_fab gamma@gmail.com a écrit :

 Ouuuhhh, Philippe a fait une blague ... et je l'ai comprise !!

 Le 4 décembre 2012 17:16, Philippe Verdy verd...@wanadoo.fr a écrit :



 Sur OSM donc qui est le gros termite, qui sont les petites fourmis ?


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


[OSM-talk-fr] [forum-osm-fr] Comment indiquer les arrêts de bus ?

2012-12-04 Diskussionsfäden forum
Le message suivant de :
##
Après avoir consulter le wiki j'hésite encore sur le bon choix à faire.



Dans le village il y a des arrêt de bus avec abris, d'autre sans abris. 
Certains ont une place pour les bus en renfoncement par rapport aux voie de 
circulation et d'autre pas du tout.

En fait je ne comprend pas la différence entre Stop position et Plateforme 
bus. Est ce que je doit matérialisé les place pour bus qui ne sont pas sur les 
voie de circulation ? Les abris sont souvent à l'écart de l'arrêt du bus, Est 
ce que je peut les indiquer clairement où ils ce trouvent ?

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum-liste
peuvent être posées à sylvainaletuffe.org

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


Re: [OSM-talk-fr] Panne des minutes diffs France

2012-12-04 Diskussionsfäden Jocelyn Jaubert
Le 03/12/2012 13:51, THEVENON Julien a écrit :
 Je viens de relancer, et ça devrait rapidement récupérer le retard.
 
 Super, merci !

C'est maintenant à jour.


-- 
Jocelyn

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


  1   2   >