Re: [talk-ph] talk-ph Digest, Vol 62, Issue 14
try using time album. this comes when you buy columbus trackker From: talk-ph-requ...@openstreetmap.org talk-ph-requ...@openstreetmap.org To: talk-ph@openstreetmap.org Sent: Thursday, September 19, 2013 1:16 PM Subject: talk-ph Digest, Vol 62, Issue 14 Send talk-ph mailing list submissions to talk-ph@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-ph or, via email, send a message with subject or body 'help' to talk-ph-requ...@openstreetmap.org You can reach the person managing the list at talk-ph-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of talk-ph digest... Today's Topics: 1. Ervin's Mapping Advocates blog post (Eugene Alvin Villar) 2. recommended csv format (Rally de Leon) 3. Re: recommended csv format (Jim Morgan) 4. Re: recommended csv format (Wayne Manuel) 5. Re: recommended csv format (Ed Garcia) 6. Re: recommended csv format (Rally de Leon) -- Message: 1 Date: Thu, 19 Sep 2013 00:56:47 +0800 From: Eugene Alvin Villar sea...@gmail.com To: OpenStreetMap Philippines talk-ph@openstreetmap.org Subject: [talk-ph] Ervin's Mapping Advocates blog post Message-ID: CAPhqi6Lh1=g9BZRtH12C3Z07suE7=CyNQ2wNK60V8JYx=rm...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi guys, Ervin has posted a nice article on his blog where he interviewed volunteer mappers who contribute to OSM, RoadGuide.ph, WaypointsDotPH, and Google Map Maker: http://www.s1expeditions.com/2013/09/100-philippinemappingadvocates.html The OSM interviewees include myself, Maning, Ian, Ed, Rem, and Tutubi. There's also Rally. :) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-ph/attachments/20130919/8ef2c3ed/attachment-0001.html -- Message: 2 Date: Thu, 19 Sep 2013 11:22:26 +0800 From: Rally de Leon rall...@gmail.com To: OSM talk-ph@openstreetmap.org Subject: [talk-ph] recommended csv format Message-ID: ca+m6697r3jcyokpuur7gkbuuupsbh1phyhvmlkh-e4jwadb...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Dear all, Which is the more common / preferred format for csv lat,long,name or long,lat,name? and why do you prefer one over the other? (eg. less hassle, less clicks to import csv to common GIS softwares) If I am to recommend to ordinary people a free conversion utility, which one? (my 2 preferred utility have different csv format) If i use gpsbabel's generic (Comma separated values) option (eg. kml to csv conversion)--- gpsbabel -w -i kml -f filename.kml -o csv -F filename.csv csv will be in this order--- lat,long,name If i use another easy-to-use/free/multi-platform KMLCSV (from http://choonchernlim.com/kmlcsv/ ) kml to csv conversion will give you--- long,lat,name KMLCSV is very easy to use and allows ordinary people to view the POI's on built-in google maps for quick verification. easy to install, easy to distribute, virtually idiot-proof. GPSBabel is universal, has gui and command line, but has too many option-buttons that can be confusing for ordinary user. or is there a way gpsbabel can convert (kml to csv) or (osm to csv) in long,lat,name csv format? Thanks, Rally -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-ph/attachments/20130919/8d64a876/attachment-0001.html -- Message: 3 Date: Thu, 19 Sep 2013 12:06:05 +0800 From: Jim Morgan j...@datalude.com To: talk-ph@openstreetmap.org Subject: Re: [talk-ph] recommended csv format Message-ID: 523a782d.4010...@datalude.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On Thursday, 19 September, 2013 11:22 AM, Rally de Leon wrote: lat,long,name or long,lat,name? and why do you prefer one over the other? (eg. less hassle, less clicks to import csv to common GIS softwares) Just my opinion: when people talk about co-ordinates, they normally talk about Lat and Long (almost never Long and Lat), so they should probably be in that order! I'd say gpsbabel has it right, and your other software is swimming against the tide. The advantage of XML formats as opposed to CSV, is that they specify that each point is either lat/lat or long/long so there is no ambiguity. Jim -- Message: 4 Date: Thu, 19 Sep 2013 12:15:52 +0800 From: Wayne Manuel wdman...@gmail.com To: Rally de Leon rall...@gmail.com Cc: OSM talk-ph@openstreetmap.org Subject: Re: [talk-ph] recommended csv format Message-ID: ca+d-fotru3qaf4hp3_7hbpfvm2cz0vdcnruit3mapunu_h+...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Personally, I prefer lat-long. Easier to tell people that it should be alphabetical. And that at least in the PHL
Re: [OSM-talk-be] (geen onderwerp)
Allemaal bedankt voor de nuttige tips. Guy Vanvuchelen -Oorspronkelijk bericht- Van: Ben Laenen [mailto:benlae...@gmail.com] Verzonden: woensdag 18 september 2013 18:55 Aan: talk-be@openstreetmap.org Onderwerp: Re: [OSM-talk-be] (geen onderwerp) On Wednesday 18 September 2013 17:58:36 Guy Vanvuchelen wrote: Daardoor wordt mijn fietspad te gemakkelijk vastgeklikt aan die landuse en dat is natuurlijk niet de bedoeling. Om te vermijden dat je nieuwe lijnen worden vastgemaakt aan bestaande lijnen, moet je control ingedrukt houden terwijl je nieuwe punten toevoegt. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] [Sentier disparu par cause de vegetation]
[EN] Hello everyone, How to map paths that have disappeared during my last visit because of the vegetation (shrubs and brambles)? Access to the path became impracticable without mulcher. At this point, I mapping the trails like this: highway = path access = no trail_visibility = no What do you think? thank you [FR] Bonjour à tous, Comment cartographier des sentiers qui ont disparu lors de mon dernier passage à cause de la végétation (arbustes et ronces)? L'accès au chemin est devenu impraticable sans débrousailleuse. En ce moment, je cartographie ces sentiers comme ceci: highway=path access=no trail_visibility=no Qu'en pensez-vous? Cordialement, Jean-Louis Stanus *Jean-Louis Stanus* ☎ +32 473761482 [image: Google Talk] *http://goo.gl/WSMDO* ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
Hallo Jean=Louis, access=no means that nobody has the right to go on the path, not that it is not possible. I vaguely remember seeing a similar discussion on the tagging mailing list a couple of months ago. Don't remember the outcome. can't find it right now found something on the help forum: https://help.openstreetmap.org/questions/16293/tagging-impassible-footpaths(main suggestion is to contact whoever is responsible for the path) regards m On Thu, Sep 19, 2013 at 11:12 AM, Jean-Louis Stanus jl.sta...@gmail.comwrote: [EN] Hello everyone, How to map paths that have disappeared during my last visit because of the vegetation (shrubs and brambles)? Access to the path became impracticable without mulcher. At this point, I mapping the trails like this: highway = path access = no trail_visibility = no What do you think? thank you [FR] Bonjour à tous, Comment cartographier des sentiers qui ont disparu lors de mon dernier passage à cause de la végétation (arbustes et ronces)? L'accès au chemin est devenu impraticable sans débrousailleuse. En ce moment, je cartographie ces sentiers comme ceci: highway=path access=no trail_visibility=no Qu'en pensez-vous? Cordialement, Jean-Louis Stanus *Jean-Louis Stanus* ☎ +32 473761482 [image: Google Talk] *http://goo.gl/WSMDO* ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 11:37, Marc Gemis wrote: Hallo Jean=Louis, access=no means that nobody has the right to go on the path, not that it is not possible. Indeed, access=no is a different context. You might also want to check out this tag: http://wiki.openstreetmap.org/wiki/Key:smoothness Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 12:31, Glenn Plas wrote: On 2013-09-19 11:37, Marc Gemis wrote: access=no means that nobody has the right to go on the path, not that it is not possible. Indeed, access=no is a different context. You might also want to check out this tag: http://wiki.openstreetmap.org/wiki/Key:smoothness To be more complete, this tag has been under scrutiny lately, and other proposals exist. Just follow the hotlinks. There is another proposal here: http://wiki.openstreetmap.org/wiki/Proposed_features/surface_unification#surface:condition Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
Sommige paden zijn zo overwoekerd van gras en onkruid (zelfs struiken) dat ze onbegaanbaar zijn. Zodra het maaien toegestaan is (juni?) worden ze opgekuist maar enkele maanden later zijn ze weer onbegaanbaar. Het hangt er dus echt vanaf wanneer je die paden gaat verkennen. Hetzelfde met sommige tracks die gewoon omgeploegd en gezaaid worden. Daarna rijdt de boer er enkele keren met de tractor over zodat de weg weer min of meer zichtbaar wordt. Men zou moeten kunnen mappen dat ze 'periodiek' toegankelijk zijn. Guy Vanvuchelen -Oorspronkelijk bericht- Van: Glenn Plas [mailto:gl...@byte-consult.be] Verzonden: donderdag 19 september 2013 12:40 Aan: OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] [Sentier disparu par cause de vegetation] On 2013-09-19 12:31, Glenn Plas wrote: On 2013-09-19 11:37, Marc Gemis wrote: access=no means that nobody has the right to go on the path, not that it is not possible. Indeed, access=no is a different context. You might also want to check out this tag: http://wiki.openstreetmap.org/wiki/Key:smoothness To be more complete, this tag has been under scrutiny lately, and other proposals exist. Just follow the hotlinks. There is another proposal here: http://wiki.openstreetmap.org/wiki/Proposed_features/surface_unification#sur face:condition Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] [Sentier disparu par cause de vegetation]
Ik ga akkord met je glenn dus ik gebruik dat: no highway key maar alleen deze: designation=public_footpath dank u alles Cordialement, Jean-Louis Stanus *Jean-Louis Stanus* ☎ +32 473761482 [image: Google Talk] *http://goo.gl/WSMDO* 2013/9/19 talk-be-requ...@openstreetmap.org Send Talk-be mailing list submissions to talk-be@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-be or, via email, send a message with subject or body 'help' to talk-be-requ...@openstreetmap.org You can reach the person managing the list at talk-be-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-be digest... Today's Topics: 1. Re: (geen onderwerp) (Ben Laenen) 2. Re: (geen onderwerp) (Guy Vanvuchelen) 3. [Sentier disparu par cause de vegetation] (Jean-Louis Stanus) 4. Re: [Sentier disparu par cause de vegetation] (Marc Gemis) 5. Re: [Sentier disparu par cause de vegetation] (Glenn Plas) 6. Re: [Sentier disparu par cause de vegetation] (Glenn Plas) 7. Re: [Sentier disparu par cause de vegetation] (Guy Vanvuchelen) 8. Re: [Sentier disparu par cause de vegetation] (Glenn Plas) -- Message transféré -- From: Ben Laenen benlae...@gmail.com To: talk-be@openstreetmap.org Cc: Date: Wed, 18 Sep 2013 18:55:12 +0200 Subject: Re: [OSM-talk-be] (geen onderwerp) On Wednesday 18 September 2013 17:58:36 Guy Vanvuchelen wrote: Daardoor wordt mijn fietspad te gemakkelijk vastgeklikt aan die landuse en dat is natuurlijk niet de bedoeling. Om te vermijden dat je nieuwe lijnen worden vastgemaakt aan bestaande lijnen, moet je control ingedrukt houden terwijl je nieuwe punten toevoegt. Ben -- Message transféré -- From: Guy Vanvuchelen guy.vanvuche...@gmail.com To: 'OpenStreetMap Belgium' talk-be@openstreetmap.org Cc: Date: Thu, 19 Sep 2013 08:12:35 +0200 Subject: Re: [OSM-talk-be] (geen onderwerp) Allemaal bedankt voor de nuttige tips. Guy Vanvuchelen -Oorspronkelijk bericht- Van: Ben Laenen [mailto:benlae...@gmail.com] Verzonden: woensdag 18 september 2013 18:55 Aan: talk-be@openstreetmap.org Onderwerp: Re: [OSM-talk-be] (geen onderwerp) On Wednesday 18 September 2013 17:58:36 Guy Vanvuchelen wrote: Daardoor wordt mijn fietspad te gemakkelijk vastgeklikt aan die landuse en dat is natuurlijk niet de bedoeling. Om te vermijden dat je nieuwe lijnen worden vastgemaakt aan bestaande lijnen, moet je control ingedrukt houden terwijl je nieuwe punten toevoegt. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Message transféré -- From: Jean-Louis Stanus jl.sta...@gmail.com To: talk-be@openstreetmap.org Cc: Date: Thu, 19 Sep 2013 11:12:57 +0200 Subject: [OSM-talk-be] [Sentier disparu par cause de vegetation] [EN] Hello everyone, How to map paths that have disappeared during my last visit because of the vegetation (shrubs and brambles)? Access to the path became impracticable without mulcher. At this point, I mapping the trails like this: highway = path access = no trail_visibility = no What do you think? thank you [FR] Bonjour à tous, Comment cartographier des sentiers qui ont disparu lors de mon dernier passage à cause de la végétation (arbustes et ronces)? L'accès au chemin est devenu impraticable sans débrousailleuse. En ce moment, je cartographie ces sentiers comme ceci: highway=path access=no trail_visibility=no Qu'en pensez-vous? Cordialement, Jean-Louis Stanus *Jean-Louis Stanus* ☎ +32 473761482 [image: Google Talk] *http://goo.gl/WSMDO* -- Message transféré -- From: Marc Gemis marc.ge...@gmail.com To: OpenStreetMap Belgium talk-be@openstreetmap.org Cc: Date: Thu, 19 Sep 2013 11:37:07 +0200 Subject: Re: [OSM-talk-be] [Sentier disparu par cause de vegetation] Hallo Jean=Louis, access=no means that nobody has the right to go on the path, not that it is not possible. I vaguely remember seeing a similar discussion on the tagging mailing list a couple of months ago. Don't remember the outcome. can't find it right now found something on the help forum: https://help.openstreetmap.org/questions/16293/tagging-impassible-footpaths(main suggestion is to contact whoever is responsible for the path) regards m On Thu, Sep 19, 2013 at 11:12 AM, Jean-Louis Stanus jl.sta...@gmail.comwrote: [EN] Hello everyone, How to map paths that have disappeared during my last visit because of the vegetation (shrubs and brambles)? Access to the path became impracticable without mulcher. At this point, I mapping the trails like this: highway = path access = no trail_visibility = no What do you think? thank you [FR] Bonjour à
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On Thursday 19 September 2013 14:22:01 Jean-Louis Stanus wrote: Ik ga akkord met je glenn dus ik gebruik dat: no highway key maar alleen deze: designation=public_footpath designation=public_footpath doesn't mean anything on itself (that tag doesn't have a definition in Belgium anyway), a highway tag is a bare minimum that's needed to map a path... Saying that the path is almost inaccessible most time of the year has to be done with extra tags. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 14:22, Jean-Louis Stanus wrote: Ik ga akkord met je glenn dus ik gebruik dat: no highway key maar alleen deze: designation=public_footpath dank u alles Bonjour Jean-Louis, Je croix que sans 'highway key' c'est une erreur, le plus correct est de le garder et en plus, ajoute l'autre cle (alors ce n'est pas une replacement mais ajoutement). En faite, c'est encore une 'highway' , meme si il n'est pas physiquement accessible... Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Future Dreams for OSM
Apparently during SOTM participants could vote for the future features of OSM. There is a wiki page about this: http://wiki.openstreetmap.org/wiki/Future/Dreams It's possible to add your own comments. m p.s. stolen from the Dutch forum, where you can post your comments as well http://forum.openstreetmap.org/viewtopic.php?id=22614 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] GIS contact gemeente Mol
Today I had a meeting with the GIS responsible for Mol. She stumbled by accident upon OSM and found some of my changes which were coinciding with editing work she was doing in AGIV and contacted me. We had an interesting talk this afternoon where I gave here an overview about what OSM is and what's going on in BE. She concludes that one one hand there is a lot of duplication (compared to AGIV) in what we're doing - which will hopefully be reduced by importing the CRAB DB, but on the other hand there are also lots of potential synergies where the government might benefit from work done by the OSM community. While this is by no means a possible onset for government instances to use OSM i.s.o. big G as their default map in many of their web sites, I see this as a nice opportunity to create awareness and give more visibility to OSM at the level of municipalities. One step at a time... She suggested that it might be interesting to present OSM on one of the many meetings organized for GIS staff. I'm not expert enough to do this, so here I am looking for volunteers to pick this up and take it further. I can provide phone and e-mail contact. Gilbert ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Imports in the North of the province of Antwerp
Whatever makes you happy ;-). I prefer to tag such building as a building = church, including the tower. I may have encountered one exception so far where the church tower was not part of the church building. But those are rare... My 2 cents.. Gilbert On 18 September 2013 12:38, Glenn Plas gl...@byte-consult.be wrote: I must have missed the as part of a bigger building. before. I thought it was only used on stand alone constructions. I did not move the node yet. It is still at the position of the import. I'll move it and add the bell_tower tower type. I share your sentiment, when I think of man_made=tower, I think cooling towers, big antenna towers etc. It would not be something I would have done personally. Glenn __**_ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talk-behttps://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Imports in the North of the province of Antwerp
On Thu, Sep 19, 2013 at 7:55 PM, Gilbert Hersschens gherssch...@gmail.comwrote: I prefer to tag such building as a building = church, including the tower. I may have encountered one exception so far where the church tower was not part of the church building. But those are rare... The same for me, but I don't like to delete things that other people created if they are not incorrect. m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] House number problem
This evening I stumbled upon some buildings in Willebroek, where the housenumbers on the ground floor are different from the ones on the first floor. In general, we put the number on the complete building, but that's impossible in this case. So I will add different nodes which will also get a addr:floor. I assume this starts with 0 for the ground floor. Correct ? regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] House number problem
The wiki at lesat mentions 1;2 There seem to be several proposal around, and I'm not sure what the best way is. In any case, level/floor 0 is ground floor. Kurt On Thu, Sep 19, 2013 at 09:42:19PM +0200, Marc Gemis wrote: This evening I stumbled upon some buildings in Willebroek, where the housenumbers on the ground floor are different from the ones on the first floor. In general, we put the number on the complete building, but that's impossible in this case. So I will add different nodes which will also get a addr:floor. I assume this starts with 0 for the ground floor. Correct ? regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice (user's and software's)
On 2013-09-17 01:40, Glenn Plas wrote : On 2013-09-17 01:02, André Pirard wrote: On 2013-09-16 11:52, Glenn Plas wrote : If you want to be serious about this then a new topic should be initiated by sending a new mail instead of a reply with a new subject. Every decent mailclient out there -usually- does not use the subject to 'thread' mails. instead it uses certain fields in the mail headers. I noticed that mail-man (the mailing list handler of THIS list) does not seem to add those headers (in fact, they seem to be removed from outgoing mails, I cannot find those fields like below). example of those are : References: 20130914070031.83C7A1561AD6@server21 CANHB50fV+JQ_DYnu91QYaURcRyAKk-pqbHGFMQmYzQZAeC=x...@mail.gmail.com 5236af60.2050...@byte-consult.be In-Reply-To: 5236af60.2050...@byte-consult.be This is what the (E)mailers usually use when exchanging mail correspondence (non mailing list) when hitting 'Reply' To be complete: top-posting (putting comments ABOVE the previous messages) is usually really a big nono in the mailing list fields. You should put follow-up comments BELOW the original mail. Personally, It doesn't bother me too much, but on plenty of mailing lists people go absolutely nuts over that fact , more true on long email exchanges, as you need to read a long reply from bottom to top in order to follow the conversation. Of course many clients let you sort using the subject field. If you make sure to bottom-post, automatically you'll be removing the non-relevant sections at the top to compact the response. I admit , when being too quick, I'm a sinner too against that rule once in a while. Some lists have their own requirements, but in general bottom-posting is considered Netiquette, top-posting isn't. It makes you scroll twice to follow a conversation. (go down to find the start, then read up). English : http://en.wikipedia.org/wiki/Posting_style You're right, my main gripe is against the mailing list software mailman itself because it does not allow HTML. It does archive a HTML version of the archive but when you look at it on the server you see HTML code. By allow HTML, I mean simple HTML: text style, lists, tables etc, not eccentric showy stuff. I've sent an e-mail to mailman about this and they replied * that we, technical people, do not need HTML because we don't use it much. I think you misunderstood my mail. At the very bottom of that partly quoted mail I stated : . I am very much against using html in mails. I believe HTML belongs on a website, not a mail. I prefer plain-text.. Sorry :) Glenn No, I didn't misunderstand your e-mail and I said 'You're right'. My topic is not what the users do but what mailman does and that's why my quote is partial. I restored the full English text here above, and no, what I had read does not contain I am very much against using html in mails and my text was not related to that phrase. I collaborated with the ietf guys for e-mail and MIME+HTML and I can tell you they are not dumb-asses. Millions of people are using what they did. People forget that the first reason to be of HTML is HT, hypertext http://en.wikipedia.org/wiki/Hypertext, which is as elegant as necessary to write sensible text, relegating with links the details to further reading. That does not belong only to Web site; some people even wrote HT books. It was also used in the precursors Gopher, WAIS etc. I sometimes use titles and index in long e-mails. I rarely write Web pages to send someone a message. What the ietf intended to include in e-mail is the simple HTML I speak of, not the extravagant one. It allows tables to be included in e-mail. It allows HT links to be used without interspersing text with ugly URLs. It allows basic formating. Your reference, which isn't at all against HTML, advocates the blockquote as a better way to quote text to avoid paragraphs ending up like this one or the last one you quote. blockquote certainly does not belong to websites!!! See following e-mail. Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice (user's and software's)
On 2013-09-17 05:29, Marc Gemis wrote : André, in digest mode, your mails are replaced by a link to the html content. In non-digest mode your mails appear fine. The result is that I never read your mails on the tagging mailing list that I follow i digest mode. It's just too much work to open an additional page to see whether it's interesting enough to read. Hi Marc, Thanks for your report, but that's strange. I always send my e-mails to the list in both text and html formats (alternative in the same e-mail), so that everybody should be pleased. But they're not! The text mode is (almost) perfectly readable on the archive server https://lists.openstreetmap.org/pipermail/talk-be/2013-September/004552.html, also containing a link to the html version that they call an attachment (they seem not to understand the word alternative). Of course, the tables that we sometimes need to send are pure garbage in text mode. I explained how I'm using a Gmail account as a perfect mailing list archiver. I also use the filters of Gmail as a perfect e-mail redistributor, like a manually maintained mailing list, the only problem is that the number of recipients is limited. Definitely, that mailman is the most antediluvian and frustrating software there is. A conspirator. Please file a bug and ask them to work as well as Gmail and to implement simple HTML filtering. followed below ... (1) archive server lists.openstreetmap.org/pipermail/talk-be/2013-September/004552.html for those who prefer not to click On 2013-09-17 13:23, ael wrote : On Tue, Sep 17, 2013 at 01:02:23AM +0200, André Pirard wrote: On 2013-09-16 11:52, Glenn Plas wrote : If you want to be serious about this then a new topic should be initiated by sending a new mail instead of a reply with a new subject. Every decent mailclient out there -usually- does not use the subject to 'thread' mails. instead it uses certain fields in the mail headers. I noticed that mail-man (the mailing list handler of THIS list) does not seem to add those headers (in fact, they seem to be removed from outgoing mails, I cannot find those fields like below). You're right, [but] my main gripe is against the mailing list software mailman itself because it does not allow HTML. Please, please no. HTML should only be in an attachment if and only if it cannot be avoided. Apart from bloat, it is a security risk. Email != HTML. Attachment? Content-Type: multipart/mixed; boundary1107514545383645585== This is a multi-part message in MIME format. --===1107514545383645585== Content-Type: *multipart/alternative*; boundary=060707090800060503050609 This is a multi-part message in MIME format. --060707090800060503050609 Content-Type: *text/plain*; charset=UTF-8 Content-Transfer-Encoding: 8bit --060707090800060503050609 Content-Type: *text/html*; charset=UTF-8 Content-Transfer-Encoding: 8bit --060707090800060503050609-- Can't you see that word *alternative***? *You can choose***!!! If you prefer to use text, please do, but do not prevent those who understood HTML to use it!!! Security: correction: the security risk is Windows and similar software. Read it: what I advocate is simple html for which there is absolutely no security risk. Those who launch a full browser, and especially an unsafe one running Javascript and, worse, Activethings, to display *any html* e-mail take as much risk as when displaying a Web page. Using simple html or filtering e-mail to obtain simple html as I suggested or interpreting only the simple part of html is perfectly safe, especially on a virus resistant system like Linux or OS X. Some may remember the RTF (rich text format) specification that people that you may want to call crazy have used in e-mail before html existed to allow what I advocate, for example writing a letter in e-mail. No one ever spoke of risk before RTF was abandoned and HTML deviated. The mad thing is this (just an example): X-Mailer: Microsoft Outlook Express 6.00.2900.3138 BODY text=3D#00 bgColor=3D#ff DIVFONT face=3DArial size=3D2Monsieur ... /FONT/DIV DIVFONT face=3DArial size=3D2/FONTnbsp;/DIV DIVFONT face=3DArial size=3D2Je vousnbsp;rappelle .../FONT/DIV a s o for more than 50 lines, switching to the same font font for every paragraph, even empty ones. And Apple Mail is even worse. They ignore the philosophy of simple HTML that is to use no font, just a size number, no line width, the user adjusts to his convenience, etc... Now here's Thunderbird doing more complicated: ul li.../li li.../li /ul p.../p pCheers,br And here's an OSM simple HTML page speaking: ul lia href=http://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=fr view-source:http://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=frbicycle/a = yes/li lia href=http://wiki.openstreetmap.org/wiki/Key:foot?uselang=fr
Re: [OSM-talk-be] House number problem
On 2013-09-19 21:42, Marc Gemis wrote : This evening I stumbled upon some buildings in Willebroek, where the housenumbers on the ground floor are different from the ones on the first floor. In general, we put the number on the complete building, but that's impossible in this case. So I will add different nodes which will also get a addr:floor. I assume this starts with 0 for the ground floor. Correct ? You may tag the house number on a node of the house. This helps the number and the name not fighting for the same place. I was doing that when I noticed they're doing it in France too. Any node is OK unless it's common to 2 houses, of course. The best is to add a node in the middle of the front wall. In your case, several even spaced and in the street order. Yes, ground=0, just as year 0 so that -1 is not a multiple of 4. I learned that in the States when I burst in a hurry into a ladies' room. Right number, just next to the hotel lift, but wrong floor. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[talk-au] Some help testing a mkgmap file requieed
Hi I have been working away on making Garmin maps but have struck a rather typical Garmin issue. Anyway if you can have a look it would be much appreciated. https://skydrive.live.com/redir?resid=D994A45D28184300!429 Here is the link to the Ent_World.img file. The issue is on the search feature. I am using a Rino 650 and Garmin 62s. Now on the Rino it is near impossible to find anything as it assume Hu is all you need and finds a few things but nothing I want. The 62S is annoying as the find using the spell feature, while slow, finds the item, say Huntsman Lake but when I select automotive routing it calculates to 86% then fades out like the batteries have failed. A few sets of batteries later and this issue appears to be with the unit. So what I am trying to identify is my Garmin 62S is on the way out and is the Rino search been knobbled by Garmin. Also as a run Garmin topo maps and Shonky occasionally the map only shows contours. Copy and deleting the img files and then restarting the unit then shutting it down and copying back the img files works. Why? No idea!!! Anyway, please have a look and see how it works. I am in the process of developing the maps for Australia wide and striking a rather large number of issues. The best was the contour lines cut using a very large polygon of many points. The I5 after seven days and seven nights had barely made a dent but my I7 crunched the data in no time. Um? Ok yes it is a faster processor but my Asus eepc with the mighty atom processor did the job in five hours. Turns out the later version of phyghtmap is considerably more efficient than the version that the instruction for Windows referred to and I had put the more recent version on the I7. Anyway experimenting with a full 64 bit version and gradually pieced together something that appears to be working but still waiting for it to work through the download. Oh, and yes using very elaborate polys for the state boarders is not a good idea as was mentioned by a fellow forum member. Almost got there with Victoria using OSMCONVERT to cut the poly but then struck the issue of the sea flooding inland. Talk about global warming. So I will be using a simpler poly for further testing. Cheers Brett ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
Guten Tag liebe Listenmitglieder, Ich mappe zwar schon seit einiger Zeit bei OSM, aber bisher immer kleinere Teile und kleine Mulitpolygone. Nun ist mir ein Missgeschick passiert, dass ich ein für mich nicht gleich erkennbares großes verschachteltes MP gelöscht habe. Ich habe die verschiedenen Landuse neu angelegt und lade diese sukzessive seit einigen Tagen auf den Server, aber das nimmt gar kein Ende mehr. Wer kennt sich mit dem Reverter-Plugin aus und kann Hilfestellung geben. Meines Erachtens ist der Fehler im Datensatz bzw. Änderungssatz 17905663 bei mir passiert. Das liegt nördlich von Berlin und betrifft Neuruppin bzw. von Alt-Ruppin östlich bis ca. Gransee und nördlich bis ca. Rheinsberg. Allerdings gibt es auch jede Menge inzwischen neu angelegter Flächen, die sauber sind. Wie bekomme ich das Problem in den Griff. Ich bin ganz klein und zerknirscht. Wer kann mir helfen? Liebe Grüße Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
Am 19.09.2013 14:38, schrieb Klaus Steiner: Ich mappe zwar schon seit einiger Zeit bei OSM, aber bisher immer kleinere Teile und kleine Mulitpolygone. Nun ist mir ein Missgeschick passiert, dass ich ein – für mich nicht gleich erkennbares – großes verschachteltes MP gelöscht habe. Ich habe die verschiedenen Landuse neu angelegt und lade diese sukzessive seit einigen Tagen auf den Server, aber das nimmt gar kein Ende mehr. Wer kennt sich mit dem Reverter-Plugin aus und kann Hilfestellung geben. Meines Erachtens ist der Fehler im Datensatz bzw. Änderungssatz 17905663 bei mir passiert. Das liegt nördlich von Berlin und betrifft Neuruppin bzw. von Alt-Ruppin östlich bis ca. Gransee und nördlich bis ca. Rheinsberg. Allerdings gibt es auch jede Menge inzwischen neu angelegter Flächen, die sauber sind. Wie bekomme ich das Problem in den Griff. Ich bin ganz klein und zerknirscht. Wer kann mir helfen? Hi, Monsterpolygone sind unnötig. Falls möglich solltest Du die Gelegenheit nutzen, die Flächen in handhabbare Größen aufzuteilen bzw. neu anzulegen, ohne MP-Technik. Wälder z.B. können prima an durchführenden Straßen aufgeteilt werden. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, PSG
Hallo Christoph, Ich werde schauen, ob ich eine kurze Beschreibung zusammenstellen kann. :-) die aktuelle OSM-Küstenlinie ist etwa 2 Millionen km lang Quelle ist die OSM-Küstenlinie Wie ist diese Zahl zu bewerten in Bezug auf die 356.000 km (CIA) In Wikipedia hat das aber natürlich nichts zu suchen. Warum nicht? OSM ist inzwischen eine reputable Quelle... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, PSG
On 19/set/2013, at 16:48, Markus liste12a4...@gmx.de wrote: Warum nicht? Steht in dem WP. Artikel, es gibt nicht die Länge der Küste Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, PSG
Hallo Martin, wieso ausgerechnet die Küstenlinien? Weil die händische Korrektur der Sägezahnkurven eine ziemlich langwierige und stumpfsinnige Arbeit ist ;-) Bei derzeit 2 Mio km wären das seeehr viele km/aktivem Mapper... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
On 19.09.2013 16:46, chris66 wrote: Am 19.09.2013 14:38, schrieb Klaus Steiner: Ich mappe zwar schon seit einiger Zeit bei OSM, aber bisher immer kleinere Teile und kleine Mulitpolygone. Nun ist mir ein Missgeschick passiert, dass ich ein – für mich nicht gleich erkennbares – großes verschachteltes MP gelöscht habe. Ich habe die verschiedenen Landuse neu angelegt und lade diese sukzessive seit einigen Tagen auf den Server, aber das nimmt gar kein Ende mehr. Wer kennt sich mit dem Reverter-Plugin aus und kann Hilfestellung geben. Meines Erachtens ist der Fehler im Datensatz bzw. Änderungssatz 17905663 bei mir passiert. Das liegt nördlich von Berlin und betrifft Neuruppin bzw. von Alt-Ruppin östlich bis ca. Gransee und nördlich bis ca. Rheinsberg. Dafür reicht eigentlich das Undelete-Plugin. Einfach die Relation 57257 wieder herstellen (am besten in neuer Ebene) und nochmal drauf schauen. Erst wirst Du nichts sehen ausser einer Relation in der Relationsliste. Somit noch alle Mitglieder runterladen. Sag Bescheid, wenn du mehr Anweisungen brauchst, bzw ich es machen soll. Allerdings gibt es auch jede Menge inzwischen neu angelegter Flächen, die sauber sind. Wie bekomme ich das Problem in den Griff. Ich bin ganz klein und zerknirscht. Wer kann mir helfen? Passiert jedem mal. Das wichtige ist zeitnah sich zu melden. Monsterpolygone sind unnötig. Falls möglich solltest Du die Gelegenheit nutzen, die Flächen in handhabbare Größen aufzuteilen bzw. neu anzulegen, ohne MP-Technik. Wälder z.B. können prima an durchführenden Straßen aufgeteilt werden. +1 allerdings ist auch dieses einfacher, wenn Teil für Teil aus der Relation rausgelöst wird und nicht nur Linien ohne Merkmale existieren. Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, Küstenlänge
Hallo Martin, es gibt nicht die Länge der Küste Dennoch ist das eine Frage, die einige Menschen bewegt. Und wenn man in WP die Zahl des CIA-Factbooks angibt, dann könnte man diese ja relativieren mit der Zahl aus OSM... Nicht dass die Schulbuchautoren den Schülern nur die CIA-Zahlen weitergeben ;-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, Küstenlänge
Am 19. September 2013 17:54 schrieb Markus liste12a4...@gmx.de: Dennoch ist das eine Frage, die einige Menschen bewegt. Und wenn man in WP die Zahl des CIA-Factbooks angibt, dann könnte man diese ja relativieren mit der Zahl aus OSM... Nicht dass die Schulbuchautoren den Schülern nur die CIA-Zahlen weitergeben ;-) ich würde die CIA Zahl rausnehmen, macht einfach keinen Sinn Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
Hi! Klaus Steiner wrote Allerdings gibt es auch jede Menge inzwischen neu angelegter Flächen, die sauber sind. Wie bekomme ich das Problem in den Griff. Ich bin ganz klein und zerknirscht. Wer kann mir helfen? Denk Dir nichts dabei - die Schuld liegt nicht bei Dir sondern bei den Leuten die solche unwartbaren Monster anlegen. Ich würde nicht versuchen, die Löschung rückgängig zu machen, sondern die Gegend in kleinen Häppchen ohne Monster-MP restaurieren. Und wenn's eine Weile dauert - Reparaturen brauchen halt manchmal ein wenig. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Versehentlich-ein-Monster-Mulipoygon-nordl-von-Berlin-geloscht-benotige-DRINGEND-HILFE-tp5778114p5778180.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
Am 19. September 2013 20:39 schrieb NopMap ekkeh...@gmx.de: Denk Dir nichts dabei - die Schuld liegt nicht bei Dir sondern bei den Leuten die solche unwartbaren Monster anlegen. +1 diese Dinger haben auf Dauer schlechte Überlebenschancen und erschweren allen Mappern die weitere Bearbeitung. Praktisch immer sind sie unnötig. Die landuse Flächen sind am besten so klein wie sinnvoll möglich, ich würde schon bei der Ersterfassung versuchen, die bei jeder Gelegenheit zu schließen und die Monster, die es bereits gibt, sollte man jeweils in kleinere zerlegen, wenn man beim Mappen darauf stößt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Freitag, den 13.09.2013, 18:58 +0200 schrieb Philipp Klaus Krause: Eine Legende wäre schön. Die Geschwindigkeitskarte ist dank der Zahlen auf der Karte auch ohne verständlich, aber bei den anderen Merkmalen sieht es anders aus. Und auch für die Geschwindigkeit schadet eine Legende nicht. Ist alles in Arbeit. Die Karte ist ja auch noch nicht fertig und eher unfreiwillig hier publik geworden... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
Am Freitag, den 13.09.2013, 20:05 +0200 schrieb fly: On 11.09.2013 11:43, Alexander Matheisen wrote: Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein Taggingschema entwickelt, das bereits intensiv genutzt wird: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich erleichtert: https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml Leider finde ich Dein Preset nicht unter den externen Presets in JOSM, dafür ist es nötig im JOSM Trac auf der Preset-Seite die URL einzutragen. Da das Preset noch nicht endgültig fertig ist, habe ich bisher auch noch nicht dort eingetragen, was aber geplant ist. Super wäre es einen eigenen Style zur Verfügung zu stellen. Das geht bereits. Dazu musst du nur die MapCSS-Dateien und das Verzeichnis icons, die unter https://github.com/rurseekatze/OpenRailwayMap/tree/master/styles zu finden sind, in JOSM einbinden. Bisher habe ich das auf der Wikiseite der OpenRailwayMap noch nicht dokumentiert, aber das kommt noch... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Am 19. September 2013 22:09 schrieb Stephan Wolff s.wo...@web.de: Moin, kann ein geschlossener way Linie und Fläche zugleich sein, wenn er je ein tag hat, das nur als way und nur als Fläche definiert ist? Ist dann definiert, ob weitere tags die Linie oder die Fläche beschreiben? Konkret habe ich das Problem bei Inseln. Ist ein geschlossener way mit natural=coastline und place=island korrekt oder sollte der way nur natural=coastline und ein multipolygon (mit diesem way als outer) place=island tragen? In letzterem Fall wäre auch ein name-tag eindeutig der Fläche zuzuordnen. Die Frage ist nicht auf Inseln beschränkt. Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. ja, das beschränkt sich nicht auf Inseln, ich finde es prinzipiell besser, für unterschiedliche Objekte in der echten Welt auch unterschiedliche Objekte in OSM zu haben. Es ist in gewisser Weise akzeptierter Shortcut, die gleiche Geometrie mehrfach zu verwenden (z.B. building=supermarket, shop=supermarket) wenn die Lage und Ausdehnung gleich ist, aber das fällt einem meist früher oder später auf die Füße weil nicht mehr klar ist, auf welches Objekt sich weitere tags beziehen, z.B. height, wikipedia, name, etc. Gerade bei areas ist es ja einfach, über ein Multipoligon ohne weiteren Aufwand ein neues Objekt zu erstellen, und damit von Anfang an Klarheit zu schaffen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versehentlich ein Monster Mulipoygon nördl. von Berlin gelöscht, benötige DRINGEND HILFE !!!
On 19.09.2013 14:38, Klaus Steiner wrote: Ich mappe zwar schon seit einiger Zeit bei OSM, aber bisher immer kleinere Teile und kleine Mulitpolygone. Nun ist mir ein Missgeschick passiert, dass ich ein für mich nicht gleich erkennbares grosses verschachteltes MP gelöscht habe. Hallo Klaus, ich hatte auch schon mal versehentlich halb Franken entwaldet. Ich mag diesen riesen Polygone auch nicht. Da blickt dann keiner mehr durch. Die Flächen sollten überschaubar sein und sind es in der Natur ja normalerweise auch, da immer wieder Strassen die Gebiete abteilen. Ansonsten können nur noch Spezialisten an OSM arbeiten, was bestimmt nicht der Sinn ist. Man sollte die Gelegenheit nutzen, so was neu und besser einzutragen. Schlaf erst mal gut und mache Dich nicht verrückt. Mit lieben Grüßen Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Am 19.09.2013 22:09, schrieb Stephan Wolff: Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. Früher war alles besser, da hat man fenced=yes getaggt. :-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linie und Fläche zugleich
Moin, kann ein geschlossener way Linie und Fläche zugleich sein, wenn er je ein tag hat, das nur als way und nur als Fläche definiert ist? Ist dann definiert, ob weitere tags die Linie oder die Fläche beschreiben? Konkret habe ich das Problem bei Inseln. Ist ein geschlossener way mit natural=coastline und place=island korrekt oder sollte der way nur natural=coastline und ein multipolygon (mit diesem way als outer) place=island tragen? In letzterem Fall wäre auch ein name-tag eindeutig der Fläche zuzuordnen. Die Frage ist nicht auf Inseln beschränkt. Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Hi, On 19.09.2013 22:09, Stephan Wolff wrote: Die Frage ist nicht auf Inseln beschränkt. Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. Ich hab mal eine Reihe von Militaerinstallationen ge-armchair-mappt, bei denen habe ich stets einen Ring als barrier=fence/wall getaggt und dann ein Multipolygon mit diesem Ring als outer und landuse=military. Das sollte auf jeden Fall klar sein - waehrend mir ein Doppeltagging am Way doch etwas gefaehrlich vorgekommen waere. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 04.09.2013 01:10, schrieb Michael Kugelmann: OSM ist aber absolut auch nicht die große Daten-Müllhalde im Internet. Noch nicht, aber wir sind auf dem besten Wege. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 19.08.2013 20:21, schrieb Harald Schwarz: Hallo, ich habe angefangen die 299 Wahlkreise für die Bundestagswahl 2013 in OSM einzutragen. Mittlerweile sind wir bei den Stimmbezirken für den Bonner Stadtrat angekommen: http://www.openstreetmap.org/#map=14/50.7254/7.0897 Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Stephan Wolff s.wolff at web.de writes: Die Frage ist nicht auf Inseln beschränkt. Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. Wird aber AFAIR nicht gerendert. Ich lege in dem Fall die Fläche als Fläche an und ziehe eine davon unabhängige Linie mit barrier=fence außenrum. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Correggere traccia GPS
Penso che il problema si risolve facilmente. Non si tratta di pista ciclabile ma di un percorso ciclabile che utilizza vari tipi di strade. Dovrebbe essere cambiato in relazione in ogni caso. Ma questo si può solo fare se sappiamo che c'è segnaletica sul posto. Se non c'è segnaletica, non si mette, salvo che si tratti di una proposta di un percorso che avrà la sua segnaletica in futuro e che è documentata in un documento con la licenza adatta. Non c'è indicazione di source nel changeset. Una rapida ricerca Google per torvare un apista ciclabile no 855 non ha dato risultati. 2013/9/18 skantanader alessandro...@gmail.com dieterdreist wrote in effetti è un bel casino quel percorso, in (piccoli) parti non esiste ancora (come strada in OSM, ma sul foto aereo si vede), ma per lo più duplica strade esistenti. Per lo più sembra da cancellare... ciao, Martin ...infatti, a dirla tutta; per me il ragazzo si è fatto un giro in bici ed ha caricato la traccia come RE_cycle_track_855, intanto cerco se esiste veramente come circuito, e magari una qualche autunnale domenica proverò a seguire il percorso a vedere se è segnalato... grazie del supporto ragazzi, -alex- -- View this message in context: http://gis.19327.n5.nabble.com/Correggere-traccia-GPS-tp5778037p5778062.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Descrizione sito storico
Chiedo ancora lumi: ho 3 diversi punti in provincia di brescia dove in cima ad una montagna si trovano dei basamenti circolari in cemento che sono ciò che rimane delle postazioni dei cannoni posizionati durante la prima guerra mondiale. Come taggarli correttamente? E poi (solito mio dilemma) la seguente dicitura (che si trova anche sui cartelli posti lungo il sentiero per raggiungerli): Piazzole Artiglieria Alpina Guerra 1915-18 la metto come name o meglio come description:it? P.S.: ho notato che tutto ciò che ho spostato da name a description:it riguardante monumenti, memoriali oppure tourism=attraction non é più ritrovabile con questa funzione: http://nominatim.openstreetmap.org/ perché cerca appunto il tag name. Quindi vanno perse un sacco di informazioni. Cioé ci sono ma nessuno sà che ci sono quindi é come se non ci fossero. Che dite? Grazie, ciao --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Descrizione-sito-storico-tp5778089.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Descrizione sito storico
demon.box ha scritto: E poi (solito mio dilemma) la seguente dicitura (che si trova anche sui cartelli posti lungo il sentiero per raggiungerli): Piazzole Artiglieria Alpina Guerra 1915-18 la metto come name o meglio come description:it? Quello non è un nome, ma una descrizione, quindi andrebbe messa nel tag description. P.S.: ho notato che tutto ciò che ho spostato da name a description:it riguardante monumenti, memoriali oppure tourism=attraction non é più ritrovabile con questa funzione: http://nominatim.openstreetmap.org/ perché cerca appunto il tag name. Quindi vanno perse un sacco di informazioni. Cioé ci sono ma nessuno sà che ci sono quindi é come se non ci fossero. Il fatto che, al momento, non ci siano tool che evidenzino certe informazioni non è una ragione per utilizzare tag impropri. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Descrizione sito storico
Certo sono perfettamente d'accordo con te, tenendo conto poi che OSM per sua stessa natura ha ancora davanti a sé dei margini enormi di sviluppo! Bisogna però mappare correttamente fin da ora. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Descrizione-sito-storico-tp5778089p5778108.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osmose abilitato per l'Italia
Scusate, ma gli errori che compaiono mi sembra si riferiscano a dati di qualche mese addietro. -- View this message in context: http://gis.19327.n5.nabble.com/Osmose-abilitato-per-l-Italia-tp5776797p5778109.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osmose abilitato per l'Italia
2013/9/19 bredy bredy...@yahoo.it: Scusate, ma gli errori che compaiono mi sembra si riferiscano a dati di qualche mese addietro. Me l'hanno detto anche i francesi. Bisogna capire a che data si riferiscono gli estratti presenti su FMACH. Le analisi vengono rifatte ogni giorno. Luca, potresti controllare? Grazie, Cristian ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Embed di una mappa OSM con immagini sa satellite/aeree
Ciao a tutti, il LUG di Bergamo (BGLUG)[1], ha creato questo minisito per il Linux Day[2a] (a Bergamo, appunto), (qui l'annuncio in ML[2b]). Il sito è, IMHO, carino ma usano una mappa Google[3] quindi gli ho proposto (mandandogli anche il codice)[4] di sostituire la Google mappa con una mappa OSM (fatta con leaflet Cloudmade). Nella risposta che mi ha dato il Presidente del BGLUG[5] mi chiedeva se c'era modo di avere anche la visualizzazione satellite ed i parcheggi. Per i parcheggi penso che questo[6] plugin di leaflet risolva il problema (anche se mi piacerebbe capire se cè un modo più semplice per dirgli fammi vedere tutti i parcheggi) mentre per le immagini da satellite mi pare di aver trovato che solo Mapquest le fornisce (cosa che significherebbe rifare la mappa, cioè non usare più leaflet), ma per Bergamo[7] non ci sono immagini da satellite disponibili ai livelli di zoom maggiori. Quindi: * conoscete qual è il modo più semplice per mostrare su una mappa (possibilmente leaflet) tutti i parcheggi? * esistono servizi che forniscono anche le immagini da satellite? Grazie, C [1] http://bglug.it/ [2a] http://bglug.herokuapp.com/ld/2013 [2b] http://lists.linux.it/pipermail/bglug/2013-September/027587.html [3] http://bglug.herokuapp.com/ld/2013/about [4] http://lists.linux.it/pipermail/bglug/2013-September/027610.html [5] http://lists.linux.it/pipermail/bglug/2013-September/027612.html [6] https://github.com/yohanboniface/Leaflet.RevealOSM [7] http://mapq.st/1erTvyJ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Relazioni tra multipolygon
Ciao a tutti, ho una domanda un po' complessa da porre, visto che si tratta di geometrie. Forse è più facile facendo un esempio: io ho una scuola la mappare, creo il rettangolo dei confini attorno ai quali si trovano l'edificio, palestra, campi, prati, parcheggi, anche un boschetto, ecc. Avendo diversi tipi di uso del suolo, decido di usare i multipolygon. Il confine sarà un poligono con type=multipolygon, amenity=school, name=Scuola X. Ora campizzo un prato, siccome è completamente interno gli darò la relazione inner per la scuola e outer per il prato. Ora invece ho un boschetto che si trova proprio su un confine dell'area della scuola. La mia domanda è: i lati in comune tra la scuola e il bosco non posso essere contemporaneamente inner e outer per la stessa relazione, come li tratto? Ho individuato due soluzioni: 1- il boschetto viene escluso dal poligono scuola che gira attorno al boschetto, ma non mi piace perchè il bosco è dentro i confini della scuola; 2- al tutto boschetto non viene data la relazione inner, quindi i lati in comune sono sia bosco che scuola, ma così risultano poligoni sovrapposti. Qual è la soluzione corretta? ce n'è una terza? Grazie mille J ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Embed di una mappa OSM con immagini sa satellite/aeree
Il giorno 19 settembre 2013 15:27, Cristian Consonni kikkocrist...@gmail.com ha scritto: Ciao a tutti, il LUG di Bergamo (BGLUG)[1], ha creato questo minisito per il Linux Day[2a] (a Bergamo, appunto), (qui l'annuncio in ML[2b]). Il sito è, IMHO, carino ma usano una mappa Google[3] quindi gli ho proposto (mandandogli anche il codice)[4] di sostituire la Google mappa con una mappa OSM (fatta con leaflet Cloudmade). Conoscono http://lugmap.it/ ? (che tra l'altro rifarei con Leaflet..) Nella risposta che mi ha dato il Presidente del BGLUG[5] mi chiedeva se c'era modo di avere anche la visualizzazione satellite ed i parcheggi. Per i parcheggi penso che questo[6] plugin di leaflet risolva il problema (anche se mi piacerebbe capire se cè un modo più semplice per dirgli fammi vedere tutti i parcheggi) mentre per le immagini da satellite mi pare di aver trovato che solo Mapquest le fornisce (cosa che significherebbe rifare la mappa, cioè non usare più leaflet), ma per Bergamo[7] non ci sono immagini da satellite disponibili ai livelli di zoom maggiori. Quindi: * conoscete qual è il modo più semplice per mostrare su una mappa (possibilmente leaflet) tutti i parcheggi? Fare una estrazione con overpass-api e mostrare il layer geojson? http://leafletjs.com/examples/geojson.html * esistono servizi che forniscono anche le immagini da satellite? https://github.com/shramov/leaflet-plugins registrare una api key di bing oppure affidarsi a mapbox con l'account base. http://www.mapbox.com/blog/leaflet-plugins-with-mapbox-js/ Grazie, C [1] http://bglug.it/ [2a] http://bglug.herokuapp.com/ld/2013 [2b] http://lists.linux.it/pipermail/bglug/2013-September/027587.html [3] http://bglug.herokuapp.com/ld/2013/about [4] http://lists.linux.it/pipermail/bglug/2013-September/027610.html [5] http://lists.linux.it/pipermail/bglug/2013-September/027612.html [6] https://github.com/yohanboniface/Leaflet.RevealOSM [7] http://mapq.st/1erTvyJ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Relazioni tra multipolygon
2013/9/19 Giovanni Caudullo giovanni.caudu...@gmail.com Forse è più facile facendo un esempio: io ho una scuola la mappare, creo il rettangolo dei confini attorno ai quali si trovano l'edificio, palestra, campi, prati, parcheggi, anche un boschetto, ecc. +1, o in altre parole: tutta l'area della scuola Avendo diversi tipi di uso del suolo, decido di usare i multipolygon. Il confine sarà un poligono con type=multipolygon, amenity=school, name=Scuola X. Ora campizzo un prato, siccome è completamente interno gli darò la relazione inner per la scuola e outer per il prato. no, non devi escluderlo dalla scuola. Se il prato fa parte dell'area della scuola lo puoi disegnare come un'area (o multipoligono) ma senza escluderlo dall'oggetto scuola Ora invece ho un boschetto che si trova proprio su un confine dell'area della scuola. La mia domanda è: i lati in comune tra la scuola e il bosco non posso essere contemporaneamente inner e outer per la stessa relazione, come li tratto? per il boschetto crei un'altra relazione multipoligono che non ha che fare con la scuola. La relazione ti serve soltanto per non sovraporre due ways ma invece puoi riutilizzare l'unico way, una volta per la scuola, una volta per il boschetto. Non devi escludere niente. Ho individuato due soluzioni: 1- il boschetto viene escluso dal poligono scuola che gira attorno al boschetto, ma non mi piace perchè il bosco è dentro i confini della scuola; -1 2- al tutto boschetto non viene data la relazione inner, quindi i lati in comune sono sia bosco che scuola, ma così risultano poligoni sovrapposti. +1, non c'è problema, sono due cose distinte (scuola, bosco) che si possono benissimo sovraporre. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Embed di una mappa OSM con immagini sa satellite/aeree
Il 19 settembre 2013 15:43, sabas88 saba...@gmail.com ha scritto: Conoscono http://lugmap.it/ ? (che tra l'altro rifarei con Leaflet..) Direi di sì, dato che la linkano appena sopra la mappa di Google in http://bglug.herokuapp.com/ld/2013/about Quindi: * conoscete qual è il modo più semplice per mostrare su una mappa (possibilmente leaflet) tutti i parcheggi? Fare una estrazione con overpass-api e mostrare il layer geojson? http://leafletjs.com/examples/geojson.html * esistono servizi che forniscono anche le immagini da satellite? https://github.com/shramov/leaflet-plugins registrare una api key di bing oppure affidarsi a mapbox con l'account base. http://www.mapbox.com/blog/leaflet-plugins-with-mapbox-js/ Chiaro, veloce e puntuale! Grazie. C ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Relazioni tra multipolygon
Chiaro. Grazie mille : ) Ciao G Il giorno 19 settembre 2013 15:58, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2013/9/19 Giovanni Caudullo giovanni.caudu...@gmail.com Forse è più facile facendo un esempio: io ho una scuola la mappare, creo il rettangolo dei confini attorno ai quali si trovano l'edificio, palestra, campi, prati, parcheggi, anche un boschetto, ecc. +1, o in altre parole: tutta l'area della scuola Avendo diversi tipi di uso del suolo, decido di usare i multipolygon. Il confine sarà un poligono con type=multipolygon, amenity=school, name=Scuola X. Ora campizzo un prato, siccome è completamente interno gli darò la relazione inner per la scuola e outer per il prato. no, non devi escluderlo dalla scuola. Se il prato fa parte dell'area della scuola lo puoi disegnare come un'area (o multipoligono) ma senza escluderlo dall'oggetto scuola Ora invece ho un boschetto che si trova proprio su un confine dell'area della scuola. La mia domanda è: i lati in comune tra la scuola e il bosco non posso essere contemporaneamente inner e outer per la stessa relazione, come li tratto? per il boschetto crei un'altra relazione multipoligono che non ha che fare con la scuola. La relazione ti serve soltanto per non sovraporre due ways ma invece puoi riutilizzare l'unico way, una volta per la scuola, una volta per il boschetto. Non devi escludere niente. Ho individuato due soluzioni: 1- il boschetto viene escluso dal poligono scuola che gira attorno al boschetto, ma non mi piace perchè il bosco è dentro i confini della scuola; -1 2- al tutto boschetto non viene data la relazione inner, quindi i lati in comune sono sia bosco che scuola, ma così risultano poligoni sovrapposti. +1, non c'è problema, sono due cose distinte (scuola, bosco) che si possono benissimo sovraporre. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pesa pubblica
Ne ho taggate alcune così amenity=weightbridge http://www.openstreetmap.org/browse/way/227459527 Il giorno 19 settembre 2013 18:17, bredy bredy...@yahoo.it ha scritto: Come si può taggare una pesa pubblica. Non credo ce ne siano molte ancora. -- View this message in context: http://gis.19327.n5.nabble.com/Pesa-pubblica-tp5778169.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Pesa pubblica
Come si può taggare una pesa pubblica. Non credo ce ne siano molte ancora. -- View this message in context: http://gis.19327.n5.nabble.com/Pesa-pubblica-tp5778169.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tool di qa per classificazione strade
2013/9/19 Aury88 spacedrive...@gmail.com: bisogna vedere dopo quanto tempo le correzioni vengono notate da questo tool...mi sembra che dopo una decina di giorni dalle mie correzioni gli errori siano ancora tutti indicati e come tempo, specialmente per un tool di controllo qualità, mi sembra esagerato :( confermo. avevo corretto intere categorie di errori, e me le segnala ancora come presenti. btw ho scritto mail all'autore per chiedere info. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Correggere traccia GPS
Giusto per informare, credo di aver capito il tracciato. Trattasi di ciclovia in progetto: http://www.municipio.re.it/retecivica/urp/pes.nsf/web/Bccltt4?opendocument lo chiamano Percorsi ciclabili verdi (Greenway) vedrò allora di verificare la corrispondenza, a prima vista è tutto corretto. solo mappata in maniera non ottimale. saluti -alex- -- View this message in context: http://gis.19327.n5.nabble.com/Correggere-traccia-GPS-tp5778037p5778189.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tool di qa per classificazione strade
Gli aggiornamenti, si trovano in alto nella pagina di dettaglio delle varie regioni, per quel che riguarda l'Emilia sono questi: Map CodeIT-45e Map NameItaly, Emilia-Romagna (pt 1) Date of Validation 2013-09-07 18:27:31 Last known edit 2013-09-03 10:45:58 (UTC) -- View this message in context: http://gis.19327.n5.nabble.com/Tool-di-qa-per-classificazione-strade-tp5776206p5778193.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag www.prezzibenzina.it
2013/9/18 sabas88 saba...@gmail.com: Nel frattempo io faccio il figo https://twitter.com/OpenStreetMapIt/status/380327751267270656 Chi fa la persona seria e scrive a osservapre...@mise.gov.it ? ho scritto adesso adesso... -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: non trovo piu di un comune su OSMAND neanche con la mappe aggiornate
On 09/16/2013 08:25 PM, beppebo...@libero.it wrote: Ho caricato ora la nuova mappa Italy e si trova...prova a riscaricare la mappa ciao Probabilmente il file del Lazio non è aggiornato ho aggiornato la mappa italy e lazio-italy versioni del 11/09/13 e 13/09/13, ma mancano almeno i comuni di Castelforte Santi Cosma e Damiano Minturno, come posso aggiornare le mappe?? dove posso trovare il database e aggiornarlo??? ciao grazie pier. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ar] II Congreso y Jornadas TI Geo y SIG
Malena: http://www.tig2013.episnet.net/, Buenisimo el sitio, y muy completa la seccion Ponencias. Critica constructuva: hagan un recorte de textos ya que la excesiva extension del resumen desvirtua su caracter resumido ;) Por lo demas me resulto muy interesante, con mi entusiasmo fui a pedir los dias a mi jefe y me los nego, asi que no podre ir :( De paso: Edite la zona donde esta la UNGS, incluso puse los Institutos que la componen. Asi, el mapa de ubicacion resulta orientador... Muchos exitos con el evento! Saludos. Sefer. De: Malena Libman malena.lib...@gmail.com Para: talk-ar@openstreetmap.org Enviado: Jueves, 19 de septiembre, 2013 9:09 A.M. Asunto: Re: [Talk-ar]Resumen de Talk-ar, Vol 51, Envío 9 Hola Sefer, Yo estudio en la Universidad que organiza el evento, mas específicamente la carrera que lo organiza que es la Tecnicatura en SIG. La verdad es que me parece que va a ser muy interesante el evento (y no solo porque yo presento trabajos). En la página http://www.tig2013.episnet.net/, podés ver los trabajos que se van a estar presentando para ver si es que te interesan. Yo voy! Alguien más? Creo que de la lista de Geoinquietos algunos iban Saludos Male ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-at] OGD Vorarlberg?
Ich habe letztes Jahr bei der VoGIS angefragt, gerade weil die Nutzungsbedingungen so schwammig sind. Der Herr Kanonier hat mich dann gleich telefonisch kontaktiert und mir gesagt, dass sie sehr interessiert an einer Zusammenarbeit wären. Im Wiki stehen dazu noch 1-2 Dinge drinnen. http://wiki.openstreetmap.org/wiki/WikiProject_Austria/vogis Ein Stammtisch in Vorarlberg bezüglich diesem Thema wäre ohnehin schon lange ausständig, ich konnte das aber leider wegen Zeitmangel letztes Jahr nicht wirklich weiterverfolgen. Am 18. September 2013 16:45 schrieb Andreas Labres l...@lab.at: Hallo Markus! Die offenen Daten des Landes Vorarlberg findest Du hier: http://data.vorarlberg.gv.at/ Diese Daten sind CC BY 3.0 AT veröffentlicht. Was mit den vogis-DL-Daten ist, kann ich nicht sagen. Ich verstehe ehrlich gesagt nicht, was die Nutzungsbedingungen http://vogis.cnv.at/nutzungsbestimmungen/nutzung.pdf erlauben und was nicht. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at -- Lukas Bischof p: +43 (664) 416 84 34 w: http://www.wordy-rappinghood.net/ @: lukas.bisc...@gmail.com ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes les façons pas de répondre à la question quelles communes appartiennent à la CUB, ou au Grand Lyon ? ou encore, extrayez-moi les limites des communes du département 73 ? Je crois voir que c'est parce que ce type de relation n'est tout simplement pas dans la base : ainsi, la relation CUB ( http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de lien avec la relation Bordeaux ( http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est spatialement, mais c'est plus fragile comme relation)... Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? Fionn Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query union item/ recurse type=down/ /union print/ /osm-script Voire le contours pour chacune des communautés urbaines en France : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=local_authority:FR v=CU/ /query union item/ recurse type=down/ /union print/ /osm-script Mais je n'arrive pas vraiment à avoir la liste exacte des communes appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez. Des idées ? Merci, Fionn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. J'ai moi même aussi essayé l'exercice et j'en suis arrive à la même conclusion. Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes les façons pas de répondre à la question quelles communes appartiennent à la CUB, ou au Grand Lyon ? ou encore, extrayez-moi les limites des communes du département 73 ? Je crois voir que c'est parce que ce type de relation n'est tout simplement pas dans la base : ainsi, la relation CUB ( http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de lien avec la relation Bordeaux ( http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est spatialement, mais c'est plus fragile comme relation)... Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? C'est un grand sujet de discutions qui oppose les spatialises (pas besoin de faire plus on peut le retrouver l’information par requête spatiale) et aux relationniste (on ajoute de la sécurité et de la sémantique avec des relations (ma vision perso)). Le modèle de zone administrative en France est construit sur des relations type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la même façon de faire : ces relations regroupent la limite extérieurs. Par contre en Espagne le principe est le même, mais il y en plus l'aspect surfacique dans les relation, c'est à dire que les relations des entités administratives filles sont également présente dans la relation. Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query union item/ recurse type=down/ /union print/ /osm-script Voire le contours pour chacune des communautés urbaines en France : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=local_authority:FR v=CU/ /query union item/ recurse type=down/ /union print/ /osm-script Mais je n'arrive pas vraiment à avoir la liste exacte des communes appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez. Des idées ? Merci, Fionn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes les façons pas de répondre à la question quelles communes appartiennent à la CUB, ou au Grand Lyon ? ou encore, extrayez-moi les limites des communes du département 73 ? Je crois voir que c'est parce que ce type de relation n'est tout simplement pas dans la base : ainsi, la relation CUB ( http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de lien avec la relation Bordeaux ( http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est spatialement, mais c'est plus fragile comme relation)... Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? Fionn Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Bonjour, Une idée : 1. Utiliser la référence de la relation englobant l'intercommunalité dans l'outil de génération de polygones simplifiés de Jocelyn : http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py (l'url polygon.openstreetmap.fr ne fonctionne pas) 2. Faire une requête Overpass API pour récupérer les *noeuds* place correspondant aux communes incluses dans ce polygone http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Select_Region_by_Polygon Il y a quelques mois j'avais fait l'exercice [*] de récupérer les limites de communes d'une intercommunalité, mais il fallait au préalable établir la liste des codes INSEE des communes qui la composaient. Cela ne colle donc pas à ton besoin, à moins que la méthode plus haut soit le bon préalable. Bonne journée [*] https://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038283.html Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes les façons pas de répondre à la question quelles communes appartiennent à la CUB, ou au Grand Lyon ? ou encore, extrayez-moi les limites des communes du département 73 ? Je crois voir que c'est parce que ce type de relation n'est tout simplement pas dans la base : ainsi, la relation CUB ( http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de lien avec la relation Bordeaux ( http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est spatialement, mais c'est plus fragile comme relation)... Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? Fionn Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query union item/ recurse type=down/ /union print/ /osm-script Voire le contours pour chacune des communautés urbaines en France : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=local_authority:FR v=CU/ /query union item/ recurse type=down/ /union print/ /osm-script Mais je n'arrive pas vraiment à avoir la liste exacte des communes appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez. Des idées ? Merci, Fionn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Le service d’aide à l’intégration des données adresses OpenData est à nouveau disponible. Malheureusement la base de données précédemment utilisé sur feu osm7 n’était pas sauvegardé. On a donc perdu le statuts des imports, heureusement il n’y en avait pas beaucoup (sauf sur une des villes). Si besoin on peut reconstruire ces statuts depuis les données OSM (si quelqu’un le demande, ou encore mieux en donne la liste). Il y surement d’autres villes qui ont mise à disposition leur données adresses depuis. Si vous en connaissait vous pouvez le signaler. http://addr.openstreetmap.fr/ Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Les recherches area-query dans une relation ou à l'intérieur d'un polygone ne marchent que pour les noeuds. C'est une limitation de l'outil Overpass API Le 19 septembre 2013 11:13, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. J'ai moi même aussi essayé l'exercice et j'en suis arrive à la même conclusion. C'est un grand sujet de discutions qui oppose les spatialises (pas besoin de faire plus on peut le retrouver l’information par requête spatiale) et aux relationniste (on ajoute de la sécurité et de la sémantique avec des relations (ma vision perso)). Le modèle de zone administrative en France est construit sur des relations type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la même façon de faire : ces relations regroupent la limite extérieurs. Par contre en Espagne le principe est le même, mais il y en plus l'aspect surfacique dans les relation, c'est à dire que les relations des entités administratives filles sont également présente dans la relation. Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query union item/ recurse type=down/ /union print/ /osm-script Voire le contours pour chacune des communautés urbaines en France : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=local_authority:FR v=CU/ /query union item/ recurse type=down/ /union print/ /osm-script Mais je n'arrive pas vraiment à avoir la liste exacte des communes appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez. Des idées ? Merci, Fionn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand succès : si j'en crois une discussion vue depuis, les area-query=* ne fonctionnent pas parce que les boundary=local_authority ( https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html) ne sont pas reconnus par Overpass. Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes les façons pas de répondre à la question quelles communes appartiennent à la CUB, ou au Grand Lyon ? ou encore, extrayez-moi les limites des communes du département 73 ? Je crois voir que c'est parce que ce type de relation n'est tout simplement pas dans la base : ainsi, la relation CUB ( http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de lien avec la relation Bordeaux ( http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est spatialement, mais c'est plus fragile comme relation)... Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? Fionn Le 13 septembre 2013 19:07, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : Bonsoir, Je me suis un peu cassé les dents sur cette question sans doute assez bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB), ainsi que les zones correspondantes. J'arrive à obtenir le contour de la CUB : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=name v=Communauté urbaine de Bordeaux/ /query union item/ recurse type=down/ /union print/ /osm-script Voire le contours pour chacune des communautés urbaines en France : osm-script query type=relation has-kv k=type v=boundary/ has-kv k=boundary v=local_authority/ has-kv k=local_authority:FR v=CU/ /query union item/ recurse type=down/ /union print/ /osm-script Mais je n'arrive pas vraiment à avoir la liste exacte des communes appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez. Des idées ? Merci, Fionn
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Le 19 septembre 2013 11:19, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le service d’aide à l’intégration des données adresses OpenData est à nouveau disponible. http://addr.openstreetmap.fr/ Frédéric. Super, merci ! Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Le 19 septembre 2013 11:19, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Il y surement d’autres villes qui ont mise à disposition leur données adresses depuis. Si vous en connaissait vous pouvez le signaler. Oui j'avais déjà signalé le Grand Nancy: http://opendata.grand-nancy.org Merci pour l'ajout. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Le rendu carto a quelques problèmes de bloquage dans son javascript (avec un comportement étrange du zoom, et une suraccélération de la souris). Les tuiles ne se raffraichissent pas correctement, leur position ne correspond pas au glissement du curseur. On dirait un paramètre incorrect pour ajuster les zooms dans l'intégration javascript, ou bien un type de projection incorrect. Le 19 septembre 2013 11:42, Romain MEHUT romain.me...@gmail.com a écrit : Le 19 septembre 2013 11:19, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Il y surement d’autres villes qui ont mise à disposition leur données adresses depuis. Si vous en connaissait vous pouvez le signaler. Oui j'avais déjà signalé le Grand Nancy: http://opendata.grand-nancy.org Merci pour l'ajout. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Le 19 septembre 2013 11:49, Philippe Verdy verd...@wanadoo.fr a écrit : Le rendu carto a quelques problèmes de bloquage dans son javascript (avec un comportement étrange du zoom, et une suraccélération de la souris). Les tuiles ne se raffraichissent pas correctement, leur position ne correspond pas au glissement du curseur. On dirait un paramètre incorrect pour ajuster les zooms dans l'intégration javascript, ou bien un type de projection incorrect. Toute cette m* de javascript est mon chef-d’œuvre de grand débutant JS, et comme telle restera inachevé (par moi) si aucun bug bloquant n'est remonté.Traduction: Ca juste marche ! Plus sérieusement, c'est où le pb, quelle ville ? Pas la peine d'envoyer un permalink, çà marche pas ;-) Sinon, Philippe, si tu passes par Nantes ou Pornic, contactes-moi. On discutera calmement OSM, et on verra si tu es aussi endurant au clavier que derrière une chopine. A+ BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Amis spatialistes et relationistes bonjour :-) Le 19/09/2013 11:13, Frédéric Rodrigo a écrit : Le 19 septembre 2013 11:01, Fionn Halleman fionn.halle...@valeurs-mobiles.fr mailto:fionn.halle...@valeurs-mobiles.fr a écrit : Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? C'est un grand sujet de discutions qui oppose les spatialises (pas besoin de faire plus on peut le retrouver l’information par requête spatiale) et aux relationniste (on ajoute de la sécurité et de la sémantique avec des relations (ma vision perso)). Le modèle de zone administrative en France est construit sur des relations type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la même façon de faire : ces relations regroupent la limite extérieurs. Par contre en Espagne le principe est le même, mais il y en plus l'aspect surfacique dans les relation, c'est à dire que les relations des entités administratives filles sont également présente dans la relation. Il y a surtout, jusque là, quelques arguments pour utiliser le modèle par limites, arguments bêtement pragmatiques : - ce modèle, contrairement au surfacique, permet de définir un niveau sans disposer de l'intégralité des surfaces à un niveau plus fin. Avec le modèle par surface, encore aujourd'hui, on ne saurait pas tracer certains départements français, qui seraient troués ou rognés sur les bords. Concrètement, voilà à quoi ressemblerait le département des Ardennes en mode surfacique (ne regarder que ce qui est en vert) : http://layers.openstreetmap.fr/?zoom=9lat=49.6lon=4.8layers=000B0FFTFT Ce constat reste encore valable pour quelques mois, tant qu'on n'aura pas terminé le tracé complet des limites de communes. - pour la modélisation par surface, il faudrait, côté exploitation des données, des moyens de digérer les relations récursives. On doit bien pouvoir trouver quelques bouts de code là-dessus, mais autant que je sache ça n'est pas disponible dans les outils de manipulation de données OSM brutes les plus populaires, notamment osm2pgsql. A contrario, la modélisation par surface, en référençant dans une relation ses relations filles, offre une manière puissante de naviguer dans l’arborescence des zones. Il y a des bénéfices à en tirer, j'imagine tout à fait qu'on modélise ça un jour prochain. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
2013/9/19 Bruno Cortial bruno.cort...@laposte.net: on verra si tu es aussi endurant au clavier que derrière une chopine. et inversement Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
2013/9/19 Vincent de Château-Thierry v...@laposte.net: Ce constat reste encore valable pour quelques mois, tant qu'on n'aura pas terminé le tracé complet des limites de communes. Si ça, ça ressemble pas à un appel à terminer les limites communales, je me fais moine ^^ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plugin cadastre-fr, version 29829 (2.5)
Hello, Me retrouvant à manger du mapcraft de la dordogne, je me retrouve avec un paquet de communes dont les planches sont sans croisillons. J'ai plusieurs fois rencontré le cas de ces planches sans repères, mais qui étaient géoréférencées. La version actuelle du plugin ne pouvant récupérer ce géoréférencement, je me demandais s'il y avait tout de même un moyen de le savoir. Auquel cas, je mettrais ces planches de côté en attendant une nouvelle version. Sinon, un petit bug peut-être déjà remonté : - Récupérer une planche, par exemple le TA d'une commune. - Demander le TA d'une autre commune en tapant n'importe quoi comme nom (qsdfvgzs). Le plugin ne trouve rien et. le TA de la commune précédemment chargé disparait. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plugin cadastre-fr, version 29829 (2.5)
De : Stéphane Péneau Me retrouvant à manger du mapcraft de la dordogne, je me retrouve avec un paquet de communes dont les planches sont sans croisillons. J'ai plusieurs fois rencontré le cas de ces planches sans repères, mais qui étaient géoréférencées. La version actuelle du plugin ne pouvant récupérer ce géoréférencement, je me demandais s'il y avait tout de même un moyen de le savoir. Auquel cas, je mettrais ces planches de côté en attendant une nouvelle version. Si un géoréférencement existe, il sera visible sur le site du cadastre. En cherchant la commune qui t'intéresse ici : http://www.cadastre.gouv.fr/ puis en affichant une de ses planches, s'il y a géoréférencement, il apparaît en bas de la fenêtre à la ligne Coordonnées en projection. Si tu vois comme intitulé métrique locale ça veut dire... qu'il n'y a rien à attendre comme aide, la planche n'est pas géoréférencée. Mais si tu vois Lambert xxx ou RGF93CCxxx là c'est bon signe. 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
De : Pieren 2013/9/19 Vincent de Château-Thierry : Ce constat reste encore valable pour quelques mois, tant qu'on n'aura pas terminé le tracé complet des limites de communes. Si ça, ça ressemble pas à un appel à terminer les limites communales, je me fais moine ^^ ça s'est vu tant que ça ? ;-))) 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
osm2pgsql ne fiche de la hiérarchie logique qu'il peut y avoir entre les différents objets OSM. Son objectif est de créer les géométries (point, lignes, polygones) correspond aux objets OSM (noeuds, chemins, relations). Bien sûr, si l'on ne définissait les limites administratives que par un modèle surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas mal d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi radical. Le double modèle par contre peut avoir du sens. Il est en effet relativement difficile aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces géométries. Je viens d'extraire par exemple des listes de lieux (communes) sur différents pays avec la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base osm2pgsql pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très mal renseigné et d'un format très aléatoire car textuel et non véritable structuré. J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir ajouter les subarea en rôle supplémentaires dans les relations de découpages administratifs. Les outils ne sachant pas les exploiter les ignoreront tout simple comme il le font jusqu'à maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun problème. * voir ici: http://osm13.openstreetmap.fr/~cquest/places/ Le 19 septembre 2013 12:32, Vincent de Château-Thierry v...@laposte.net a écrit : Amis spatialistes et relationistes bonjour :-) Le 19/09/2013 11:13, Frédéric Rodrigo a écrit : Le 19 septembre 2013 11:01, Fionn Halleman fionn.halleman@valeurs-**mobiles.fr fionn.halle...@valeurs-mobiles.fr mailto:fionn.halleman@**valeurs-mobiles.frfionn.halle...@valeurs-mobiles.fr a écrit : Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ? C'est un grand sujet de discutions qui oppose les spatialises (pas besoin de faire plus on peut le retrouver l’information par requête spatiale) et aux relationniste (on ajoute de la sécurité et de la sémantique avec des relations (ma vision perso)). Le modèle de zone administrative en France est construit sur des relations type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la même façon de faire : ces relations regroupent la limite extérieurs. Par contre en Espagne le principe est le même, mais il y en plus l'aspect surfacique dans les relation, c'est à dire que les relations des entités administratives filles sont également présente dans la relation. Il y a surtout, jusque là, quelques arguments pour utiliser le modèle par limites, arguments bêtement pragmatiques : - ce modèle, contrairement au surfacique, permet de définir un niveau sans disposer de l'intégralité des surfaces à un niveau plus fin. Avec le modèle par surface, encore aujourd'hui, on ne saurait pas tracer certains départements français, qui seraient troués ou rognés sur les bords. Concrètement, voilà à quoi ressemblerait le département des Ardennes en mode surfacique (ne regarder que ce qui est en vert) : http://layers.openstreetmap.**fr/?zoom=9lat=49.6lon=4.8** layers=000B0FFTFThttp://layers.openstreetmap.fr/?zoom=9lat=49.6lon=4.8layers=000B0FFTFT Ce constat reste encore valable pour quelques mois, tant qu'on n'aura pas terminé le tracé complet des limites de communes. - pour la modélisation par surface, il faudrait, côté exploitation des données, des moyens de digérer les relations récursives. On doit bien pouvoir trouver quelques bouts de code là-dessus, mais autant que je sache ça n'est pas disponible dans les outils de manipulation de données OSM brutes les plus populaires, notamment osm2pgsql. A contrario, la modélisation par surface, en référençant dans une relation ses relations filles, offre une manière puissante de naviguer dans l’arborescence des zones. Il y a des bénéfices à en tirer, j'imagine tout à fait qu'on modélise ça un jour prochain. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talk-frhttps://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
De : Christian Quest Bien sûr, si l'on ne définissait les limites administratives que par un modèle surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas mal d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi radical. Le double modèle par contre peut avoir du sens. Il est en effet relativement difficile aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces géométries. Je viens d'extraire par exemple des listes de lieux (communes) sur différents pays avec la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base osm2pgsql pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très mal renseigné et d'un format très aléatoire car textuel et non véritable structuré. J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir ajouter les subarea en rôle supplémentaires dans les relations de découpages administratifs. Les outils ne sachant pas les exploiter les ignoreront tout simple comme il le font jusqu'à maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun problème. Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est plus lisible, et surtout, le type de ces relations ne peut pas être boundary, ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : nested_areas ou quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas type=boundary : on ne parle pas de limites, ici. A creuser... vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Il ne faut pas prendre boundary au pied de la lettre... Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui va avec). En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ? Je préfère un seul objet OSM pour représenter une unique entité sur le terrain (la région machinchose, le département trucmuche). Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet représentant en même temps une surface et un linéaire ? ;) Le 19 septembre 2013 15:34, V de Chateau-Thierry v...@laposte.net a écrit : Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est plus lisible, et surtout, le type de ces relations ne peut pas être boundary, ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : nested_areas ou quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas type=boundary : on ne parle pas de limites, ici. A creuser... vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Le 19 septembre 2013 13:15, Pieren pier...@gmail.com a écrit : 2013/9/19 Vincent de Château-Thierry v...@laposte.net: Ce constat reste encore valable pour quelques mois, tant qu'on n'aura pas terminé le tracé complet des limites de communes. Si ça, ça ressemble pas à un appel à terminer les limites communales, je me fais moine ^^ Ilya surtour que l'argumentcité est totalement faux, je dis bien totalement car il s'agit de mauvaise foi manifeste car une énumération des composantes filles d'une surface peut avoir lieu ***même si*** on n'a pas encore tout tracé, et si on n'a pas la précision complète suffisante. L'énumération des filles demande très peu de données dans la base : 1 seul membre à ajouter par fille dans sa relation parente, donc en tout pour le niveau adminstratif des communes, autant que de communes (alors que pour les chemins membres des relation communales on monte facilement = une moyene de l'ordre de 6 à 12 de membres par commune, et en tout de l'ordre du quart de million de chemins membres pour les communes françaises., contre 36000 membres en tout pour les énumérations de communes filles membres du niveau admin supérieur..). Cela fait très longtemps que ces onnées auraient été terminées et de façon exhaustive et stable. De plus l'opposition n'est absolument pas entre représentation des frontières ou des surfaces car en fait en stockant des ways membres uniquement on réalise les deux simultanément, les chemins membres étant obligatoirement tous des anneaux fermés. Jamais il n'y a eu opposition entre partisan du modèle surfacique et celui du modèle par frontière car c'est exactement la même chose ici avec les mêmes données. La différence n'est pas du tout entre surface et par frontières, mais entre ces derniers (totalement équivalents entre eux) et la représentation parsous-ensembles (qui n'est pas une représentation relationnelle non plus, car un modèle relationnel, au sens SQL du terme, ne peut pas accepter les récursions d'un type d'objet vers lui-même : si on veut faire une requête relationnelle, le système imposerait de dénormaliser ces ensembles et sous-ensembles pour inclure dans le parent non seulement ses filles,mais aussi ses petites filles et tous les niveaux descendants, ce qui n'est absolument pas optimal ; ce type de requête nécessite un type de requête SQL particulier, certes ,mais pas plus particulier ni plus compliqué que les requêtes géométriques qui sont extrêmement fragiles et très compliquées et lourdes à réaliser car il faut comparer non seulemetn des listes de chemins membres très longues, mais aussi descendre jus'au niveau de leurs noeuds et aire des calculs de projection sur un axe à partir d'un point pour savori où se situe l'intérieur et l'extérieur et déterminer s'il y a untersection ou non; la requête ne permettant pas non plus de répondre quand une intersection existe mais n'est pas complète d'une surface dans l'autre, car il y a un peu partout des anomalies fréquentes avec des chemins oubliés oupas encore tracés non plus...). Je ne dis pas qu'on doit utiliser le modèle ensembliste (relations membres) à la place du modèle actuel surfaço-linéaire (utilisant des chemins membres, ou bientôt des anneaux membres fermés avec l'introduction attendue de la primitive 'surfacique qui enfait va être une primitive d'anneaux fermés), mais que les deux se complètent utilement et se renforcent mutuellement pour permettre d'alléger de très nombreuses analyses et exploitation des données. Le modèle ensembliste est en effet totalement indépendant de la précision géométrique, il nécessaite très peu de données, il est stable, documenté, facilement vérifiable et facile à garder stable et complet. De plus il renforce énormément le système surfaço-linéaire en évitant des tas d'accidents d'éditions (liés à l'oubli fréquent de télécharger TOUTES les relations utilisant chaque noeud ou chemin donné avant de le modifier). Il suffit de voir comment très souvent les relations sont cassées en France, et la difficulté constante pour les réparer (car cela demande de télécharger énormément de données pour retrouver tous les chemins nécessaires) ! En comparaison si on a une liste e filles dans la relation parente, la réparation est évidente et ne nécessite pas de longues recherches et très peu de données demandées au serveur. Tout est plus efficace. pour naviguer dans les données. Regardez avec quelle faciliité déconcertante on navigue en Espagne ou en Belgique et comment ces pays sont TRES stables dans la base, le moindre accident étant très vite réparé et facile à vérifier... Et même si on ne télécharge JAMAIS les remations parentes, c'est le système qui s'en charge AUTOMATIQUEMENT partout (ce qui n'est pas le cas avec le modèle surfaço-linéaire) : les oublis n'ont plsu aucune excuse car cela ne peut provenir que 'd'une suppression volontaire de données et non d'un accident lié à la fusion ou la scission d'un chemin.en plusieurs. Je voudrais donc qu'on arrêt d'opposer les
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
2013/9/19 Christian Quest cqu...@openstreetmap.fr: J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. Non (snip) Il faut écouter les vieux routiers des bdd : la redondance ne détecte pas les incohérences, elle les créer ! Encore plus dans un projet comme OSM où chaque entité peut être modifiée séparément et sans contrôle. Les relations boundary sont déjà très difficiles à maintenir. Vous allez doubler le travail sur 36000 communes, 100 départements et 22 régions, doublez le nombre de relations (ou leur taille); tout ça pour éviter que quelques personnes remplissent une base spatiale avec osm2pgsql... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Pus lisible deu modèles dans des relations séparées ? Pas du tout ! Et cela complique tout en fait en ne sachant plus quelle relation utiliser, on va dénormaliser ennore plus les attributs. Regarde effectivement l'Espagne ou la Belgique et prétend que ce n'est pas lisible ! Et pourtant cela demande peu de membres dans les relations, qu sont classés à part avec des rôles clairement séparés qui ne gênent en rien la lisibilité des lites de chemins membres (qui elles sont carrément bordéliques, et le mot est faible, et totalement illisibles sans outils pour vérifier qu'on n'a pas pris par erreur un morceau de commune voisine ni oublié une petite enclave ou une ile exclavée qui fait échouer toute requête purement géométrique...). Le 19 septembre 2013 15:34, V de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest Bien sûr, si l'on ne définissait les limites administratives que par un modèle surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas mal d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi radical. Le double modèle par contre peut avoir du sens. Il est en effet relativement difficile aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces géométries. Je viens d'extraire par exemple des listes de lieux (communes) sur différents pays avec la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base osm2pgsql pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très mal renseigné et d'un format très aléatoire car textuel et non véritable structuré. J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir ajouter les subarea en rôle supplémentaires dans les relations de découpages administratifs. Les outils ne sachant pas les exploiter les ignoreront tout simple comme il le font jusqu'à maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun problème. Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est plus lisible, et surtout, le type de ces relations ne peut pas être boundary, ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : nested_areas ou quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas type=boundary : on ne parle pas de limites, ici. A creuser... vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html 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 https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Des nouvelles de X-Plane
Vu sur le forum de la communauté française. http://www.x-plane.fr/thread52179.html Les données OpenStreetMap vont de nouveau être intégrées aux scènes du simulateur de vol X-Plane. Avec une date butoir qui approche. Les utilisateurs de la simulation ont donc tout intérêt à améliorer l'existant, et c'est l'objet du fil de discussion Un bel exemple de bénéfice partagé entre les deux communautés Bonne journée -- 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Mon avis est que les relations apportent un aspect plus sémantique à la structure des données. De plus OSM est par essence en construction. Les limites peuvent être ouvertes ou incomplètes. Les relations offrent donc un autre point d'entré. Même si la redondance crée des problèmes, elle consolide l'ensemble. Par exemple les relations sur les cours d'eau (aux qu'elles j'ai activement participé) permettent de suivre les cours d'eau même s'il sont incomplet ou changent de nom en cours de route. Le 19 septembre 2013 15:54, Pieren pier...@gmail.com a écrit : 2013/9/19 Christian Quest cqu...@openstreetmap.fr: J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. Non (snip) Il faut écouter les vieux routiers des bdd : la redondance ne détecte pas les incohérences, elle les créer ! Encore plus dans un projet comme OSM où chaque entité peut être modifiée séparément et sans contrôle. Les relations boundary sont déjà très difficiles à maintenir. Vous allez doubler le travail sur 36000 communes, 100 départements et 22 régions, doublez le nombre de relations (ou leur taille); tout ça pour éviter que quelques personnes remplissent une base spatiale avec osm2pgsql... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
2013/9/19 Pieren pier...@gmail.com: Et si on va dans la consolidation, on peut aussi rétablir tous les is_in qui ont été injustement supprimés. Et mettre des addr:country=France sur toutes les adresses en France. Parce qu'il y aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et pis, ça consolide et on pourra mieux détecter les incohérences. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osrm ferroviaire ?
Oui Christian tu as raison : entre les traversée jonction simple, les doubles, les bifurcations droite, gauche, les voies uniques, les voies à sens unique, les voies à double sens, etc. Tous ceci est hors de portée du contributeur moyen (simplement parce que c’est indétectable sur une simple ortho fusse-t-elle celle de Nancy ;-). En fait, le nœud du problème est de convertir la base OSM actuelle en graphe gare-tronçon ferré à l’échelle européenne. A noter que je me fous des lignes commerciales (pour le calcul d’itinéraire tout au moins). De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : jeudi 19 septembre 2013 17:15 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] osrm ferroviaire ? Il y a des choses qu'il faudra sûrement traiter en plus qu'un simple rail.lua Les voies ferrées sont tracées mais les aiguillages sont rarement renseignés, or lorsque 2 voies se croisent il n'y a pas forcément d'aiguillage, ça peut être un simple croisement. Les trains ne peuvent pas non plus faire des virages n'importe comment même si les way sont connectés... un beau casse tête en perspective où il faudrait déterminer le graphe aussi en se basant sur la géométrie des intersections... Le 19 septembre 2013 17:06, Ab_fab gamma@gmail.commailto:gamma@gmail.com a écrit : Est-ce que cela peut se résumer à la bidouille d'un nouveau profil rail.lua ? https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles Ca a l'air d'être la conclusion de la discussion ici : https://github.com/DennisOSRM/Project-OSRM/issues/90 Le 19 septembre 2013 16:56, HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr a écrit : Bonjour à tous, Je suis confronté à un problème pour l’heure insoluble. Je cherche à calculer la distance d’itinéraires entre deux gares ferroviaires quelconques au niveau européen. Pas de problème pour le routier, tout le monde sait faire. Pas de problème non plus pour le temps de trajet ferroviaire entre une origine et une destination, mais point de kilométrage. Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes (pas de LGV, par exemple) soit partielle (ou les deux). Des pistes sur des ressources existantes que j’aurai manqué ? La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) : quel serait la méthode et le cout (technique/financier) pour adapter osrm à du routing ferroviaire. J’ai déjà lu ceci : https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines A vot’bon coeur Denis HELFER Chargé d’études géomatiques Correspondant SI 03 88 23 95 58 [Description : Description : D:\Documents and Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG] ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fabhttp://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ inline: image001.jpg___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osrm ferroviaire ?
Est-ce que cela peut se résumer à la bidouille d'un nouveau profil rail.lua ? https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles Ca a l'air d'être la conclusion de la discussion ici : https://github.com/DennisOSRM/Project-OSRM/issues/90 Le 19 septembre 2013 16:56, HELFER Denis denis.hel...@rff.fr a écrit : Bonjour à tous, ** ** Je suis confronté à un problème pour l’heure insoluble. Je cherche à calculer la distance d’itinéraires entre deux gares ferroviaires quelconques au niveau européen. Pas de problème pour le routier, tout le monde sait faire. Pas de problème non plus pour le temps de trajet ferroviaire entre une origine et une destination, mais point de kilométrage. Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes (pas de LGV, par exemple) soit partielle (ou les deux). Des pistes sur des ressources existantes que j’aurai manqué ? La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) : quel serait la méthode et le cout (technique/financier) pour adapter osrm à du routing ferroviaire. J’ai déjà lu ceci : https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines ** ** A vot’bon coeur ** ** ** ** *Denis HELFER* *Chargé d’études géomatiques* *Correspondant SI* *03 88 23 95 58 * [image: Description : Description : D:\Documents and Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG]*** * ** ** ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://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 image001.jpg___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
De : Christian Quest Il ne faut pas prendre boundary au pied de la lettre... Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme n'est pas choisi au hasard, non ? Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui va avec). La recopie de tags, c'est 3 clic dans JOSM 1er : 3e bouton en partant de la gauche dans le panneau des relations = ouvre une nouvelle relation copiée sur celle sélectionnée initialement 2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation pour sélectionner tous les membres 3e : bouton 'Poubelle' juste au dessus du précédent et voilà une relation toute neuve, avec tous les tags, et vide de membres. Donc bon... En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ? Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) ) Actuellement, la relation [1] a 259 membres : 258 ways et un node. En ajoutant les 455 références des 455 communes, on triple presque le nombre de membres, mais surtout on mélange 2 styles de références, on va vers des objets un peu monstrueux je trouve. Les relations actuelles se concentrent sur la géométrie d'un objet, et rien d'autre. Celles dont on parle avec les subarea ne décrivent pas de géométrie, mais des relations d'inclusion via la sémantique : un arbre, qui irait de la racine (le pays) aux communes voire aux quartiers, via des branches : les régions, les depts, etc. Tout dans la même relation, je trouve ça à la fois moins lisible, moins évident à comprendre car hétéroclite, accessoirement plus lourd à manipuler. Bref, je ne vois pas d'avantages, plutôt (que) des inconvénients. En modélisant ça à part, on assure, mine de rien, une compatibilité pour les usages actuels des boundary : leurs consommateurs n'y verraient que du feu. Mais les nouvelles relations, hiérarchiques, seraient simples à combiner aux boundaries, avec une clé ultra simple pour ce qui concerne nos découpages admin : le ref:INSEE et rien que lui. Je préfère un seul objet OSM pour représenter une unique entité sur le terrain (la région machinchose, le département trucmuche). Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet représentant en même temps une surface et un linéaire ? ;) Va savoir :-) Mais moi aussi je préfère un seul objet par entité. Mais ici j'estime qu'on représente 2 notions distinctes : d'un côté des emprises géométriques, indépendantes les unes des autres (ce qui est le problème à l'origine de ce fil) et de l'autre un arbre, ici administratif mais on pourrait appliquer ça à d'autres cas. vincent [1] : http://www.openstreetmap.org/browse/relation/7392 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
En attendant le grand soir relationniste, j'ai fait ma liste de communes de la CUB à la main. Ceci dit, j'ai besoin des autres communautés urbaines aussi, et des autres niveaux d'EPCI plus tard... Donc la discussion m'intéresse au-delà de mon petit problème bordelais : y a-t-il un consensus sur le fait que je peux ajouter un lien entre les relations commune et les relations EPCI ? Est-ce quelqu'un a un brouillon de comment ça se traduit dans les logiciels courants (me connaissant, je serais fichu de faire de la CUB une partie de Bordeaux au lieu du contraire) PS : venant d'un monde adepte de bases de données plates comme des crêpes, c'est un authentique trésor que cette notion de relation. Fionn Le 19 septembre 2013 16:52, Philippe Verdy verd...@wanadoo.fr a écrit : Plutôt que les is_in:*=* ou les left/right:*=* franchement on peut consolider beaucoup plus facilement et avec énormément moins de données avec le modèle ensembliste (ne vous fiez pas au nom donné subarea pour le rôle, ce n'est pas du tout une notion surfacique à proprement parler car cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et aucune coordonnée). Essayez avec le modèle purement géométrique d'obtenir la liste des 22 régions métropolitaines ! il faut télécharger actuellement plus de 800 000 chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des heures de téléchargement, des millions de requêtes envoyées au serveur (ou bien on peut télécharger un gros fichier dump de la base et passer plusieurs jours à monter une base locale: quel gachis de temps pour tout le monde !) et consommer une bande passante réseau de plusieurs gigaoctets. Alors que 22 membres en tout et pour tout (membres ensembliste) dans la base suffisent et permet d'avoir cette liste en quelques millisecondes avec 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko, ce qui est accessible à n'importe quel utilisateur ayant une relation internet lente ou un matériel très limité en capacité de stockage et de calcul ! Cela n'exclue pas de stocker aussi dans les relations les contours externes mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne le fait plus pour la France entière car on aurait beaucoup trop de chemins membres, la frontière est déjà scindée en plusieurs parties stockées à part et on a beucoup de mal à synchroniser les différents niveaux hiérarchiques de façon cohérente: mais ce sont ces frontières qui ont une redondance énormes car on doit les reporter à tous les niveaux (et on passe son temps à chercher comment les réparer efficacement et rapidement sans erreur. Alors oui je suis favorable à la suppression des tags is_in (les membres de rôle subarea sont énormément plus efficaces), et des tags left/right beaucoup trop redondants et limités à une seule langue arbitraire (les chemins frontières avec leurs rôles inner/outer suffisent, ces rôles pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la géométrie, si elle est correcte et complète, la distinction entre inner et outer est une facilité qui évite de devoir le calculer par un traitement complexe nécessitant la connaissance intégrale du détail des géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles pour détecter des incohérences et vérifier l'intention du tracé initial; ces rôles 'inner et outer sont vérifiables automatiquement de façon asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir à charger le détail complet des géométries).. Le 19 septembre 2013 16:29, Pieren pier...@gmail.com a écrit : 2013/9/19 Pieren pier...@gmail.com: Et si on va dans la consolidation, on peut aussi rétablir tous les is_in qui ont été injustement supprimés. Et mettre des addr:country=France sur toutes les adresses en France. Parce qu'il y aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et pis, ça consolide et on pourra mieux détecter les incohérences. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
2013/9/19 Frédéric Rodrigo fred.rodr...@gmail.com: Même si la redondance crée des problèmes, elle consolide l'ensemble. Et c'est les mêmes qui suppriment les left/right:village sur les ways qui nous disent ça... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osrm ferroviaire ?
Il y a des choses qu'il faudra sûrement traiter en plus qu'un simple rail.lua Les voies ferrées sont tracées mais les aiguillages sont rarement renseignés, or lorsque 2 voies se croisent il n'y a pas forcément d'aiguillage, ça peut être un simple croisement. Les trains ne peuvent pas non plus faire des virages n'importe comment même si les way sont connectés... un beau casse tête en perspective où il faudrait déterminer le graphe aussi en se basant sur la géométrie des intersections... Le 19 septembre 2013 17:06, Ab_fab gamma@gmail.com a écrit : Est-ce que cela peut se résumer à la bidouille d'un nouveau profil rail.lua ? https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles Ca a l'air d'être la conclusion de la discussion ici : https://github.com/DennisOSRM/Project-OSRM/issues/90 Le 19 septembre 2013 16:56, HELFER Denis denis.hel...@rff.fr a écrit : Bonjour à tous, ** ** Je suis confronté à un problème pour l’heure insoluble. Je cherche à calculer la distance d’itinéraires entre deux gares ferroviaires quelconques au niveau européen. Pas de problème pour le routier, tout le monde sait faire. Pas de problème non plus pour le temps de trajet ferroviaire entre une origine et une destination, mais point de kilométrage. Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes (pas de LGV, par exemple) soit partielle (ou les deux). Des pistes sur des ressources existantes que j’aurai manqué ? La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) : quel serait la méthode et le cout (technique/financier) pour adapter osrm à du routing ferroviaire. J’ai déjà lu ceci : https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines ** ** A vot’bon coeur ** ** ** ** *Denis HELFER* *Chargé d’études géomatiques* *Correspondant SI* *03 88 23 95 58 * [image: Description : Description : D:\Documents and Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG]** ** ** ** ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ image001.jpg___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] osrm ferroviaire ?
Bonjour à tous, Je suis confronté à un problème pour l'heure insoluble. Je cherche à calculer la distance d'itinéraires entre deux gares ferroviaires quelconques au niveau européen. Pas de problème pour le routier, tout le monde sait faire. Pas de problème non plus pour le temps de trajet ferroviaire entre une origine et une destination, mais point de kilométrage. Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes (pas de LGV, par exemple) soit partielle (ou les deux). Des pistes sur des ressources existantes que j'aurai manqué ? La question subsidiaire (j'ai déjà pas mal fouillé le web sans succès) : quel serait la méthode et le cout (technique/financier) pour adapter osrm à du routing ferroviaire. J'ai déjà lu ceci : https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines A vot'bon coeur Denis HELFER Chargé d'études géomatiques Correspondant SI 03 88 23 95 58 [Description : Description : D:\Documents and Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG] inline: image001.jpg___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible
Problème pour les datas de Rennes. Qui rapidement bloque l'outil avec des tuiles qui ne se chargent plus du tout et le javascript qu part en boucle interne, et va faire des requêtes n'importe où au serveur de tuiles pour essayer de récupérer des tuiles partout sauf celles qu'on voudrait afficher, et qui les affiche même pas à la position de la souris quand on glisse la carte. Ca commence à bloquer dès qu'on essaye de marquer un point de nom de rue comme déjà OK dans la base OSM. Après 3 ou 4, on dirait qu'on commence à tomber à cours de requêtes HTTTP et le javascript se bloque en attendant une session, ou bien comemnce à mélanger les états des requêtes HTTP en cours.pas détectées comme terminées. Le 19 septembre 2013 12:16, Bruno Cortial bruno.cort...@laposte.net a écrit : Le 19 septembre 2013 11:49, Philippe Verdy verd...@wanadoo.fr a écrit : Le rendu carto a quelques problèmes de bloquage dans son javascript (avec un comportement étrange du zoom, et une suraccélération de la souris). Les tuiles ne se raffraichissent pas correctement, leur position ne correspond pas au glissement du curseur. On dirait un paramètre incorrect pour ajuster les zooms dans l'intégration javascript, ou bien un type de projection incorrect. Toute cette m* de javascript est mon chef-d’œuvre de grand débutant JS, et comme telle restera inachevé (par moi) si aucun bug bloquant n'est remonté.Traduction: Ca juste marche ! Plus sérieusement, c'est où le pb, quelle ville ? Pas la peine d'envoyer un permalink, çà marche pas ;-) Sinon, Philippe, si tu passes par Nantes ou Pornic, contactes-moi. On discutera calmement OSM, et on verra si tu es aussi endurant au clavier que derrière une chopine. A+ BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Justement c''est le modèle purement géométrique qui a une quantité ENORME de redondance en lui-même. beaucoup plus que le modèle ensembliste. Et je suis en vieux routier des BDD, je sais aussi de quoi je parle. Et ceux qui parlent de mettre le modèle ensembliste dans des relations séparées à part des relations géométriques militent en fait pour un redondance enorome de données (deux objets séparés avec duplication intégrale des attributs juste pour gérer des listes de membres différentes, alors qu'on a déjà la notion de rôle pour distinguer les listes de membres sans rien dupliquer du tout). Le modèle ensembliste pourtant est beaucoup plus efficace que d'ajouter aussi des tags is_in : là oui ces derniers sont des redondances très lourdes, très volumineuses, et difficiles à maintenir (mais la seule chose qu'on a pu faire pour tenter de garder une trace des morceaux de géométries cassées...). Rien que is_in:country=* génère des millions de copies de l'attribut pour un pays comme la France. En comparaison le modèle ensembliste générera ***1 et 1 seul*** membre par commune (preuve qu'il n'a pas de redondance en lui-même) quel que soit le nombre de niveaux administratifs gérés, et le modèle géométrique à frontières génère 6 à 12 membres par commune, chaque chemin membre étant inclus presque toujours au moins deux fois (et souvent plus pour les niveaux adminsitratifs muttiples), ce qui montre une redondance intrinsèque du modèle géométrique à lui tout seul (et qui pourtant n'arrive pas à se stabiliser et qu'il est difficile de vérifier et parcourir, et qui rend toute rechercher ultra compliquée et lourde à faire si c'est le seul moyen). Si tu commence à parler d'éviter les redondances, alors clairement c'est le modèle géométrique actuel (chemins frontières ou surfaces, même chose) qui a perdu depuis toujours quand les données sont à la base essentiellement hiérarchiques (et donc mieux représentés par un modèle ensembliste, avec comme membres des régions filles sans aucune petite fille) Le 19 septembre 2013 15:54, Pieren pier...@gmail.com a écrit : 2013/9/19 Christian Quest cqu...@openstreetmap.fr: J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. Non (snip) Il faut écouter les vieux routiers des bdd : la redondance ne détecte pas les incohérences, elle les créer ! Encore plus dans un projet comme OSM où chaque entité peut être modifiée séparément et sans contrôle. Les relations boundary sont déjà très difficiles à maintenir. Vous allez doubler le travail sur 36000 communes, 100 départements et 22 régions, doublez le nombre de relations (ou leur taille); tout ça pour éviter que quelques personnes remplissent une base spatiale avec osm2pgsql... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
plutôt que de parler de notion relationiste, moi je préfère parler de notion ensembliste. - Certains sont trompés sur une fausse distinction entre modèle par frontières et modèle par surface alors que c'est exactement la même chose et fait avec les mêmes données de géométrie : des noeuds avec des coordonnées, et des chemins pour les assembler et un attribut ou un type unique permettant de donner une interprétation soit comme surface bidimentionnelle soit comme tracé filaire unidimentionnel. - Le nom du rôle subarea est trompeur. En fait ce serait plus clair si c'était include (notion ensembliste, totalement détaché de la géométrie) et on devrait pouvoir aussi ajouter un rôle exclude (notion également ensembliste) ce qui permet aussi de créer des exceptions locales à un modèle purement hiérarchique (les exceptions existent partout en géographie humaine, à commencer par nos administrations compliquées), mais cela ne change rien à la volumétrie et la modélisation. LE but n'est pas réellement de déinir des surfaces (au sens géométrique) mais bien des ensembles d'entités (il n'y a pas obligation non plus que les entités membres listées en include ou exclude soient disjointes entre elles, rien que le rôle exclude n'est utile que si justement il y a des intersections d'ensembles. Si on doit modéliser ça: il vaut mieux en terme de volumétrie des données lister les communes comme membres dans la relation EPCI (avec un rôle subarea tel qu'il existe déjà, ou renommé include). plutôt que le contraire (équivalent topologique aux actuels tags is_in qui sont clairemetn indésirables). Donc Bordeaux sera listé comme membre de la relation de la CUB, plutot que le contraire (Bordeaux contient un membre avec un rôle spécifique pour donner son EPCI à fiscalité propre, la CUB, mais combien de membres (et de dôles spécifiques) faudra-t-il pour lister les EPCI et autres structures (administratives, ministérielles et régaliennes, commerciales, encironnementales) auxquelles Bordeaux est attaché). Logiquement c'est Bordeaux qui est membre de la CUB et pas le contraire, soyons logique ! Un unique nom de rôle include suffit pour modéliser les ensembles (si on ajoute exclude c'est pour permettre d'inclure une sous-région comme les autres, mais d'en exclure un fragment, ce qui simplifie les choses. Le 19 septembre 2013 17:17, Fionn Halleman fionn.halle...@valeurs-mobiles.fr a écrit : En attendant le grand soir relationniste, j'ai fait ma liste de communes de la CUB à la main. Ceci dit, j'ai besoin des autres communautés urbaines aussi, et des autres niveaux d'EPCI plus tard... Donc la discussion m'intéresse au-delà de mon petit problème bordelais : y a-t-il un consensus sur le fait que je peux ajouter un lien entre les relations commune et les relations EPCI ? Est-ce quelqu'un a un brouillon de comment ça se traduit dans les logiciels courants (me connaissant, je serais fichu de faire de la CUB une partie de Bordeaux au lieu du contraire) PS : venant d'un monde adepte de bases de données plates comme des crêpes, c'est un authentique trésor que cette notion de relation. Fionn Le 19 septembre 2013 16:52, Philippe Verdy verd...@wanadoo.fr a écrit : Plutôt que les is_in:*=* ou les left/right:*=* franchement on peut consolider beaucoup plus facilement et avec énormément moins de données avec le modèle ensembliste (ne vous fiez pas au nom donné subarea pour le rôle, ce n'est pas du tout une notion surfacique à proprement parler car cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et aucune coordonnée). Essayez avec le modèle purement géométrique d'obtenir la liste des 22 régions métropolitaines ! il faut télécharger actuellement plus de 800 000 chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des heures de téléchargement, des millions de requêtes envoyées au serveur (ou bien on peut télécharger un gros fichier dump de la base et passer plusieurs jours à monter une base locale: quel gachis de temps pour tout le monde !) et consommer une bande passante réseau de plusieurs gigaoctets. Alors que 22 membres en tout et pour tout (membres ensembliste) dans la base suffisent et permet d'avoir cette liste en quelques millisecondes avec 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko, ce qui est accessible à n'importe quel utilisateur ayant une relation internet lente ou un matériel très limité en capacité de stockage et de calcul ! Cela n'exclue pas de stocker aussi dans les relations les contours externes mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne le fait plus pour la France entière car on aurait beaucoup trop de chemins membres, la frontière est déjà scindée en plusieurs parties stockées à part et on a beucoup de mal à synchroniser les différents
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Le 19/09/2013 18:02, Philippe Verdy a écrit : C'est à que tu te trompes complètement car tu ne comptes pas tout ! Tu ne regarde QUE la relation de l'Yonne et pas les relations des communes. et tu oublies aussi qu'entre les deux il y a les arrondissements. Pour l'Yonne cela ajouterait SEULEMENT les 3 ou 4 membres des arrondissements et c'est tout (1 membre unique par arrondissement pour toute la base de données), mais pas toutes les communes; dans chaque arrondissement il y a aura uniquement la cinquantaine de communes. dans la commune il n'y aura rien du tout (sauf si elle a un découpage administrarif infracommunal au niveau 9 ou plus). Tu as raison, le niveau des arrondissements change les chiffres, en s'intercalant. Mais ça ne change rien au principe : ce que je décrivais pour une relation de département s'applique à une relation d'arrdt, en divisant (en moyenne par 3 ou 4) la liste des références de communes. Pour toute la France et pour la totalité de sa structure adminsistrative de niveau 2 à 8, il ne faudra pas plus de 4 membres (répartis parmi les 4 relations existantes, soit effectivement 1 seul membre ajouté en moyenne par relation !). Sûrement pas : la répartition se fera surtout parmi les relations au dessus des communes, donc il faut enlever un bon 36000 à ton 2e 4. Alors qu'on a pas loin du million de chemins et des dizaines de millions de noeuds à télécharger ou mettre à jour pour seulement en déduire (par un calcul très compliqué et faux en permanence car jamais les données ne sont complètes et cohérentes) sa structure administative ! Il n'y a pas photo, le modèle ensembliste est très largement gagnant et assure à lui tout seul une totale absence de redondance, donc la solidité et la cohérence d'ensemble. Les chemins ne sont réellement nécessaires qu'au niveau le plus fin des relations (donc dans les feuilles au niveau 8 si c'et le niveau final) et TOUS les autres chemins sont des redondances. De plus il y a une autre redondance par le fait que chaque chemin est mentionné au moins deux fois (par les relations limitrophes qu'il délimite), ce qui n'arrive pas non plus avec la définition ensembliste. Bref reprend tes calculs et n'oublie rien : mais si tu ne veux pas regarder le problème complet, tu vas tirer des conclusions fausses comme ci-dessus. Je n'ai rien contre le modèle ensembliste, comme tu l'appelles. Je lui trouve un véritable intérêt pour sa capacité à décrire, autrement que par inclusion spatiale, des relations entre objets. Et je m'en sers au quotidien, donc je suis d'avance convaincu. Je pense que décrire ces relations dans OSM apporterait une vraie plus-value. Je parle ici en pensant aux usages, aux consommateurs. La demande initiale de Fionn est un cas d'usage, concret. Il y en aura d'autres à l'avenir, enfin on ne peut que l'espérer ! Là où, définitivement, j'ai un souci, c'est avec la volonté de tout ranger dans un même sac : géométrie et relations hiérarchiques. En pensant aussi bien à la maintenance qu'à la réutilisation, je ne suis pas convaincu par la pertinence. Mais bon, je radote. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osrm ferroviaire ?
La réponse simple à ta dernière question est « non » aussi surprenant que cela puisse paraitre. En revanche, c'est un projet dont l'horizon n'est plus si lointain. Ce n'est pas encore dit que cela sera de l'open data. De : Fionn Halleman [mailto:fionn.halle...@valeurs-mobiles.fr] Envoyé : jeudi 19 septembre 2013 18:03 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] osrm ferroviaire ? Si le raisonnement est très macro (de l'interurbain à l'échelle européenne), alors l'absence de turn_restrictions ne doit pas être un énorme problème. Ceci est aussi vrai pour le réseau routier, mais il faudrait voir pour le cas du rail. Et s'il fallait vraiment tenir compte du fait que les trains ne peuvent pas prendre des virages en épingle : 1/ ils peuvent en revanche rebrousser chemin (j'ai en tête la liaison Angoulême-Royan, ou la gare Saint-Charles à Marseille) 2/ on peut peut-être utiliser le fait qu'OSRM semble pouvoir appliquer des pénalités selon l'angle du virage (sauf si c'est à 180°, auquel cas c'est un rebroussement). Un autre problème que j'ai remarqué (mais qui ne devrait pas être bloquant pour un calcul d'iti interurbain) est que la base OSM est parfois très précise (l'ensemble des voies est représentées), parfois au contraire insuffisamment détaillée (un seul axe pour plusieurs voix, cf Bordeaux-La Rochelle). Euh... Ce n'est d'ailleurs pas une donnée dont dispose RFF ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Plutôt que les is_in:*=* ou les left/right:*=* franchement on peut consolider beaucoup plus facilement et avec énormément moins de données avec le modèle ensembliste (ne vous fiez pas au nom donné subarea pour le rôle, ce n'est pas du tout une notion surfacique à proprement parler car cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et aucune coordonnée). Essayez avec le modèle purement géométrique d'obtenir la liste des 22 régions métropolitaines ! il faut télécharger actuellement plus de 800 000 chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des heures de téléchargement, des millions de requêtes envoyées au serveur (ou bien on peut télécharger un gros fichier dump de la base et passer plusieurs jours à monter une base locale: quel gachis de temps pour tout le monde !) et consommer une bande passante réseau de plusieurs gigaoctets. Alors que 22 membres en tout et pour tout (membres ensembliste) dans la base suffisent et permet d'avoir cette liste en quelques millisecondes avec 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko, ce qui est accessible à n'importe quel utilisateur ayant une relation internet lente ou un matériel très limité en capacité de stockage et de calcul ! Cela n'exclue pas de stocker aussi dans les relations les contours externes mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne le fait plus pour la France entière car on aurait beaucoup trop de chemins membres, la frontière est déjà scindée en plusieurs parties stockées à part et on a beucoup de mal à synchroniser les différents niveaux hiérarchiques de façon cohérente: mais ce sont ces frontières qui ont une redondance énormes car on doit les reporter à tous les niveaux (et on passe son temps à chercher comment les réparer efficacement et rapidement sans erreur. Alors oui je suis favorable à la suppression des tags is_in (les membres de rôle subarea sont énormément plus efficaces), et des tags left/right beaucoup trop redondants et limités à une seule langue arbitraire (les chemins frontières avec leurs rôles inner/outer suffisent, ces rôles pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la géométrie, si elle est correcte et complète, la distinction entre inner et outer est une facilité qui évite de devoir le calculer par un traitement complexe nécessitant la connaissance intégrale du détail des géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles pour détecter des incohérences et vérifier l'intention du tracé initial; ces rôles 'inner et outer sont vérifiables automatiquement de façon asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir à charger le détail complet des géométries).. Le 19 septembre 2013 16:29, Pieren pier...@gmail.com a écrit : 2013/9/19 Pieren pier...@gmail.com: Et si on va dans la consolidation, on peut aussi rétablir tous les is_in qui ont été injustement supprimés. Et mettre des addr:country=France sur toutes les adresses en France. Parce qu'il y aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et pis, ça consolide et on pourra mieux détecter les incohérences. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osrm ferroviaire ?
Le jeudi 19 septembre 2013 18:15:03, HELFER Denis a écrit : La réponse simple à ta dernière question est « non » aussi surprenant que cela puisse paraitre. Ca, pour être surprenant, ça l'est En revanche, c’est un projet dont l’horizon n’est plus si lointain. Ce n’est pas encore dit que cela sera de l’open data. Croisons les doigts... En attendant, j'ai commencé à dessiner la seconde voie de Nantes vers Bordeaux. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Le 19 septembre 2013 17:42, V de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest Il ne faut pas prendre boundary au pied de la lettre... Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme n'est pas choisi au hasard, non ? Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui va avec). La recopie de tags, c'est 3 clic dans JOSM 1er : 3e bouton en partant de la gauche dans le panneau des relations = ouvre une nouvelle relation copiée sur celle sélectionnée initialement 2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation pour sélectionner tous les membres 3e : bouton 'Poubelle' juste au dessus du précédent et voilà une relation toute neuve, avec tous les tags, et vide de membres. Donc bon... En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ? Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) ) Actuellement, la relation [1] a 259 membres : 258 ways et un node. En ajoutant les 455 références des 455 communes, on triple presque le nombre de membres, mais surtout on mélange 2 styles de références, on va vers des objets un peu monstrueux je trouve. C'est à que tu te trompes complètement car tu ne comptes pas tout ! Tu ne regarde QUE la relation de l'Yonne et pas les relations des communes. et tu oublies aussi qu'entre les deux il y a les arrondissements. Pour l'Yonne cela ajouterait SEULEMENT les 3 ou 4 membres des arrondissements et c'est tout (1 membre unique par arrondissement pour toute la base de données), mais pas toutes les communes; dans chaque arrondissement il y a aura uniquement la cinquantaine de communes. dans la commune il n'y aura rien du tout (sauf si elle a un découpage administrarif infracommunal au niveau 9 ou plus). Total ajouté dans la base : jamais plus de membres ajoutés qu'il y a de relations dans la base. Et il ne s'agit de remonter dans le parent qu'une seule et unique donnée, mais aucun de ses autres attributs (on ne duplique pas les noms, on ne duplique pas non plus la géométrie comme on l'a fait à l'excès dans les listes de chemins membres outer/inner où il faut souvent remonter plein de chemins de la relation fille vers la mère, dont le volume explose : il suffit de regarder les relations du pays, des réions et départements=et même des arrondissements). Franchement fais tes calculs correctement et va voir réellement la situation en Espagne et en Belgique et fait le compte : ces membres ajoutés sont une partie INFIME des données en comparaison des membres inner/outer des listes de chemins. Pour toute la France et pour la totalité de sa structure adminsistrative de niveau 2 à 8, il ne faudra pas plus de 4 membres (répartis parmi les 4 relations existantes, soit effectivement 1 seul membre ajouté en moyenne par relation !). Alors qu'on a pas loin du million de chemins et des dizaines de millions de noeuds à télécharger ou mettre à jour pour seulement en déduire (par un calcul très compliqué et faux en permanence car jamais les données ne sont complètes et cohérentes) sa structure administative ! Il n'y a pas photo, le modèle ensembliste est très largement gagnant et assure à lui tout seul une totale absence de redondance, donc la solidité et la cohérence d'ensemble. Les chemins ne sont réellement nécessaires qu'au niveau le plus fin des relations (donc dans les feuilles au niveau 8 si c'et le niveau final) et TOUS les autres chemins sont des redondances. De plus il y a une autre redondance par le fait que chaque chemin est mentionné au moins deux fois (par les relations limitrophes qu'il délimite), ce qui n'arrive pas non plus avec la définition ensembliste. Bref reprend tes calculs et n'oublie rien : mais si tu ne veux pas regarder le problème complet, tu vas tirer des conclusions fausses comme ci-dessus. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
