[talk-ph] Drones (UAV's) in Th ePhilippines
Drones must be registered, their ‘pilots’ licensed MANILA, Philippines–The Civil Aviation Authority of the Philippines (CAAP) on Thursday advised model aircraft enthusiasts that drones and other unmanned aircraft vehicles (UAV) must be registered and their controllers licensed. CAAP issued a memorandum circular signed on June 26 reminding officials of the new provisions under the Philippine Civil Aviation Regulations Part II. Under the provisions, owners and operators must register their equipment with CAAP which is the only agency authorized to issue them license to operate. “Any operator found violating [these] rules will be fined between P300,000 to P500,000 per unauthorized flight, depending on the gravity of the violations,” the CAAP said in a statement. Capt. Beda Badiola, assistant director general of CAAP and head of the flight standard inspectorate service, said reports had reached his office that drone users in the country are fast increasing as its prices have started to go down. A drone can cost roughly P50,000. But instead of licensed operators, CAAP said drones are mostly used by photographers, hobbyists, researchers and employees of firms doing geodetic surveys and media companies. “Any violation of the said memorandum will be dealt with accordingly,” said Badiola, whose office oversees and regulates all flight operations of aircraft manned and unmanned in the Philippines. He said the aviation body even imposes stiff penalty on violators in restricted areas like airports, crowded areas and “no fly zone.” In its memo, CAAP classified the UAV into large, micro and small. Large UAV are unmanned airship with an envelope capacity greater than 100 cubic meters while micro UAV means that with a gross weight of 100 grams or less. A small UAV means an unmanned aircraft that is neither a large UAV nor a micro UAV. Owners of these aircraft must obtain a certification from CAAP, the registration cost of which would still have to be determined by the aviation body. “That would normally depend on the gross weight,” Badiola said. Regards Mark Cupitt If we change the world, let it bear the mark of our intelligence See me on Open StreetMap https://www.openstreetmap.org/user/Mark_Cupitt See me on LinkedIn http://ph.linkedin.com/in/markcupitt *See me on StackExchange http://gis.stackexchange.com/users/17846/mark-c* === The contents of this email are intended only for the individual(s) to whom it is addressed and may contain confidential or privileged information. If you are not the intended recipient, you must not disclose, copy, distribute, or use the contents of this email. If you have received this email in error, please notify the sender immediately and delete the email and any attachments. === ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Am 24/lug/2014 um 23:03 schrieb Alex Barth a...@mapbox.com: In this example, the database powering the geocoder is a derived database. The geocoding results are produced works, which are then collected into what forms a derivative database as part of a collective database. Not following how I can make a Derivative Database from a Produced Work. Once it's a Produced Work it's a Produced Work, right? I also see it like this, it would be a database of works (like a database of renderings) and not under ODbL, therefore I think the premise that a geocoding result is a produced work might already be flawed, because it seems natural that a database of results is a derivative database. cheers, Martin___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Thu, Jul 24, 2014 at 5:03 PM, Alex Barth a...@mapbox.com wrote: Forward and reverse geocoding existing records is such a huge potential use case for OSM, helping us drive contributions. At the same time it's _the_ use case of OSM where we collide heads on with the realities and messiness of data licensing: Do we really want to make a legal review the hurdle of entry for using OSM for geocoding? Or limit using OSM for geocoding in areas where no one's ever going to sue? How can we get on the same page on how we want geocoding to work and then trace back on how we can fit this into the ODbL? Geocoding should just be possible and frictionless with OSM, no? Shouldn't there be a way to open up OSM to geocoding while maintaining share alike on the whole database? These are the key questions I support open geocoding with share alike applied to the whole database. How can we get clarity on this either way? Because not clarifying this is effectively saying no which I believe loses high-quality contributions. Clarifying with a no or not clarifying at all will direct a lot of effort elsewhere -- this is a shame. In a previous role I directed a lot of resources specifically toward OSM. With this continued lack of clarity, today I would direct them elsewhere. That's also a shame. (and yes, when I'm saying geocoding I'm referring to permanent geocoding here, where the geocoding result winds up being stored in someone else's db) To not support this is essentially saying that OSM is not to be used for geocoding in the majority of desired cases. But it comes down to what people want for the project, and where address-level effort will go. -Randy ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Salut Pierre Thanks - But this doesn't parse (see below). I'm getting: Error: line 4: static error: Element print cannot be subelement of element union. -- Stefan [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center; ); ; out meta qt; 2014-07-24 15:20 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Stefan, In your example, the parenthesis are making a union of the two requests. and the greater then ( ) is doing a recurse request. This example below is working. It extract independantly nodes and ways, calculating the centroid for the ways. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Jeudi 24 juillet 2014 9h44 Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Salut Pierre Thanks - But this doesn't parse (see below). I'm getting: Error: line 4: static error: Element print cannot be subelement of element union. -- Stefan [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center; ); ; out meta qt; 2014-07-24 15:20 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Thanks again - I think I got it - including a bug: GeoJSON is still returning polygons! But with XML it works. E.g. replacing [out:json] with [out:xml] or exporting as XML. --Stefan 2014-07-24 15:48 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your example, the parenthesis are making a union of the two requests. and the greater then ( ) is doing a recurse request. This example below is working. It extract independantly nodes and ways, calculating the centroid for the ways. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Jeudi 24 juillet 2014 9h44 Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Salut Pierre Thanks - But this doesn't parse (see below). I'm getting: Error: line 4: static error: Element print cannot be subelement of element union. -- Stefan [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center; ); ; out meta qt; 2014-07-24 15:20 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
In my last overpass test with the new out center feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. 2014-07-24 16:30 GMT+02:00 Stefan Keller sfkel...@gmail.com: Thanks again - I think I got it - including a bug: GeoJSON is still returning polygons! But with XML it works. E.g. replacing [out:json] with [out:xml] or exporting as XML. --Stefan 2014-07-24 15:48 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your example, the parenthesis are making a union of the two requests. and the greater then ( ) is doing a recurse request. This example below is working. It extract independantly nodes and ways, calculating the centroid for the ways. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Jeudi 24 juillet 2014 9h44 Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Salut Pierre Thanks - But this doesn't parse (see below). I'm getting: Error: line 4: static error: Element print cannot be subelement of element union. -- Stefan [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center; ); ; out meta qt; 2014-07-24 15:20 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Wiki translate extension
Hi all, As for improving translation tasks on OSM wiki, how would you feel about the Mediawiki Translate extension ? https://www.mediawiki.org/wiki/Extension:Translate I won't explain how important translated content is for non-english people looking for reference or documentation. This extension can really help us to maintain constant quality in this localized content, especially tag pages. I don't know if another better software extension exists for MediaWiki, this one bring really good features. Cheers. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
On Thu, Jul 24, 2014 at 5:33 PM, Christian Quest cqu...@openstreetmap.fr wrote: In my last overpass test with the new out center feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. It's already reported: https://github.com/drolbr/Overpass-API/issues/93 Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Drones
Greetings. I'm curious to know if any OSM groups are currently running their own drones for imagery. In Iceland we have been looking longingly at the eBee https://www.sensefly.com/drones/ebee.html but so far haven't started fundraising for it. Are there similarly sophisticated yet cheaper options around and currently in use? --Jói ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
it is exact Christian. It did work with xml. But re-running with the json output option, the centroid is not added. Pierre De : Christian Quest cqu...@openstreetmap.fr À : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Jeudi 24 juillet 2014 11h33 Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? In my last overpass test with the new out center feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. 2014-07-24 16:30 GMT+02:00 Stefan Keller sfkel...@gmail.com: Thanks again - I think I got it - including a bug: GeoJSON is still returning polygons! But with XML it works. E.g. replacing [out:json] with [out:xml] or exporting as XML. --Stefan 2014-07-24 15:48 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your example, the parenthesis are making a union of the two requests. and the greater then ( ) is doing a recurse request. This example below is working. It extract independantly nodes and ways, calculating the centroid for the ways. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : Talk Openstreetmap talk@openstreetmap.org Envoyé le : Jeudi 24 juillet 2014 9h44 Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Salut Pierre Thanks - But this doesn't parse (see below). I'm getting: Error: line 4: static error: Element print cannot be subelement of element union. -- Stefan [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center; ); ; out meta qt; 2014-07-24 15:20 GMT+02:00 Pierre Béland pierz...@yahoo.fr: Stefan, In your request, you make a recursive query that loads nodes from the way. In this example, the node and way queries are independant. For the way, the center command is used. [out:json] [timeout:25] ; node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta; way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); out meta center qt; Pierre De : Stefan Keller sfkel...@gmail.com À : Talk Openstreetmap talk@openstreetmap.org Cc : Roland Olbricht roland.olbri...@gmx.de Envoyé le : Jeudi 24 juillet 2014 8h19 Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) function? Hi, I'm trying to get a list of point features only (as GeoJSON or XML). This could serve as input e.g. to uMap. The problem is that the query returns points but also areas. This is actually correct - but I want these areas converted to point geometries too (centered, like ST_Centroid). I then found the modifcator/keyword center in the Overpass QL [1]. But I still get polygons. See the query [2] below. Any ideas? --Stefan [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ *** Dairy (Käserei) Query ways/areas only... *** [out:json] [timeout:25] ; ( node[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); way[shop~dairy] (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); ); out meta center qt; ; out meta center qt; ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Drones
Hi, On Thu, Jul 24, 2014 at 03:54:29PM +, Jóhannes Birgir Jensson wrote: Greetings. I'm curious to know if any OSM groups are currently running their own drones for imagery. In Iceland we have been looking longingly at the eBee https://www.sensefly.com/drones/ebee.html but so far haven't started fundraising for it. I'd be very interested in a solution. Are there similarly sophisticated yet cheaper options around and currently in use? I found this one: https://store.3drobotics.com/products/3DR-Aero Additionally one would need a camera - e.g. some Canon (not DSLR) with CHDK or something beeing capable of continously shooting at e.g. 1/2Hz or something. Flash memory shouldnt be problem here. I am unshure about focal length, frequency of shooting, rectifying images (work needed) for later use in a WMS (GeoTIFF etc). Investing that much money without having an idea whether results are usable is a little risky :) Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Pieren wrote On Thu, Jul 24, 2014 at 5:33 PM, Christian Quest In my last overpass test with the new out center feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. It's already reported: https://github.com/drolbr/Overpass-API/issues/93 Pieren Right, some of the missing bits for JSON support are already implemented in the out_geom_json branch. However, Roland hasn't merged this branch into the master branch yet. https://github.com/drolbr/Overpass-API/tree/out_geom_json Best mmd -- View this message in context: http://gis.19327.n5.nabble.com/Overpass-API-Overpass-QL-center-and-centroid-function-tp5812491p5812549.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Drones
Am 24.07.2014 17:54, schrieb Jóhannes Birgir Jensson: Are there similarly sophisticated yet cheaper options around and currently in use? See http://wiki.openstreetmap.org/wiki/UAV I doubt that any of the DIY solutions can take it up with a commercial product wrt packaging, ease of use etc. But there it lots of information around and a reasonably good system can be built for less than Euro 2k. The main issue is a easy to use software tool chain for post processing the images. Some more or less random further links http://flightriot.com/ http://diydrones.com/ http://pixhawk.org/ http://www.bormatec.com/ signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
As for improving translation tasks on OSM wiki, how would you feel about the Mediawiki Translate extension ? I'm against any kind of automatic translation tool, which will just cause more errors. When I look up a word I'm usually at least presented with more than one translation. Also this seems geared towards 1:1 translations, which in the OpenStreetMap Wiki often isn't the reality, because some things are different from country to country. Or for example usefull combinations or see also might be different. Some pages might even be very country specific and a short summary for other languages might be enough as long as there is a English documentation. Also warnings like Do not confuse with xyz might only make sense in one language. What we really need is people actually editing the Wiki in the first place and in my opinion the best way to get people to do so would be a better editor: https://www.mediawiki.org/wiki/VisualEditor __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
What we really need is people actually editing the Wiki in the first place and in my opinion the best way to get people to do so would be a better editor: https://www.mediawiki.org/wiki/VisualEditor There's an issue for this on trac [1] but the main problem is that the extension moved from requiring mediawiki 1.23 to requiring mediawiki 1.24 which is still in development. [1] https://trac.openstreetmap.org/ticket/4920 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Dear all Thanks for the help - especially from the french colleagues. I'm still struggling even with the XML output. My actual goal is to display the result set of the Dairy/Cheese Makers query in uMap. When I apply the query below to http://overpass-turbo.osm.ch/ the result is OK (displayed POIs: 386, Lines: 300, Polygons: 138). But when I add this URL as remote data to uMap, there are less markers displayed. It seems again that there is a problem with the ways/areas: http://umap.osm.ch/de/map/kasereien_18 You can easily see the difference when comparing to Simon's solution: Simon actually gave up using overpass within uMap and preprocessed the data locally: http://umap.osm.ch/de/map/kasereien_6 --Stefan [out:xml] [timeout:25] ; ( node[shop~dairy]; node [name~[Kk]äserei|[Cc]häsi|[Ff]romagerie|[Cc]aseificio|[Cc]hascharia]; node[produce~cheese]; node[craft~cheese_making]; ); out meta; ( way[shop~dairy]; way [name~[Kk]äserei|[Cc]häsi|[Ff]romagerie|[Cc]aseificio|[Cc]hascharia]; way[produce~cheese]; way[craft~cheese_making]; ); out meta center qt; ( ._; ; ); out meta qt; 2014-07-24 19:58 GMT+02:00 mmd mmd@gmail.com: Pieren wrote On Thu, Jul 24, 2014 at 5:33 PM, Christian Quest In my last overpass test with the new out center feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. It's already reported: https://github.com/drolbr/Overpass-API/issues/93 Pieren Right, some of the missing bits for JSON support are already implemented in the out_geom_json branch. However, Roland hasn't merged this branch into the master branch yet. https://github.com/drolbr/Overpass-API/tree/out_geom_json Best mmd -- View this message in context: http://gis.19327.n5.nabble.com/Overpass-API-Overpass-QL-center-and-centroid-function-tp5812491p5812549.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
extension moved from requiring mediawiki 1.23 to requiring mediawiki 1.24 which is still in development. Can't you just use the old version that worked with 1.23? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
Stefan Keller wrote I'm still struggling even with the XML output. My actual goal is to display the result set of the Dairy/Cheese Makers query in uMap. When I apply the query below to http://overpass-turbo.osm.ch/ the result is OK (displayed POIs: 386, Lines: 300, Polygons: 138). But when I add this URL as remote data to uMap, there are less markers displayed. It seems again that there is a problem with the ways/areas: I created a new issue for umap now [1], as I believe the center tag is not yet handled during import. Please feel free to enhance the ticket as needed. [1] https://bitbucket.org/yohanboniface/umap/issue/94/overpass-api-extension-center-in-osm -- View this message in context: http://gis.19327.n5.nabble.com/Overpass-API-Overpass-QL-center-and-centroid-function-tp5812491p5812559.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
Hi Andreas, I agree with you about the automatic translation tool and that wasn't my point. Contributors should always translate documents by themselves without using any automatic tool. Nevertheless, some features of the extension would bring us some comfort when dealing with translation topic. I like the percentage of translation for each language indicator and the capability to know when the English page is more accurate/up to date than other ones. May some alternative software can do the same job ? Additionally to the visual editor (which is a really good tool too), it can be a strong adding to the OSM wiki, don't you ? Cheers. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com 2014-07-24 21:11 GMT+02:00 Andreas Goss andi...@t-online.de: extension moved from requiring mediawiki 1.23 to requiring mediawiki 1.24 which is still in development. Can't you just use the old version that worked with 1.23? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
Hi, On 07/24/2014 08:22 PM, Andreas Goss wrote: Also this seems geared towards 1:1 translations, which in the OpenStreetMap Wiki often isn't the reality, because some things are different from country to country. Or for example usefull combinations or see also might be different. Fully agree. I wonder if it might be better to do what Wikipedia have done - instead of having one Wiki where the same articles exist in different languages (and often with wildly different content), have a Wiki for every language where the community using that language can build their own OSM reference (with Interwiki links where useful). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
2014-07-24 22:47 GMT+02:00 Frederik Ramm frede...@remote.org: I wonder if it might be better to do what Wikipedia have done - instead of having one Wiki where the same articles exist in different languages (and often with wildly different content), have a Wiki for every language where the community using that language can build their own OSM reference (with Interwiki links where useful). Not really the kindest idea for those who try to bring reusable tags worldwide ;) I'm ok to say all things aren't the same in each country. That's why wiki and data should adapt in each translation/location. According to you, we'd better split OSM in several projects, one for each country and data consumers will do the rest. That's not the same deal. In my mind, OSM can't be break apart of its data reference if we want consumers find our data useful. If you split the reference, you should split the whole project. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
2014-07-24 21:39 GMT+02:00 mmd mmd@gmail.om mmd@gmail.com: I created a new issue for umap now [1], as I believe the center tag is not yet handled during import. Please feel free to enhance the ticket as needed. I'm almost sure it is not handled... but will be very soon as this overpass feature is really useful ! -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
Hi, On 07/24/2014 11:05 PM, François Lacombe wrote: According to you, we'd better split OSM in several projects, one for each country and data consumers will do the rest. This would be interesting but it is not what I said. I said, let's have different Wikis for different languages. It is simply a more holistic approach to the concept of translation. I don't believe in the kind of page-by-page, sentence-by-sentence, even word-by-word translation that some people seem to advocate. If we're after that, just dump all non-English content and use Google translate. If we want high-quality documentation for users of different languages, which will also often be people with wildly different cultural backgrounds, then that has to be written from scratch - perhaps informed by material in other languages but likely not translated. Using the same Wiki with language namespacing implements the concept of very close translations - the structure is the same for everyone, and the translator is just expected to fill in the blanks. I don't believe that this will lead to high-quality documentation; I believe this will be at best a little better than automatic translation. I think that the evolution of the project is replayed in different countries at different times. Speaking simplistically, the community in a country where OSM is just taking off might be better off with the kind of documentation available to OSM in France when the project was at the same state, rather than the sophisticated detail that is available today. If I am in a country where we have barely mapped the major road network, am I really interested in translations of turn lane relations and TMC information, or will such detail perhaps discourage me? You seem to be mainly equating the Wiki with a catalogue of tags but I think it is much more, and its relevance as a tag catalogue is shrinking with editor presets becoming ever more complex. Of course editor presets would also have to be localised (and not only translated)... ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
As a somewhat regular translator, I would like to say something. My gut feeling is that we shouldn't separate the wiki into different ones, but I can say there are some considerable issues on the model we have right now. Often when I am going to translate an article, I try to improve it, but because the english article is considered the main one, I end up having to improve the english article as well. This can be a big productivity killer. At the very least, when the page is about a key specific to my country, I can just stick a {{Translate from Portuguese}} template on the english page. I also take issue with the namespacing as it is. The page for the key highway=* is Key:highway in english, but it is Pt:Key:highway in portuguese. Just imagine what a portuguese speaker thinks when he sees something like that and doesn't know what it means. By reading the page's content, he can understand what highway means, because the generous translators explained, but what about Pt:Key ? I know what it means, that's just an example. Things like Talk: and User: prefix can be uncomfortable to some users too. I have to say that it wasn't intuitive to understand that, linking to other wiki page from a page in portuguese will link to an english page unless I stick a Pt: prefix before it. These are some of the issues I can remember right now. 2014-07-24 18:50 GMT-03:00 Frederik Ramm frede...@remote.org: Hi, On 07/24/2014 11:05 PM, François Lacombe wrote: According to you, we'd better split OSM in several projects, one for each country and data consumers will do the rest. This would be interesting but it is not what I said. I said, let's have different Wikis for different languages. It is simply a more holistic approach to the concept of translation. I don't believe in the kind of page-by-page, sentence-by-sentence, even word-by-word translation that some people seem to advocate. If we're after that, just dump all non-English content and use Google translate. If we want high-quality documentation for users of different languages, which will also often be people with wildly different cultural backgrounds, then that has to be written from scratch - perhaps informed by material in other languages but likely not translated. Using the same Wiki with language namespacing implements the concept of very close translations - the structure is the same for everyone, and the translator is just expected to fill in the blanks. I don't believe that this will lead to high-quality documentation; I believe this will be at best a little better than automatic translation. I think that the evolution of the project is replayed in different countries at different times. Speaking simplistically, the community in a country where OSM is just taking off might be better off with the kind of documentation available to OSM in France when the project was at the same state, rather than the sophisticated detail that is available today. If I am in a country where we have barely mapped the major road network, am I really interested in translations of turn lane relations and TMC information, or will such detail perhaps discourage me? You seem to be mainly equating the Wiki with a catalogue of tags but I think it is much more, and its relevance as a tag catalogue is shrinking with editor presets becoming ever more complex. Of course editor presets would also have to be localised (and not only translated)... ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
In my opinion we should try to keep the different language pages as similar as possible - that is, they should aim to be just translations of one another. My reason behind this is that OpenStreetMap is a community and data project. We need to work together and use common tagging so that developers can build tools based on OSM data. We should avoid an OpenStreetMap for people who can speak English, one for those that can speak French, etc... If there is country specific information about a tag then I would like to be aware of it, as it could be useful for other countries/languages too. That could be as simple as copying it to the English[1] language page (marking it as requiring translation) or if it's longer providing a link on the English language page. Also worth noting that a lot of the translations haven't stayed up to date. This works both ways - English page updated, translations not updated, or a non-English page updated and not copied back to the English page (in any language). I'd encourage people to copy between the pages even if they just mark the text as needing translating. Regards, Rob [1] You could also copy it to other language pages, but at a bare minimum the English page as this is considered the Main page/OSM's default language. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki VisualEditor (Was: Wiki translate extension)
extension moved from requiring mediawiki 1.23 to requiring mediawiki 1.24 which is still in development. Can't you just use the old version that worked with 1.23? VisualEditor is still in development. MediaWiki provide an extension so that non Wikimedia sites can start to use it but as of June 2014 this extension has required mw 1.24 https://www.mediawiki.org/w/index.php?title=Extension%3AVisualEditordiff=1021728oldid=1021727 Any version that worked with mw 1.23 was considered unstable and hence Grant was unwilling to install it for OSM's wiki. I don't blame Grant - he works hard to keep everything up and running and as such a stable version is a reasonable request. If anything it's the visualeditor developers who need to hurry up and stop pushing the requirements up - mw 1.22, mw 1.23, mw 1.24, ... when will it stop!! Rob ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
On 25.07.2014 01:04, Rob Nickerson wrote: In my opinion we should try to keep the different language pages as similar as possible - that is, they should aim to be just translations of one another. My reason behind this is that OpenStreetMap is a community and data project. We need to work together and use common tagging so that developers can build tools based on OSM data. We should avoid an OpenStreetMap for people who can speak English, one for those that can speak French, etc... I agree with that. We are a global project and we expect our software to work globally, so our documentation needs to be consistent across multiple languages. Of course there has always been content intended for a local audience, or pages that describe local conventions and so on. But I don't see why that should prevent us from also having content that applies globally. Content related to local topics should also not be confused with languages. Why should the page about Road signs in Germany not also be available in English, for example? Also worth noting that a lot of the translations haven't stayed up to date. This works both ways - English page updated, translations not updated, or a non-English page updated and not copied back to the English page (in any language). I've also noticed this everyday problem, and I believe the Translate extension could help with those cases. So I'm in favour to give it a try. Let's just install it, try it on a few pages, and see how well it works. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
+1 Language is not the same thing as country. There could well be French-speaking people mapping in England, English in Spain, Spanish in Egypt, Arabic-speakers in Turkey, Turks in Germany, etc. Steve On 25/07/2014 00:04, Rob Nickerson wrote: In my opinion we should try to keep the different language pages as similar as possible - that is, they should aim to be just translations of one another. My reason behind this is that OpenStreetMap is a community and data project. We need to work together and use common tagging so that developers can build tools based on OSM data. We should avoid an OpenStreetMap for people who can speak English, one for those that can speak French, etc... If there is country specific information about a tag then I would like to be aware of it, as it could be useful for other countries/languages too. That could be as simple as copying it to the English[1] language page (marking it as requiring translation) or if it's longer providing a link on the English language page. Also worth noting that a lot of the translations haven't stayed up to date. This works both ways - English page updated, translations not updated, or a non-English page updated and not copied back to the English page (in any language). I'd encourage people to copy between the pages even if they just mark the text as needing translating. Regards, Rob [1] You could also copy it to other language pages, but at a bare minimum the English page as this is considered the Main page/OSM's default language. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Drones
On Thu, Jul 24, 2014 at 8:54 AM, Jóhannes Birgir Jensson j...@betra.is wrote: I'm curious to know if any OSM groups are currently running their own drones for imagery. In Iceland we have been looking longingly at the eBee https://www.sensefly.com/drones/ebee.html but so far haven't started fundraising for it. Are there similarly sophisticated yet cheaper options around and currently in use? Haven't flown any...yet, but think it has real possibilities to help map. Satellite imagery always seems out of date or cloud covered. Being able to capture new buildings using drones seem like a good fit. I have seen 3D modeling using images taken from quadcopters. The possibilities of what can be done with open source software are pretty amazing. We are going to have a demo of aerial imagery using kits at an upcoming OSM 10th Anniversary event in Seattle. That is weather permitting. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
Using the same Wiki with language namespacing implements the concept of very close translations - the structure is the same for everyone, and the translator is just expected to fill in the blanks. I don't believe that this will lead to high-quality documentation; I believe this will be at best a little better than automatic translation. But that concept is not really reality. There a dozen for German pages which are completely different from the English one, but both cover that topic in a way that is usefull for people who get to that page. The main advantage I see with keeping everything in one Wiki is that it is a lot easier to find tagging or translation mistakes. Often when I am going to translate an article, I try to improve it, but because the english article is considered the main one, I end up having to improve the english article as well. This can be a big productivity killer. Completely agree with you. As pointed out in the other mail the issue is not just translation, but documentation in the first place. I just tried to translate all the craft= pages, but bascially I have to fix the template on the English page first every time. For vending= which I did before I bacially had to create every single page. I have to say that it wasn't intuitive to understand that, linking to other wiki page from a page in portuguese will link to an english page unless I stick a Pt: prefix before it. On the one hand that's bad on the other hand it's also an advantage, because I bet most of the time the portuguese page does not exist, so forcing a create page would be worse. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki translate extension
If there is country specific information about a tag then I would like to be aware of it, as it could be useful for other countries/languages too. And if I open a DE:feature I would like to be presentet with the information relevant to my country in the first place. If I open DE:bicycle_something then I don't want to be presented with various signs that are used in the US, South Africa, Japan or Mexico. I want to see the sign that I saw on the ground in Germany and then how to tag it. So I want to see these signs: https://commons.wikimedia.org/wiki/Category:Cycling_signs_in_Germany And not these: http://www.trafficsign.us/bikesign.html If you want country relevant information on every translation then you do have to look though a dozen different signs 99.99% of the people reading that page are never goingto use. And those are sign that are easy to spot. Now make that text... That could be as simple as copying it to the English language page (marking it as requiring translation) or if it's longer providing a link on the English language page. You are still going to present me with a lot of information that is not usefull for my country. And it will get worse once you try to translate non-English pages back. From German to Englisch you are then going to get funny stuff like [PLEASE DON'T CONFUSE evangelical with evangelical!!!] __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Drones
Sometime I think, it wolud be nice to start with developing of our own aplication for capturing of: 1. Aerial images 2. Terrain model information 3. 3D information about buildings We have enoug knowdlege in the cloud to do it. What we need is one or 2 universities for staering the develepment and (probably) crowd funding for getting it open source. I can write mockup for such solution. BR, Marek Kleciak Dnia 25 lipca 2014 2:24 Clifford Snow napisał(a): On Thu, Jul 24, 2014 at 8:54 AM, Jóhannes Birgir Jensson lt;j...@betra.isgt; wrote:I'm curious to know if any OSM groups are currently running their own drones for imagery. In Iceland we have been looking longingly at the eBee https://www.sensefly.com/drones/ebee.html but so far haven't started fundraising for it. Are there similarly sophisticated yet cheaper options around and currently in use? Haven't flown any...yet, but think it has real possibilities to help map. Satellite imagery always seems out of date or cloud covered. Being able to capture new buildings using drones seem like a good fit. I have seen 3D modeling using images taken from quadcopters. The possibilities of what can be done with open source software are pretty amazing. We are going to have a demo of aerial imagery using kits at an upcoming OSM 10th Anniversary event in Seattle. That is weather permitting. Clifford --@osm_seattleosm_seattle.snowandsnow.usOpenStreetMap: Maps with a human touch___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] BR-101 no RS
Veja foto anexado, BR-101 no Rio Grande do Sul parecendo um freeway tipo Autobahn no alemanha, nao ha estradas com velocidade livre no Brasil. Algum preciso verificar os classificacoes e o uso do maxspeed, calculando roteamento com 250kph no Brasil nao e bom, e nem tenho carro que posso andar tao rapido (sim quero compra um McLaren) Aun Johnsen Sent from my iPhone___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-101 no RS
Aun, recomendo usar para seus testes mapas compilados por brasileiros para brasileiros: http://www.cocardl.com.br/viewtopic.php?f=52t=214 Esses mapas compilados por outros sites, a maioria europeus, apresentam problemas. Não recomendo para testes. Outro dia eu mandei para o pessoal do AlternativaLibres o trecho do nosso style/address que faz o devido tratamento do prefixo do tipo do logradouro para flexibilizar a busca, ex.: o usuário não é obrigado a digitar Avenida sempre, só se ele quiser. Outro aspecto que damos atenção é o tratamento das velocidades. Em 24 de julho de 2014 08:25, Aun Johnsen li...@gimnechiske.org escreveu: Veja foto anexado, BR-101 no Rio Grande do Sul parecendo um freeway tipo Autobahn no alemanha, nao ha estradas com velocidade livre no Brasil. Algum preciso verificar os classificacoes e o uso do maxspeed, calculando roteamento com 250kph no Brasil nao e bom, e nem tenho carro que posso andar tao rapido (sim quero compra um McLaren) Aun Johnsen Sent from my iPhone ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prefeitura de São Paulo declara bases sem restrição de licença
Nunca assisti o filme. Em Eu sou a Lei! - A história do Juiz Dredd http://filmesegames.com.br/2012/eu-sou-a-lei-a-historia-do-juiz-dredd/, eu leio: Dredd é conhecido por sua obsessão pela lei, a tal ponto de ser considerado por aqueles que o conhecem como uma verdadeira máquina, desprovido de humanidade, ética ou compaixão. Para ele, não há limites que o impeçam de cumprir suas missões. Conhecedor de todos os estatutos legais e com consciência de que todo crime merece punição, Dredd continua no encalço dos malfeitores. Dentre outras coisas. Se você não disser, eu nunca vou saber qual parte faz você confrontar o Dredd comigo ou com outro. É muita coisa que caracteriza-o, e certamente várias delas podem não ter qualquer semelhança com características minhas. Mas as pessoas são livres para interpretar outras como conseguirem... Talvez fosse mais próximo do acerto você ter me chamado de um pedagogo arrogante, que pretende ensinar os outros como devem ser algumas coisas. Pedagogos, todos nós queremos ser em algum momento, com técnicas eficazes ou não, mais ou menos eficientes. Quanto a descobrir se alguém está sendo arrogante, a questão sempre se enraíza naquelas outras, filosóficas, de se existe verdade, se ela é alcançável, ou mesmo se um indivíduo deve abraçar convenções (tais como leis). Alexandre Magno Em 22 de julho de 2014 14:22, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Não lembro do filme. Paulo, por favor, diga de outra forma, para eu saber o que você está dizendo. Em 22 de julho de 2014 12:42, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Agora tu fizeste me lembrar do filme do Juiz Dredd: Eu sou a lei! kk Em 22 de julho de 2014 07:49, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Seria mais uma dificuldade para educar importadores ilícitos sem consciência: Se eles podem fazer isso, eu também posso. E essa estória de permissões para esses dados que estou colocando é uma besteira. Daí a pessoa vai lá e importa seus dados privativos quebrando logo o histórico, para começar. Em 22 de julho de 2014 02:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Sim, por isso chamei de sub-ideal. O ideal é que não degrademos o histórico nunca. Mas acho que a gente deveria considerar os prós e contras de quebrar os históricos com o objetivo de disponibilizar os dados mais rapidamente. Afinal, são muitos dados e pouca mão de obra. 2014-07-21 10:42 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Mas degrada o histórico de versões. Quero dizer: pode ficar difícil conectar logicamente o objeto antigo com o novo. Em 19 de julho de 2014 12:22, Fernando Trebien fernando.treb...@gmail.com escreveu: Um subideal (que talvez seja possível, dependendo dos interesses da comunidade) é sim excluir coisas do OSM e depois reintroduzir aquilo que foi excluído e que não consta no novo dataset. Na verdade, eu acho essa uma abordagem muito mais rápida quando a fonte de dados é muito mais rica do que o OSM. Também é uma abordagem que evita os problemas da conflação. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: deleçao de vias sem justificativa
Eu monitorando changesets no ES atravez RSS, quando chegar em casa posso manda o site que criando estes, ele me avisar todos changesets dentro do BBOX, no meu caso criei um BBOX pra todo estado Ele nao me avisando se nao have nenhum mudança dentro BBOX, mesmo se meu area e dentro changeset O menus e se fique offline ele so me dar os 10 ultimos :( nao dar pedir mais Aun Johnsen Sent from my iPhone On 24. juli 2014, at 09:43, Gerald Weber gwebe...@gmail.com wrote: Eu estranhei a reação deste usuário. Parece que inicialmente estava fazendo um trabalho sério, mas posso estar enganado. Sinto falta de alguma ferramenta mais eficiente para verificar edições. Para um sistema tão aberto como o OSM é tudo manual demais. abraço Gerald 2014-07-24 9:33 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-07-24 9:05 GMT-03:00 Gerald Weber gwebe...@gmail.com: precisamos reverter as edições e solicitar a suspensão deste usuário. Alguém me ajuda a fazer isto? Vamos ver. (e só um desabafo, mas outra coisa que me deixa puto é o iD gerar um changeset para cada coisa que o usuário salva. 912 changesets em 4 meses... Só é trabalho para a gente verificar depois) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: deleçao de vias sem justificativa
Ele pode ter rido apenas da sua seriedade. Sua abordagem foi objetiva, completa e SÉRIA. Infelizmente tem gente assim, que ri quando a pessoa leva algo a sério. Em 24 de julho de 2014 09:43, Gerald Weber gwebe...@gmail.com escreveu: Eu estranhei a reação deste usuário. Parece que inicialmente estava fazendo um trabalho sério, mas posso estar enganado. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: deleçao de vias sem justificativa
Ainda mais se for um mapazinho (mais um projeto de desocupados) gratuito e irrelevante, onde todo mundo mete a mão. Não é assim que eu penso, mas eu conheço pessoas que pensam assim. Em 24 de julho de 2014 10:08, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Ele pode ter rido apenas da sua seriedade. Sua abordagem foi objetiva, completa e SÉRIA. Infelizmente tem gente assim, que ri quando a pessoa leva algo a sério. Em 24 de julho de 2014 09:43, Gerald Weber gwebe...@gmail.com escreveu: Eu estranhei a reação deste usuário. Parece que inicialmente estava fazendo um trabalho sério, mas posso estar enganado. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é
Re: [Talk-br] BR-101 no RS
O melhor seria mapear a etiqueta maxspeed. Assim todos os sistemas (não apenas a compilação da Cocar) funcionariam corretamente nesse trecho. E ela está faltando em alguns trechos da BR-101 (vou resolver no RS): http://www.itoworld.com/map/125?lon=-50.49460lat=-29.41505zoom=8 Quanto à classificação, está correta conforme os critérios com da comunidade brasileira, que são diferentes dos da comunidade alemã. Lá se usa motorway apenas para autobahns, aqui podemos ter motorways cuja velocidade máxima é 80km/h. (Há mais de 1 ano, antes de todo o debate, eu só queria chamar de motorways as vias cuja velocidade máxima fosse acima desse patamar. A BR-101 seria uma motorway mesmo assim porque o limite de velocidade é 110km/h.) 2014-07-24 8:53 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aun, recomendo usar para seus testes mapas compilados por brasileiros para brasileiros: http://www.cocardl.com.br/viewtopic.php?f=52t=214 Esses mapas compilados por outros sites, a maioria europeus, apresentam problemas. Não recomendo para testes. Outro dia eu mandei para o pessoal do AlternativaLibres o trecho do nosso style/address que faz o devido tratamento do prefixo do tipo do logradouro para flexibilizar a busca, ex.: o usuário não é obrigado a digitar Avenida sempre, só se ele quiser. Outro aspecto que damos atenção é o tratamento das velocidades. Em 24 de julho de 2014 08:25, Aun Johnsen li...@gimnechiske.org escreveu: Veja foto anexado, BR-101 no Rio Grande do Sul parecendo um freeway tipo Autobahn no alemanha, nao ha estradas com velocidade livre no Brasil. Algum preciso verificar os classificacoes e o uso do maxspeed, calculando roteamento com 250kph no Brasil nao e bom, e nem tenho carro que posso andar tao rapido (sim quero compra um McLaren) Aun Johnsen Sent from my iPhone ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: deleçao de vias sem justificativa
Em 2014-07-24 09:43, Gerald Weber escreveu: Eu estranhei a reação deste usuário. Parece que inicialmente estava fazendo um trabalho sério, mas posso estar enganado. Sinto falta de alguma ferramenta mais eficiente para verificar edições. Para um sistema tão aberto como o OSM é tudo manual demais. Essa ferramenta foi lançada recentemente e me agradou bastante: http://nrenner.github.io/achavi/ abraços, wille abraço Gerald 2014-07-24 9:33 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-07-24 9:05 GMT-03:00 Gerald Weber gwebe...@gmail.com: precisamos reverter as edições e solicitar a suspensão deste usuário. Alguém me ajuda a fazer isto? Vamos ver. (e só um desabafo, mas outra coisa que me deixa puto é o iD gerar um changeset para cada coisa que o usuário salva. 912 changesets em 4 meses... Só é trabalho para a gente verificar depois) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- wille http://wille.blog.br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Bem, não vamos fugir do assunto original, eu só mencionei a limitação do Garmin porque achei que usar um POI ao invés de um nome de rua facilitaria o teste que eu sugeri. Não era uma crítica ao Garmin, mas eu realmente acho estranho que não se possa fazer com ele algo que eu fazia/faço com todos os outros GPSs que eu já usei: buscar por POIs dentro de uma cidade sem estar fisicamente próximo dela. 2014-07-24 11:41 GMT-03:00 Aun Johnsen li...@gimnechiske.org: Fernando Concegui busca por POI, mas alem do ~85 km (tenque verificar) somente pelo nome, e se ha mais que um com mesma nome so retorna o mais perto (pelo menus no meu Nüvi 50), ele nao busco pelo nome proximente, alas Guanabara nao vai retornar Windsor Guanabara, mas Windsor G pode da certo Aun Johnsen Sent from my iPhone On 24. juli 2014, at 11:06, Fernando Trebien fernando.treb...@gmail.com wrote: Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Fernando, bem Nuvi 50 e um modelo antiga, nao tem modelo mais recente, ver que Garmin Nüvi 53 vender por 399 no Lojas Americanas Aun Johnsen Sent from my iPhone On 24. juli 2014, at 12:28, Fernando Trebien fernando.treb...@gmail.com wrote: Bem, não vamos fugir do assunto original, eu só mencionei a limitação do Garmin porque achei que usar um POI ao invés de um nome de rua facilitaria o teste que eu sugeri. Não era uma crítica ao Garmin, mas eu realmente acho estranho que não se possa fazer com ele algo que eu fazia/faço com todos os outros GPSs que eu já usei: buscar por POIs dentro de uma cidade sem estar fisicamente próximo dela. 2014-07-24 11:41 GMT-03:00 Aun Johnsen li...@gimnechiske.org: Fernando Concegui busca por POI, mas alem do ~85 km (tenque verificar) somente pelo nome, e se ha mais que um com mesma nome so retorna o mais perto (pelo menus no meu Nüvi 50), ele nao busco pelo nome proximente, alas Guanabara nao vai retornar Windsor Guanabara, mas Windsor G pode da certo Aun Johnsen Sent from my iPhone On 24. juli 2014, at 11:06, Fernando Trebien fernando.treb...@gmail.com wrote: Eu não tenho um Garmin, e a informação que eu tinha é que ele não faz busca por ponto de interesse (que seria uma opção mais fácil pra esse teste do que buscar por cruzamentos). On 24 Jul 2014 08:44, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Sò uma observação quando tu disseste (requisito do geocoding do Garmin): Isso não é limitação da Garmin, mas sim dos mapas ou da compilação. Meu bairro está 100% numerado e o mapa Garmin dele no Cocar tem a numeração toda. Quem quiser estão aqui: http://www.cocardl.com.br/viewtopic.php?f=52t=139 A compilação deles é cortesia do Wesley Martins (não sei se ele participa desta lista). Há também os mapas do Brasil e América do Sul, cortesia do Márcio Thundercel: http://www.cocardl.com.br/viewtopic.php?f=52t=214 e http://www.cocardl.com.br/viewtopic.php?f=52t=215 Há ainda também o mapa diário de São Paulo, cortesia do Nelson (não sei que toolset ele usa): http://naoliv.iq.unesp.br/mapas/gmapsupp.img E ainda quem quiser, baixe os kits de compilação e compile seu próprio mapa Garmin: http://www.cocardl.com.br/viewtopic.php?f=23t=114 Em 20 de julho de 2014 22:00, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de
Re: [Talk-br] Maproulette
Como seria isso? Região predefinida ou para o Brasil todo? Eu topo. Em 24-07-2014 13:06, Arlindo Pereira escreveu: Que tal criarmos um desafio para copiar o nome de ruas sem nome do mapa do IBGE? []s Arlindo 2014-07-24 12:57 GMT-03:00 John Packer john.pack...@gmail.com mailto:john.pack...@gmail.com: Vitor, Para criar um desafio e colocar no MapRoulette, é preciso entrar em contato com os desenvolvedores (um deles é o mvexel[1]). Até onde eu saiba, no momento não tem nenhum desafio ativo no Brasil. Foi feita uma apresentação na SOTM-EU com mais detalhes[2]. [1]: http://www.openstreetmap.org/user/mvexel [2]: http://sotm-eu.org/en/slots/39 Em 24 de julho de 2014 12:38, Vitor George vitor.geo...@gmail.com mailto:vitor.geo...@gmail.com escreveu: Não entendi muito bem como usar o MapRoulette. Queria criar um desafio de completar nomes de ruas em uma região, há como fazer? On Tue, Jul 22, 2014 at 4:56 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com mailto:erickdeoliveiral...@gmail.com wrote: De acordo com esta nota http://www.openstreetmap.org/user/mvexel/diary/23374 o Maproulette agora permite que você crie um limite da área onde ele encontra os erros. ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] Treppen-Renderer: Aufruf zum Sammeln außergewöhnlicher Exemplare!
Hallo zusammen! Beim mappen der sichelförmigen Treppe an der Lanxess Arena [1] wäre ich hinterher froh gewesen, wenn ein Tool mir anschließend visuelles Feedback gegeben hätte. User Marek_kleciak plant durch einen Studenten einen entsprechenden Renderer schreiben zu lassen, der Eigenschaften von [2] versteht. Ich bin gespannt. Hier nun der Aufruf für diesen Treppen-Renderer zunächst einmal eine Datensammlung für außergewöhnliche und exotische Treppenanlagen anzulegen. Tragt eure Treppen unter [3] ein. Vielen Dank!! Viele Grüße aus Köln Johannes [1] https://lists.openstreetmap.org/pipermail/talk-de/2014-July/108942.html [2] https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling [3] https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling/demo_collection signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 209 15.7.–21.7.2014
Am 23. Juli 2014 22:07 schrieb Michael Reichert naka...@gmx.net: die Wochennotiz Nr. 209 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/ … -nr-209-2/ ist nur bei mir der Link nicht richtig angekommen? Hier vollständig: http://blog.openstreetmap.de/blog/2014/07/wochennotiz-nr-209-2/ Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] BreBeMi inaugurata
2014-07-24 0:22 GMT+02:00 sabas88 saba...@gmail.com: Ho controllato prima, sembrerebbe già stata inaugurata ieri su OSM :-) http://www.openstreetmap.org/changeset/24291476 Siam più veloci delle autorità! :-) Ciao, Stefano PS Off topic ma inerente agli anticipi sull'inaugurazione ufficiale http://genova.mentelocale.it/60002-genova-piazza-don-andrea-gallo-subito-open-street-map/ conosci chi ha scritto l'articolo? Open Street Map si scrive attaccato :-P -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
Il giorno 24 luglio 2014 08:42, Luca Delucchi lucadel...@gmail.com ha scritto: conosci chi ha scritto l'articolo? Open Street Map si scrive attaccato :-P Anch'io l'ho sempre visto scrivere staccato dai giornalisti. Riusciamo abbastanza a far capire il concetto della mappa aperta (soprattutto se diciamo a differenza di Google :-D ), ma sull'ortografia c'è ancora da lavorare! :-D Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
Il giorno 24 luglio 2014 09:30, Simone Saviolo simone.savi...@gmail.com ha scritto: Il giorno 24 luglio 2014 08:42, Luca Delucchi lucadel...@gmail.com ha scritto: conosci chi ha scritto l'articolo? Open Street Map si scrive attaccato :-P Anch'io l'ho sempre visto scrivere staccato dai giornalisti. Riusciamo abbastanza a far capire il concetto della mappa aperta (soprattutto se diciamo a differenza di Google :-D ), ma sull'ortografia c'è ancora da lavorare! :-D Belin precisini! Ho chiesto ad un possibile contatto intermedio di passare l'informazione :-) Ciao, Simone Ciao, Stefano ___ 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] Mapcss e nodi estremi di una way
Il 07/21/2014 11:02 PM, emmexx scrisse: Vorrei evidenziare i nodi estremi di una way. Per il 1° nodo c'e' un esempio nel wiki, basta usare qualcosa come way[highway] [index=1] node Ok anche per i successivi ma come faccio ad individuare l'ultimo nodo? Ho provato i vari last, 0, -1 ma non funzionano. Per i posteri: ho aperto una segnalazione sul sito di josm e mi e' stato risposto che al momento non e' possibile. Ho inventato una possibile soluzione che consiste nel duplicare il layer, invertire nel secondo layer tutte le way ed applicare 2 regole diverse con mapcss. Ma non e' esattamente comodo per lo scopo che mi prefiggevo, cioe' individuare way non connesse. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
http://osrm.at/8Du Qualcosa mi dice che c'è qualcosina da mettere a posto. O forse è solo OSRM a non usare dati aggiornati? Provo a darci un'occhiata. Ciao! Carlo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
2014-07-24 22:44 GMT+02:00 Carlo Stemberger carlo.stember...@gmail.com: http://osrm.at/8Du Qualcosa mi dice che c'è qualcosina da mettere a posto. O forse è solo OSRM a non usare dati aggiornati? Sono andato a dare un'occhiata ed ho trovato una cosa strana. In alcuni svincoli fa fare dei giri strani, come se ci fossere dei sensi unici dove non devono esserci. Ho aperto con JOSM ed ho trovato che in parecchie vie (ad esempio way 244592124 e way 245418999 ) vengono disegnate le freccette del senso unico anche se non c'è il tag oneway. Sapete da cosa dipende ciò? e soprattuto vedete anche voi allo stesso modo. Io ho fatto alcune prove e sembra che dipenda da highway=motorway_link (nel senso che se c'è un altro valore non si vedono le freccette). Sono andato a vedere altri casi simili e in tutti i casi ho trovato che p stato messo espllicitamente oneway=no. C'è qualcuno che ha deciso che highway=motorway_link implicha oneway=yes ? AnyFile ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
Il giorno gio, 24/07/2014 alle 23.31 +0200, Any File ha scritto: Sono andato a dare un'occhiata ed ho trovato una cosa strana. In alcuni svincoli fa fare dei giri strani, come se ci fossere dei sensi unici dove non devono esserci. Ho aperto con JOSM ed ho trovato che in parecchie vie (ad esempio way 244592124 e way 245418999 ) vengono disegnate le freccette del senso unico anche se non c'è il tag oneway. Sapete da cosa dipende ciò? e soprattuto vedete anche voi allo stesso modo. Io ho fatto alcune prove e sembra che dipenda da highway=motorway_link (nel senso che se c'è un altro valore non si vedono le freccette). Sono andato a vedere altri casi simili e in tutti i casi ho trovato che p stato messo espllicitamente oneway=no. C'è qualcuno che ha deciso che highway=motorway_link implicha oneway=yes ? Si, è così per le motorway. Va messo oneway=no se non è a senso unico Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] BreBeMi inaugurata
Am 24/lug/2014 um 23:31 schrieb Any File anysomef...@gmail.com: C'è qualcuno che ha deciso che highway=motorway_link implicha oneway=yes ? si, credo per lo più si presume senso unico anche per i link ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-se] Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm
Hej! Jag har tyvärr inte fått några svar så jag har bestämt mig för att ställa in evenemanget i morgon. Jag hjälper gärna till att som volontär ordna HOT-evenemang i Stockholm om det finns intresse. Hör gärna av er om ni har en bra idé eller intresse av att bjudas in. :-) Mvh, John - - - - John Andersson Wikimedia Sverige Project Manager Phone: +46(0)73-3965189 Email: john.anders...@wikimedia.se Skype: johnandersson86 Be sure to follow us on Twitter at @WikiEuropeana and @WikimediaSE Would you like to support free knowledge and Wikipedia? Please consider becoming a member of Wikimedia Sverige! We need your support. Subject: Fwd: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm From: karl.wet...@kodapan.se Date: Wed, 16 Jul 2014 15:52:58 +0200 CC: john.anders...@wikimedia.se To: talk-se@openstreetmap.org John söker någon som kan komma till Stockholm den 25:e juli och hjälpa HOT-nybörjare att kartera. Han är inte med på listan, så CC:a gärna honom eller svara privat, så slipper jag vidarebefodra! ; ) kalle Begin forwarded message: From: John Andersson john.anders...@wikimedia.se Subject: RE: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm Date: 16 Jul 2014 15:37:07 GMT+2 To: Karl Wettin karl.wet...@kodapan.se Cc: Joakim Fors joa...@fo.rs Hej! Det får ni gärna göra om ni inte kan! Om ni skulle vara intresserade av att besöka Stockholm så går det att söka ett minibidrag från oss på upp till 2 000 kronor! Mvh, John - - - - John Andersson Wikimedia Sverige Project Manager Phone: +46(0)73-3965189 Email: john.anders...@wikimedia.se Skype: johnandersson86 Be sure to follow us on Twitter at @WikiEuropeana and @WikimediaSE Would you like to support free knowledge and Wikipedia? Please consider becoming a member of Wikimedia Sverige! We need your support. Subject: Re: Möjligt Humanitarian OpenStreetMap Team-evenemang 25 juli i Sthlm From: karl.wet...@kodapan.se Date: Wed, 16 Jul 2014 15:27:18 +0200 CC: joa...@fo.rs To: john.anders...@wikimedia.se Hej John, både Joakim och jag är långt nere i Skåne och min misstanke är att han har lika få möjligheter som mig att ställa upp i Stockholm. Mitt bästa tips är att du går med på mejllistan https://lists.openstreetmap.org/listinfo/talk-se och ställer samma fråga där. Eller om du vill så kan jag vidarebefodra det här mejlet åt dig dit och be folk svara dig privat. kalle On 16 Jul 2014, at 14:57, John Andersson john.anders...@wikimedia.se wrote: Hejsan! Jag heter John och jobbar för Wikimedia Sverige, men skriver till er som volontär. Jag har de senaste månaderna börjat bidra lite smått på HOT, vilket jag tycker är ett helt fantastiskt projekt. Jag har tänkt att dra ihop ett litet evenemang runt det vid tillfälle och tänkte nu göra ett första försök. På HOT:s mailinglista gick nedanstående mail ut för några dagar sedan och jag tänkte att nu är det dags att ta tag i det hela. I korthet handlar det om att det i flera länder kommer att äga rum mapathon som fokuserar på att kartera Lesotho. Saken är dock den att jag själv inte är kunnig nog i OSM och HOT för att känna mig redo att hålla en presentation och lära andra hur man ska göra. Jag har dock förstått av mina kollegor att ni är väldigt kunniga och tänkte höra om ni båda eller någon av er vore intresserade av att vara med på evenemanget och lära mig och andra nybörjare hur man ska göra på bästa sätt? Jag tror att det skulle kunna bli riktigt trevligt! Jag kan då ordna lokalen och troligtvis fika/pizza/whatever samt kommunicera ut det i våra kanaler. Vad tror ni om detta? Vore det intressant? Med vänliga hälsningar, John - - - - John Andersson Wikimedia Sverige Project Manager Phone: +46(0)73-3965189 Email: john.anders...@wikimedia.se Skype: johnandersson86 Be sure to follow us on Twitter at @WikiEuropeana and @WikimediaSE Would you like to support free knowledge and Wikipedia? Please consider becoming a member of Wikimedia Sverige! We need your support. Hi Severin, To answer some of your questions.. - The TM jobs should be set up later this week - They will cover the bulk of the country. The center of Lesotho is mostly mountainous so there will likely be very few settlements to be mapped, but there will be rivers, streams roads. The rivers streams are important due to flooding / drought risks that exist in Lesotho. -
[Talk-es] Conclusiones tras la excursión a mapear Sopelana
Tras salir el pasado Jueves a mapear Sopela, hemos sacado algunas conclusiones que probablemente ya sabíais. - En primer lugar, las 11 personas que acudimos, nos dividimos en 4 recorridos y 4 tipos distinto de mapeadores: *DIR : Mapeador de calles, direcciones y accesos a edificios.* *EDI : Mapeador de tipos y formas de edificios.* *POI1 : Mapeador de Comercios y servicios.* *POI2 : Mapeador de mobiliario urbano.* - Antes de empezar a mapear, cada uno recibió una lista con los elementos que debía mapear y una lista de códigos resumiendo estos elementos. Todos los elementos se anotaron en forma de punto, aunque luego este punto tuviese que transformarse en un polígono (como en el caso de edificios). - Algunos tomaron los datos sobre papel y otros empleando tablets (Vespucci para POI1 y POI2 y KeyPadMapper para DIR y EDI). *Con KeyPadMapper se tomaron datos de entradas y calles (DIR) y se acordó un código mediante el cual también tomar los datos de los tipos, alturas y accesibilidad de los edificios.* *Con Vespucci se añadieron los POIs siguiendo el árbol de decisión que facilita determinar qué tipo de dato se refiere.* Las conclusiones generales son que las aplicaciones de *tablets*, en nuestro caso *han lastrado la toma de datos*. En nuestra opinión, ha resultado más sencillo para expertos y profanos en OSM mapear sobre papel. Además, debido a que una vez recogidos en la tablet, es necesario pasar por JOSM para adecuarlos y eliminar duplicidades, se requiere el mismo tiempo (o incluso menos) y es más sencillo para personas no expertas en OSM crear los elementos desde cero, consultando el papel, que solucionar conflictos entre la capa existente y la recogida en la tablet. Tampoco os quiero aburrir con lo que hicimos, pero si alguno está interesado en qué códigos usamos o en qué elementos nos centramos, os podemos contar todo. Los datos aún no están subidos, pero poco a poco mi pueblo ( http://www.openstreetmap.org/#map=18/43.38004/-2.98023) lo veréis llenarse de elementos. Saludos. -- Ander Pijoan Lamas Research Assistant, Deustotech Computer Science Engineer University of Deusto E-mail: ander.pij...@deusto.es Phone: +34 664471228 in: http://www.linkedin.com/profile/view?id=162888312 ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
[OSM-Talk-ZA] Fwd: [Wikimedia-GH] Map4Ebola on OpenStreetMap
fyi -- Weitergeleitete Nachricht -- Von: rupert THURNER rupert.thur...@gmail.com Datum: 24.07.2014 20:20 Betreff: Fwd: [Wikimedia-GH] Map4Ebola on OpenStreetMap An: wikimediac...@lists.wikimedia.org wikimediac...@lists.wikimedia.org here a link where the icrc tries to get help mapping crisis regions. rupert -- Weitergeleitete Nachricht -- Von: Enock Seth Nyamador kwadzo...@gmail.com Datum: 23.07.2014 18:05 Betreff: [Wikimedia-GH] Map4Ebola on OpenStreetMap An: Planning Wikimedia Ghana Chapter wikimedia...@lists.wikimedia.org Hello Guys, I hope we all here know about the Ebola virus outbreak. Is becoming very serious, one of the top doctors just contracted http://af.reuters.com/article/topNews/idAFKBN0FS10V20140723 the virus as well. If you have some free time to spare, why not do this? What can you and I do to help? Tracing a building alone can help the Red Cross and MSF personnel's deployed since this is the map loaded onto GPS devices they use for navigating. If you need any help on how to map first just read the beginner guides here learnosm.org and then feel free to ask myself OR HOT http://www.hotosm.org/ mailing list any question related to this. All mapping tasks relating to Ebola can be found here http://tasks.hotosm.org/ Best, - Enock ___ Wikimedia-GH mailing list wikimedia...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-gh ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
Re: [OSM-Talk-ZA] Fwd: [Wikimedia-GH] Map4Ebola on OpenStreetMap
Thanks Rupert for forwarding. - Enock On Jul 24, 2014 6:23 PM, rupert THURNER rupert.thur...@gmail.com wrote: fyi -- Weitergeleitete Nachricht -- Von: rupert THURNER rupert.thur...@gmail.com Datum: 24.07.2014 20:20 Betreff: Fwd: [Wikimedia-GH] Map4Ebola on OpenStreetMap An: wikimediac...@lists.wikimedia.org wikimediac...@lists.wikimedia.org here a link where the icrc tries to get help mapping crisis regions. rupert -- Weitergeleitete Nachricht -- Von: Enock Seth Nyamador kwadzo...@gmail.com Datum: 23.07.2014 18:05 Betreff: [Wikimedia-GH] Map4Ebola on OpenStreetMap An: Planning Wikimedia Ghana Chapter wikimedia...@lists.wikimedia.org Hello Guys, I hope we all here know about the Ebola virus outbreak. Is becoming very serious, one of the top doctors just contracted http://af.reuters.com/article/topNews/idAFKBN0FS10V20140723 the virus as well. If you have some free time to spare, why not do this? What can you and I do to help? Tracing a building alone can help the Red Cross and MSF personnel's deployed since this is the map loaded onto GPS devices they use for navigating. If you need any help on how to map first just read the beginner guides here learnosm.org and then feel free to ask myself OR HOT http://www.hotosm.org/ mailing list any question related to this. All mapping tasks relating to Ebola can be found here http://tasks.hotosm.org/ Best, - Enock ___ Wikimedia-GH mailing list wikimedia...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-gh ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
[Talk-lv] smukaa aluuksne
oho. pamaniiju, cik skaisti aluuksne saziimeeta http://www.openstreetmap.org/#map=14/57.4230/27.0513 paldies :) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [OSM-talk-fr] Osmose, BANO et Numérotation des lieux-dits
Le 23/07/2014 23:44, Frédéric Rodrigo a écrit : Le 23/07/2014 11:06, lenny a écrit : Bonjour, dans la discussion suivante : https://www.mail-archive.com/talk-fr@openstreetmap.org/msg68212.html il était indiqué que BANO allait évoluer pour prendre en compte les lieux-dits ; ne faudrait-il pas également faire évoluer osmose pour qu'il ne renvoie pas une erreur lorsque addr:place existe : http://osmose.openstreetmap.fr/fr/map/#zoom=18lat=48.424788lon=-1.250867layer=Mapnikoverlays=FFFTitem=2060level=1%2C2%2C3tags=fixable=bbox=-1.2562286853790283%2C48.423056430500864%2C-1.245424747467041%2C48.42665186614596 Je viens de le prendre en compte pour cette erreur en particulier et pour les doublons de numéro. Résultats d'analyses disponibles sur osmose d'ici quelque jours. Frédéric. merci pour ta réponse. osmose est vraiment un sacré outil Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aires de covoiturage
park_ride c'est autre chose, non ? Ce ne sont pas les parkings proche de transports en commun... Le 24 juillet 2014 00:07, Tetsuo Shima tets...@gmail.com a écrit : Moi je tagge les parking destinés au covoiturage - ou seulement autorisé - amenity=parking et park_ride http://wiki.openstreetmap.org/wiki/Key:park_ride=yes Le 23 juillet 2014 18:43, Gwen ping...@no-log.org a écrit : bonjour Le 21/07/2014 14:32, Romain MEHUT a écrit : Ces aires sont avant-tout des parkings. Elles ont une signalétique indiquant qu'elles sont destinées aux covoitureurs mais rien n'empêchent de s'y stationner comme n'importe quel autre parking. Effectivement, sur l'espace public, seuls les véhicules bénéficiant du label autopartage peuvent bénéficier d'emplacements de stationnement réservés (article L2213-2 du code des collectivités ) http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI22495442cidTexte=LEGITEXT06070633 Les panneaux aire de covoiturage présent sur des parking construits sur l'espace public sont juste là à titre incitatif. J'ai appris cela en parcourant ce guide consacré à l'aménagement des aires de covoiturage en Basse-Normandie (il date de 2010) : http://aides.region-basse-normandie.fr/index.php/component/docman/doc_download/278-covoiturage-notice-pdf.pdf Gwen ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aires de covoiturage
Oui, le wiki indique bien que c'est à utiliser pour les parcs relais http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking#Attributs. Francescu Le 24 juillet 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : park_ride c'est autre chose, non ? Ce ne sont pas les parkings proche de transports en commun... Le 24 juillet 2014 00:07, Tetsuo Shima tets...@gmail.com a écrit : Moi je tagge les parking destinés au covoiturage - ou seulement autorisé - amenity=parking et park_ride http://wiki.openstreetmap.org/wiki/Key:park_ride=yes Le 23 juillet 2014 18:43, Gwen ping...@no-log.org a écrit : bonjour Le 21/07/2014 14:32, Romain MEHUT a écrit : Ces aires sont avant-tout des parkings. Elles ont une signalétique indiquant qu'elles sont destinées aux covoitureurs mais rien n'empêchent de s'y stationner comme n'importe quel autre parking. Effectivement, sur l'espace public, seuls les véhicules bénéficiant du label autopartage peuvent bénéficier d'emplacements de stationnement réservés (article L2213-2 du code des collectivités ) http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI22495442cidTexte=LEGITEXT06070633 Les panneaux aire de covoiturage présent sur des parking construits sur l'espace public sont juste là à titre incitatif. J'ai appris cela en parcourant ce guide consacré à l'aménagement des aires de covoiturage en Basse-Normandie (il date de 2010) : http://aides.region-basse-normandie.fr/index.php/component/docman/doc_download/278-covoiturage-notice-pdf.pdf Gwen ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aires de covoiturage
2014-07-21 14:32 GMT+02:00 Romain MEHUT romain.me...@gmail.com: Ces aires sont avant-tout des parkings. Elles ont une signalétique indiquant qu'elles sont destinées aux covoitureurs mais rien n'empêchent de s'y stationner comme n'importe quel autre parking. Je pense qu'au niveau des tags, il faudrait un nouveau tag access lorsque l'accès est restreint au covoiturage. Ca peut être aussi bien un parking ou une voie dédiée sur autoroute. Et un autre tag du genre des amenity pour les simples points de rendez-vous mais sans restrictions d'accès particulières. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aires de covoiturage
Le covoiturage est un transport en commun... sauf qu'il est pas public. P+R s'applique quasi a toutes les intermodalité voiture d'ailleurs aussi bien dans la vrai vie que dans OSM. Au Luxembourg et en Allemagne par exemple les parking dédié au covoiturage sont estampillé P+R, qu'ils intègrent une intermodalité voiture-voiture voiture-bus ou les deux. Le 24 juillet 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : park_ride c'est autre chose, non ? Ce ne sont pas les parkings proche de transports en commun... Le 24 juillet 2014 00:07, Tetsuo Shima tets...@gmail.com a écrit : Moi je tagge les parking destinés au covoiturage - ou seulement autorisé - amenity=parking et park_ride http://wiki.openstreetmap.org/wiki/Key:park_ride=yes Le 23 juillet 2014 18:43, Gwen ping...@no-log.org a écrit : bonjour Le 21/07/2014 14:32, Romain MEHUT a écrit : Ces aires sont avant-tout des parkings. Elles ont une signalétique indiquant qu'elles sont destinées aux covoitureurs mais rien n'empêchent de s'y stationner comme n'importe quel autre parking. Effectivement, sur l'espace public, seuls les véhicules bénéficiant du label autopartage peuvent bénéficier d'emplacements de stationnement réservés (article L2213-2 du code des collectivités ) http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI22495442cidTexte=LEGITEXT06070633 Les panneaux aire de covoiturage présent sur des parking construits sur l'espace public sont juste là à titre incitatif. J'ai appris cela en parcourant ce guide consacré à l'aménagement des aires de covoiturage en Basse-Normandie (il date de 2010) : http://aides.region-basse-normandie.fr/index.php/component/docman/doc_download/278-covoiturage-notice-pdf.pdf Gwen ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aires de covoiturage
Pour les acces réservé au covoiturage il faut chercher High Occupancy Vehicule http://wiki.openstreetmap.org/wiki/Key:hov Le 24 juillet 2014 12:56, Tetsuo Shima tets...@gmail.com a écrit : Le covoiturage est un transport en commun... sauf qu'il est pas public. P+R s'applique quasi a toutes les intermodalité voiture d'ailleurs aussi bien dans la vrai vie que dans OSM. Au Luxembourg et en Allemagne par exemple les parking dédié au covoiturage sont estampillé P+R, qu'ils intègrent une intermodalité voiture-voiture voiture-bus ou les deux. Le 24 juillet 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : park_ride c'est autre chose, non ? Ce ne sont pas les parkings proche de transports en commun... Le 24 juillet 2014 00:07, Tetsuo Shima tets...@gmail.com a écrit : Moi je tagge les parking destinés au covoiturage - ou seulement autorisé - amenity=parking et park_ride http://wiki.openstreetmap.org/wiki/Key:park_ride=yes Le 23 juillet 2014 18:43, Gwen ping...@no-log.org a écrit : bonjour Le 21/07/2014 14:32, Romain MEHUT a écrit : Ces aires sont avant-tout des parkings. Elles ont une signalétique indiquant qu'elles sont destinées aux covoitureurs mais rien n'empêchent de s'y stationner comme n'importe quel autre parking. Effectivement, sur l'espace public, seuls les véhicules bénéficiant du label autopartage peuvent bénéficier d'emplacements de stationnement réservés (article L2213-2 du code des collectivités ) http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI22495442cidTexte=LEGITEXT06070633 Les panneaux aire de covoiturage présent sur des parking construits sur l'espace public sont juste là à titre incitatif. J'ai appris cela en parcourant ce guide consacré à l'aménagement des aires de covoiturage en Basse-Normandie (il date de 2010) : http://aides.region-basse-normandie.fr/index.php/component/docman/doc_download/278-covoiturage-notice-pdf.pdf Gwen ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] A151 un peu courte au Nord ?
Bonjour , un habitant de Tôtes, ancien de l'IGN - et collègue - à qui je viens de montrer notre serveur de tuiles et BANO m'a signalé gentillement que l'A151 s'arrête un peu trop au Sud de Dieppe; effectivement on la voit catégorisée Bretelle d'Accès au dessus de son croisement avec l'A29 ; je laisse les spécialistes ajuster ?! Evidemment il a contribué à enrichir sa commune de résidence au passage ! -- Hugues ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A151 un peu courte au Nord ?
HParv a exposé le 24/07/2014 : Bonjour , un habitant de Tôtes, ancien de l'IGN - et collègue - à qui je viens de montrer notre serveur de tuiles et BANO m'a signalé gentillement que l'A151 s'arrête un peu trop au Sud de Dieppe; effectivement on la voit catégorisée Bretelle d'Accès au dessus de son croisement avec l'A29 ; je laisse les spécialistes ajuster ?! Evidemment il a contribué à enrichir sa commune de résidence au passage ! Bonjour, Sur OSM elle est catégorisée en Voie rapide (trunk) quand elle devient N 27 en passant la D 2. La carte IGN 1/25000 inscrit encore A 151 plus au nord entre Varneville et Tôtes mais Route 500 et les cartes IGN grandes échelles mettent bien que c'est la N 27 à cet endroit : http://tile.openstreetmap.fr/?zoom=14lat=49.64024lon=1.04514layers=B000TFF A moins que le prolongement (passage de la N 27 en autoroute), prévu de longue date, soit intervenu récemment ? Je penche plutôt pour une erreur de l'IGN au 1/25000 :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A151 un peu courte au Nord ?
Bonjour, que disent exactement les panneaux sur place ? parce que pour le coup si on compare avec ce qu'il y a sur d'autres cartes en ligne, tout le monde semble être d'accord pour dire que l'autoroute A151 se termine à la sortie 2 juste au sud de Varneville-Bretteville, et qu'il est prolongé par la N27 (trunk) ... Sylvain Le 24 juillet 2014 13:02, HParv talk-fr@rramuhn.org a écrit : Bonjour , un habitant de Tôtes, ancien de l'IGN - et collègue - à qui je viens de montrer notre serveur de tuiles et BANO m'a signalé gentillement que l'A151 s'arrête un peu trop au Sud de Dieppe; effectivement on la voit catégorisée Bretelle d'Accès au dessus de son croisement avec l'A29 ; je laisse les spécialistes ajuster ?! Evidemment il a contribué à enrichir sa commune de résidence au passage ! -- Hugues ___ 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] Osmose et wiki pas d'accord
Bonjour http://www.openstreetmap.org/way/116455022 C'est l'écluse du canal de Marans entre la mer (ou la Sèvre Niortaise plus exactement mais la marée remonte jusque là) et ce canal Dans le wiki http://wiki.openstreetmap.org/wiki/FR:Key:lock 3: landuse=basin waterway=lock Dans Osmose Tag conflict Conflict between tags waterway, landuse way 116455022 waterway = lock landuse = basin Qui a raison ? @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A151 un peu courte au Nord ?
Bel exemple ! LE TERRAIN, LE TERRAIN... ;) Le 24 juillet 2014 13:38, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Bonjour, que disent exactement les panneaux sur place ? parce que pour le coup si on compare avec ce qu'il y a sur d'autres cartes en ligne, tout le monde semble être d'accord pour dire que l'autoroute A151 se termine à la sortie 2 juste au sud de Varneville-Bretteville, et qu'il est prolongé par la N27 (trunk) ... Sylvain Le 24 juillet 2014 13:02, HParv talk-fr@rramuhn.org a écrit : Bonjour , un habitant de Tôtes, ancien de l'IGN - et collègue - à qui je viens de montrer notre serveur de tuiles et BANO m'a signalé gentillement que l'A151 s'arrête un peu trop au Sud de Dieppe; effectivement on la voit catégorisée Bretelle d'Accès au dessus de son croisement avec l'A29 ; je laisse les spécialistes ajuster ?! Evidemment il a contribué à enrichir sa commune de résidence au passage ! -- Hugues ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
Le wiki... Le 24 juillet 2014 13:59, Régis Bouguin regis.boug...@wanadoo.fr a écrit : Bonjour http://www.openstreetmap.org/way/116455022 C'est l'écluse du canal de Marans entre la mer (ou la Sèvre Niortaise plus exactement mais la marée remonte jusque là) et ce canal Dans le wiki http://wiki.openstreetmap.org/wiki/FR:Key:lock 3: landuse=basin waterway=lock Dans Osmose Tag conflict Conflict between tags waterway, landuse way 116455022 waterway = lock landuse = basin Qui a raison ? @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
2014-07-24 14:46 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Le wiki... Pas sûr. Il y a une différence entre le wiki anglais (qui fait référence) et sa version française: http://wiki.openstreetmap.org/wiki/Key:lock http://wiki.openstreetmap.org/wiki/FR:Key:lock Le polygone '3' est maintenant conseillé en natural=water + water=lock, ce qui plus logique qu'un landuse. Il est probable que le wiki français soit simplement en retard dans la traduction. y-a-pu-ka Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
J'aurai du mettre... la version anglaise du wiki ;) Le 24 juillet 2014 15:27, Pieren pier...@gmail.com a écrit : 2014-07-24 14:46 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Le wiki... Pas sûr. Il y a une différence entre le wiki anglais (qui fait référence) et sa version française: http://wiki.openstreetmap.org/wiki/Key:lock http://wiki.openstreetmap.org/wiki/FR:Key:lock Le polygone '3' est maintenant conseillé en natural=water + water=lock, ce qui plus logique qu'un landuse. Il est probable que le wiki français soit simplement en retard dans la traduction. y-a-pu-ka Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Le 17/07/2014 23:23, Francescu GAROBY a écrit : * le rendu étransport d'OSM est pour moi un contre-exemple tellement il est dégueu : une seule couleur (alors que nombre de lignes ont un tag 'colour' correspondant à la couleur attribuée par l'opérateur du réseau), pas de serpent (il s'agit de la façon de représenter les lignes empruntant la même voie : on trace toutes les lignes de couleur en parallèle) ; * une répétition anormalement élevée du nom de la ligne à certains niveaux de zoom (zooms 16 et supérieurs) et rien aux zooms inférieurs (le zoom 15 est vide, dans l'exemple que tu donnes). +1 Résumé de ma contribution qui suit : - 1er sujet : comment résoudre, avec simplicité et légèreté de données, l'intégration dans OSM des lignes de bus qui comportent une dizaine de variantes ? - 2e sujet : problématique du rendu actuel de la couche Transports, quand les girouettes de bus indiquent 4 lettres, et qu'une dizaine de références ou plus (à 4 lettres !) devraient en toute rigueur et exhaustivité coexister sur un même tronçon de rue. Également : difficultés qui en découleraient si le rendu se mettait à tracer en parallèle toute les routes existantes. - 3e sujet : proposition de solution, qui nécessite, soit d'abandonner les « route master », soit d'ajouter un étage de relation, avec des routes de bus élémentaires, qui ne serviraient que de briques pour assembler les vraies routes de bus. - À Belfort, on a depuis cette année des girouettes à 4 lettres sur les lignes suburbaines, pour distinguer les variantes de parcours et d'antennes : par exemple, pour la ligne D (qui représente presque un mini réseau à elle toute seule, mais avec la moitié en tronc commun : Gare TGV-entrée de Delle, cadencée à 20 mn) : DCFF, DGFF, DECI, DEBA, DEBO pour l'aller, les retours (aussi nombreux) étant réunis sous les deux girouettes DTGV et DTGM, ce qui fait au total 9 routes et 7 « ref » pour une seule ligne ! (une variante n'existe pas dans le sens retour). http://info.optymo.fr/media/com_infosvoyageurs/uploads/fiches/fiche_ligne_D.pdf Le problème au niveau du rendu, c'est que si je tague (je n'ai pas essayé, mais ça me semble évident) les 4 lettres dans la clé « ref », les 7 groupes de 4 lettres vont faire un beau bazar incompréhensible sur le rendu. Je me contente donc d'indiquer « D », ce qui fait d'ailleurs toujours autant de répétitions. - La ligne urbaine 3 n'est pas mal non plus au niveau variantes. Il y a un long tronc commun et deux antennes, desservies alternativement en temps normal. Sauf que l'été ou le soir, les deux antennes sont desservies successivement, le bus revenant rapidement à la fourche par la N 19 pour desservir la 2e antenne. On est déjà là avec 6 routes en présence, avec toutefois une unique girouette « 3 ». Là où ça se complique, c'est qu'il y a des parcours partiels, du côté terminus commun, les bus pouvant partir, non de Valdoie, mais seulement de Liberté, ou encore de IUT, et en plus, plusieurs bus dans la journée ne font qu'un quart de la ligne. Au final, je viens de compter, on a 12 routes différentes pour une seule ligne. hiver : http://info.optymo.fr/media/com_infosvoyageurs/uploads/fiches/fiche%20_ligne_3.pdf été : http://info.optymo.fr/media/com_infosvoyageurs/uploads/fiches/fiche_ligne_3.pdf En définitive, si je mappe tout ça, j'arrive à deux endroits du réseau à 20 ou 22 routes de bus : - sur 300 m de l'avenue du Général Leclerc, avec les 5 lignes du réseau urbain, dont la prolixe ligne 3, - près de la gare TGV, pour 400 m de D 119 avec 3 ronds-points (… non découpés, ndlr), où l'on n'a seulement les lignes 3, D et M ! === Il y a clairement un problème : soit on mappe « comme il faut », et on a 22 routes de bus sur certaines rues, soit on doit abandonner l'idée de mapper les lignes de bus complexes, et alors, au nom de quoi ? Et où placer la limite entre ce qui doit être mappé de ce qui doit être abandonné… ou simplifié de façon inexacte ? - Ma proposition qui allègerait bien les données en évitant ces redondances excessives : au lieu d'indiquer directement dans les tronçons de voirie les 22 routes de bus, je propose de créer des routes de bus élémentaires qui ne comportent que le parcours d'une bifurcation à l'autre du réseau de bus (donc plus qu'une seule route de bus par sens), et de mapper les routes de bus, non au niveau des tags de tronçons de voirie, mais dans une relation qui réunit les routes élémentaires. Le problème serait alors que les logiciels de rendu sachent exploiter ce procédé. Je me pose aussi la question de savoir comment taguer les lignes saisonnières… opening_hours, ça convient ? Désolé d'aborder autant de sujets dans un même mail, mais il y a un point commun, et qui rejoint la question des ronds points : décrire le complexe quand le système est prévu pour du simple. Muselaar ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
N'existerait-il pas une extension MediaWiki permettant de signaler que les pages locales sont plus anciennes que les pages anglaises ? Bien sur, cela ne garenti pas l'exacte similitude du contenu, mais permettrait au moins de s'y retrouver dans ce qu'il faut traduire de ce qui semble à jour. Des cas comme celui sont probablement légion. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 24 juillet 2014 16:00, Christian Quest cqu...@openstreetmap.fr a écrit : J'aurai du mettre... la version anglaise du wiki ;) Le 24 juillet 2014 15:27, Pieren pier...@gmail.com a écrit : 2014-07-24 14:46 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Le wiki... Pas sûr. Il y a une différence entre le wiki anglais (qui fait référence) et sa version française: http://wiki.openstreetmap.org/wiki/Key:lock http://wiki.openstreetmap.org/wiki/FR:Key:lock Le polygone '3' est maintenant conseillé en natural=water + water=lock, ce qui plus logique qu'un landuse. Il est probable que le wiki français soit simplement en retard dans la traduction. y-a-pu-ka Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les places (place de l'église, etc..)
Le 23/07/2014 18:53, Pieren a écrit : C'est aussi le cas avec les boulevards et avenues, par exemple (plusieurs filaires, espace large et ouvert, sert d'adresse). Va-t-on vers la création d'un tag place à chaque fois que plusieurs éléments constitutifs d'un lieu sont cartographiés dans OSM ? Tu as l'air contre l'idée de l'utilisation du tag place= pour les places. Mais est-ce que tu estimes aussi qu'il n'y a pas besoin d'un tag supplémentaire pour référencer leur emprise ? Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Par hasard, je viens de tomber sur le message ci-dessous qui n'est pas arrivé sur la ML. Je pense que c'est quelqu'un qui est inscrit sur nabble, mais pas sur la mailing-list, ce qui expliquerait pourquoi il est indiqué This post has NOT been accepted by the mailing list yet. : http://gis.19327.n5.nabble.com/Pourquoi-je-quitte-OSM-tp5810862p5812264.html = Je voudrais apporter quelques compléments sur l'origine du nom officiel de la commune de Vers : Les dénominations officielles successives ont été : XVIIIème siècle : la carte de Cassini indique « Ver » pour la localité est « la Celle » pour la rivière. 1793 : Vers-Hébécourt. (Convention Nationale an II) 1801 : Vers et Hébécourt. (Bulletin des Lois) XIXème siècle : la minute de levé de la carte de l’état-major reporte « Vers », le nom de la rivière est devenu « la Selle ». 1878 : Vers, à la suite de la création de la commune de Hébécourt. (Ministère de l’Intérieur) 1919 : Vers est renommée Vers-sur-Selles, très probablement pour la différencier des sept autres communes françaises se nommant Vers. « Selles » y est écrit avec un « s » final alors que la rivière est dénommée « la Selle », ce qui peut résulter d’une erreur de transcription faite à l’époque, officialisée alors par les services de l’État (ministère de l’intérieur à l’époque) et conservée ainsi depuis près d’un siècle. Ces éléments peuvent être versés à l’appui d’une demande que ferait le maire de Vers-sur-Selles conformément aux dispositions de l’article L. 2111-1 du code général des collectivités territoriales. Jean-sébastien Majka Unité de toponymie de l'IGN. = ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
Bonjour Le 24/07/2014 16:19, François Lacombe a écrit : N'existerait-il pas une extension MediaWiki permettant de signaler que les pages locales sont plus anciennes que les pages anglaises ? Il existe un principe, via une extension de Mediawiki qui, en sectionnant la page anglophone, propose à la traduction les sections dans les différentes langues. Un section non traduites ou obsolètes affichera automatiquement la section anglophones. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Je suis complètement d'accord pour ce niveau intermédiaire entre les chemins et les relations route qui symbolisent toutes les variations des lignes de transport en commun. J'ai une rue où j'ai mappé toutes les lignes qui rentrent en ville et j'arrive à 63 relations route pour 28 itinéraires. Il ya donc relativement peu de variations sur les lignes, mais il y a certainement bcp de lignes qui y passent, ce qui rend l'édition compliqué. J'ai déjà essayé de faire cet exercice pour un itinéraire: https://www.openstreetmap.org/relation/2336781/history#map=14/50.8655/4.6878 https://www.openstreetmap.org/relation/2336780/history#map=14/50.8653/4.6883 il y a 2 ans déjà, mais à l'époque OSM n'était pas prêt pour une solution tellement révolutionnaire. Même si pour les itinéraires de randonnée une telle solution a bien été adoptée. Malheureusement, je ne vois pas comment cela résoudrait notre différence d'opinion sur les rond-points. Jo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
Merci David. Aurais-tu le nom de cette extension ? Avoir ce genre d'outil aiderait franchement à la traduction et à sa maintenance après coup. Même si je veux y contribuer, je ne sais pas par où commencer :( *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 24 juillet 2014 16:47, David Crochet david.croc...@free.fr a écrit : Bonjour Le 24/07/2014 16:19, François Lacombe a écrit : N'existerait-il pas une extension MediaWiki permettant de signaler que les pages locales sont plus anciennes que les pages anglaises ? Il existe un principe, via une extension de Mediawiki qui, en sectionnant la page anglophone, propose à la traduction les sections dans les différentes langues. Un section non traduites ou obsolètes affichera automatiquement la section anglophones. Cordialement -- David Crochet ___ 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] Rencontre parisienne demain ?
Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne demain ?
Je suis dans les parages... mais rien d'annoncé pour demain soir. C'est un peu le désert Paris en ce moment ! Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
Bonjour Le 24/07/2014 16:55, François Lacombe a écrit : Aurais-tu le nom de cette extension ? https://www.mediawiki.org/wiki/Extension:Translate Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
2014-07-24 16:28 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr: Jean-sébastien Majka Unité de toponymie de l'IGN. Bien vu. Je vais envoyer le lien au maire de ce village. Avec un peu de chance, il pourrait monter un meilleur dossier pour faire valider sa version officiellement. Ca fait juste 95 ans que l'erreur n'est pas corrigée ! Alors si la communauté OSM peut aider à connecter les bonnes personnes ... En plus, on aura bientôt des nouveaux noms de régions ([1]), alors renommer un nom de village, ça serait peanuts ;-) [1] http://www.lefigaro.fr/politique/le-scan/2014/06/03/25001-20140603ARTFIG00285-quels-noms-pour-les-nouvelles-regions.php J'aime bien Poichenli pour Poitou-Charentes-Centre-Limousin. Ou Champicardenne pour Picardie-Champagne-Ardenne. mdr Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et wiki pas d'accord
Super :) Je vais pousser cela sur la liste internationale et fermons la parenthèse ;) *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com 2014-07-24 17:28 GMT+02:00 David Crochet david.croc...@free.fr: Bonjour Le 24/07/2014 16:55, François Lacombe a écrit : Aurais-tu le nom de cette extension ? https://www.mediawiki.org/wiki/Extension:Translate Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Sur la question du découpage des ronds-points, j'en suis venu à penser différemment (bien que j'avoue, j'en ai découpé quelques uns pour plus de clarté, mais tous les autres, non), il me semble à moi aussi maintenant que c'est uniquement un problème de rendu : Une solution élégante, et qui allègerait les données, serait de s'abstenir de taguer la route sur les ronds-points, et que la continuité soit reconnue par le fait que 2 nodes différents d'un même rond-point appartiennent à la même route. Je n'arrive pas à imaginer un cas où il pourrait y avoir ambiguité. La route serait alors d'office le parcours obligatoire d'un node à l'autre, étant donné le sens de circulation. Si l'on considère le rond-point comme un carrefour en un même et unique objet, il n'y aurait effectivement en toute logique aucune raison de le taguer, dans la mesure ou les nodes d'entrée et de sortie appartiennent au même carrefour. Un rond-point est un cas particulier de chemin, il n'est pas linéaire, mais circulaire, il revient sur lui-même, on ne peut pas lui appliquer les raisonnements adaptés aux autres chemins. Il y a bien sûr des cas particuliers dans lesquels un parcours peut débuter ou se terminer sur un rond-point, mais à mon sens, ça ne peut en aucun cas être le node d'entrée ou de sortie, mais seulement un node intermédiaire, ce qui n'interfèrerait pas avec ma proposition. Mais cette solution demanderait des adaptations logicielles. Qu'en disent les techniciens ? Pour ton exemple de routes « intermédiaires », je ne comprends pas exactement ce que tu as fait, étant donné que le rendu n'est actuellement pas apte à le prendre en compte... Tu as mis à la fois les chemins, les stops, et les plateformes, c'est ça ? Je ne pense pas que ce soit une bonne idée d'intégrer les arrêts à ces niveaux intermédiaires : d'une part, les arrêts peuvent être différents d'une ligne à l'autre (rien qu'à Belfort qui est une petite ville, il y a plusieurs exemples d'arrêts qui sont « sautés » par certaines lignes), d'autre part, les arrêts, que ce soit les stop_positions ou les plateformes, n'interfèrent quasiment pas avec le reste de la cartographie, donc cela ne crée pas de perturbation pour l'édition des autres usages. De plus, concernant le nombre élevé, je ne crois pas qu'un même point d'arrêt puisse être utilisé par 63 routes de bus, ça doit faire une sacrée queue de bus, et ils n'auraient pas le temps de s'arrêter. Dans mes deux exemples de 20 et 22 relations-routes, il n'y a aucun arrêt qui soit partagé par toutes les relations présentes sur la rue. Sur tout le réseau du Territoire de Belfort, ville comprise, je ne vois que 3 stop_positions (parce que 2 sens confondus) qui totalisent 14 ou 15 routes, et plusieurs autres 11 routes, en raison essentiellement des variations de parcours selon le moment de la journée. Avec l'éditeur de relations de JOSM, ce nombre de relations différentes sur un même objet local est très facile à gérer. La question qui reste est de savoir si c'est techniquement réalisable. Pour taguer, on peut toujours, mais si ensuite ce n'est pas exploitable, ça ne présente pas d'intérêt. Cette solution demanderait donc des adaptations logicielles. Qu'en disent les techniciens ? Muselaar Le 24/07/2014 16:45, Jo a écrit : Je suis complètement d'accord pour ce niveau intermédiaire entre les chemins et les relations route qui symbolisent toutes les variations des lignes de transport en commun. J'ai une rue où j'ai mappé toutes les lignes qui rentrent en ville et j'arrive à 63 relations route pour 28 itinéraires. Il ya donc relativement peu de variations sur les lignes, mais il y a certainement bcp de lignes qui y passent, ce qui rend l'édition compliqué. J'ai déjà essayé de faire cet exercice pour un itinéraire: https://www.openstreetmap.org/relation/2336781/history#map=14/50.8655/4.6878 https://www.openstreetmap.org/relation/2336780/history#map=14/50.8653/4.6883 il y a 2 ans déjà, mais à l'époque OSM n'était pas prêt pour une solution tellement révolutionnaire. Même si pour les itinéraires de randonnée une telle solution a bien été adoptée. Malheureusement, je ne vois pas comment cela résoudrait notre différence d'opinion sur les rond-points. Jo ___ 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] Rencontre parisienne demain ?
On essaye d'être optimiste et on y va quand même :) Le 24 juil. 2014 17:22, Christian Quest cqu...@openstreetmap.fr a écrit : Je suis dans les parages... mais rien d'annoncé pour demain soir. C'est un peu le désert Paris en ce moment ! Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Nouvelle réflexion qui s'ajoute aux précédentes : je ne comprends en fait pas l'utilité des « routes master » : il me semble que c'est une sorte de catégorie déguisée, précédemment vilipendée... Si l'on veut chercher toutes les routes d'une même ligne, il est bien facile de recouper l'opérateur avec le numéro de la ligne en question... ? Le 24/07/2014 17:48, Muselaar a écrit : Sur la question du découpage des ronds-points, j'en suis venu à penser différemment (bien que j'avoue, j'en ai découpé quelques uns pour plus de clarté, mais tous les autres, non), il me semble à moi aussi maintenant que c'est uniquement un problème de rendu : Une solution élégante, et qui allègerait les données, serait de s'abstenir de taguer la route sur les ronds-points, et que la continuité soit reconnue par le fait que 2 nodes différents d'un même rond-point appartiennent à la même route. Je n'arrive pas à imaginer un cas où il pourrait y avoir ambiguité. La route serait alors d'office le parcours obligatoire d'un node à l'autre, étant donné le sens de circulation. Si l'on considère le rond-point comme un carrefour en un même et unique objet, il n'y aurait effectivement en toute logique aucune raison de le taguer, dans la mesure ou les nodes d'entrée et de sortie appartiennent au même carrefour. Un rond-point est un cas particulier de chemin, il n'est pas linéaire, mais circulaire, il revient sur lui-même, on ne peut pas lui appliquer les raisonnements adaptés aux autres chemins. Il y a bien sûr des cas particuliers dans lesquels un parcours peut débuter ou se terminer sur un rond-point, mais à mon sens, ça ne peut en aucun cas être le node d'entrée ou de sortie, mais seulement un node intermédiaire, ce qui n'interfèrerait pas avec ma proposition. Mais cette solution demanderait des adaptations logicielles. Qu'en disent les techniciens ? Pour ton exemple de routes « intermédiaires », je ne comprends pas exactement ce que tu as fait, étant donné que le rendu n'est actuellement pas apte à le prendre en compte... Tu as mis à la fois les chemins, les stops, et les plateformes, c'est ça ? Je ne pense pas que ce soit une bonne idée d'intégrer les arrêts à ces niveaux intermédiaires : d'une part, les arrêts peuvent être différents d'une ligne à l'autre (rien qu'à Belfort qui est une petite ville, il y a plusieurs exemples d'arrêts qui sont « sautés » par certaines lignes), d'autre part, les arrêts, que ce soit les stop_positions ou les plateformes, n'interfèrent quasiment pas avec le reste de la cartographie, donc cela ne crée pas de perturbation pour l'édition des autres usages. De plus, concernant le nombre élevé, je ne crois pas qu'un même point d'arrêt puisse être utilisé par 63 routes de bus, ça doit faire une sacrée queue de bus, et ils n'auraient pas le temps de s'arrêter. Dans mes deux exemples de 20 et 22 relations-routes, il n'y a aucun arrêt qui soit partagé par toutes les relations présentes sur la rue. Sur tout le réseau du Territoire de Belfort, ville comprise, je ne vois que 3 stop_positions (parce que 2 sens confondus) qui totalisent 14 ou 15 routes, et plusieurs autres 11 routes, en raison essentiellement des variations de parcours selon le moment de la journée. Avec l'éditeur de relations de JOSM, ce nombre de relations différentes sur un même objet local est très facile à gérer. La question qui reste est de savoir si c'est techniquement réalisable. Pour taguer, on peut toujours, mais si ensuite ce n'est pas exploitable, ça ne présente pas d'intérêt. Cette solution demanderait donc des adaptations logicielles. Qu'en disent les techniciens ? Muselaar Le 24/07/2014 16:45, Jo a écrit : Je suis complètement d'accord pour ce niveau intermédiaire entre les chemins et les relations route qui symbolisent toutes les variations des lignes de transport en commun. J'ai une rue où j'ai mappé toutes les lignes qui rentrent en ville et j'arrive à 63 relations route pour 28 itinéraires. Il ya donc relativement peu de variations sur les lignes, mais il y a certainement bcp de lignes qui y passent, ce qui rend l'édition compliqué. J'ai déjà essayé de faire cet exercice pour un itinéraire: https://www.openstreetmap.org/relation/2336781/history#map=14/50.8655/4.6878 https://www.openstreetmap.org/relation/2336780/history#map=14/50.8653/4.6883 il y a 2 ans déjà, mais à l'époque OSM n'était pas prêt pour une solution tellement révolutionnaire. Même si pour les itinéraires de randonnée une telle solution a bien été adoptée. Malheureusement, je ne vois pas comment cela résoudrait notre différence d'opinion sur les rond-points. Jo ___ 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] Rencontre parisienne demain ?
Bonne relance ! Je regarde de mon côté et je vous dis quoi. A+ Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne demain ?
J'en profite pour vous dire que sera l'occasion de parler DAE en Essonne et en IdF A+ Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Le 24/07/2014 16:28, Stéphane Péneau a écrit : Par hasard, je viens de tomber sur le message ci-dessous qui n'est pas arrivé sur la ML. Je pense que c'est quelqu'un qui est inscrit sur nabble, mais pas sur la mailing-list, ce qui expliquerait pourquoi il est indiqué This post has NOT been accepted by the mailing list yet. : http://gis.19327.n5.nabble.com/Pourquoi-je-quitte-OSM-tp5810862p5812264.html = Je voudrais apporter quelques compléments sur l'origine du nom officiel de la commune de Vers : Les dénominations officielles successives ont été : XVIIIème siècle : la carte de Cassini indique « Ver » pour la localité est « la Celle » pour la rivière. 1793 : Vers-Hébécourt. (Convention Nationale an II) 1801 : Vers et Hébécourt. (Bulletin des Lois) XIXème siècle : la minute de levé de la carte de l’état-major reporte « Vers », le nom de la rivière est devenu « la Selle ». Nom mais franchement, si la rivière qui traverse la commune s'appelle La Selle, je ne comprends même pas que cette discussion ai pu s'éterniser si longtemps ! Ce point de détail a t'il été mentionné précédemment ? 1878 : Vers, à la suite de la création de la commune de Hébécourt. (Ministère de l’Intérieur) 1919 : Vers est renommée Vers-sur-Selles, très probablement pour la différencier des sept autres communes françaises se nommant Vers. « Selles » y est écrit avec un « s » final alors que la rivière est dénommée « la Selle », ce qui peut résulter d’une erreur de transcription faite à l’époque, officialisée alors par les services de l’État (ministère de l’intérieur à l’époque) et conservée ainsi depuis près d’un siècle. Ces éléments peuvent être versés à l’appui d’une demande que ferait le maire de Vers-sur-Selles conformément aux dispositions de l’article L. 2111-1 du code général des collectivités territoriales. Jean-sébastien Majka Unité de toponymie de l'IGN. = ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne demain ?
Et 10 ans d'OSM au NUMA... donc demain 19h Chez PAPA Le 24 juillet 2014 18:51, Marc SIBERT m...@sibert.fr a écrit : J'en profite pour vous dire que sera l'occasion de parler DAE en Essonne et en IdF A+ Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne demain ?
Cool ! Par contre, on ne pourrait pas retourner au père foutard svp ? Il n'y a pas de terrasse chez papa. Je proposerai bien un autre lieu mais la veille c'est un peu court ;) Le 24 juil. 2014 19:17, Christian Quest cqu...@openstreetmap.fr a écrit : Et 10 ans d'OSM au NUMA... donc demain 19h Chez PAPA Le 24 juillet 2014 18:51, Marc SIBERT m...@sibert.fr a écrit : J'en profite pour vous dire que sera l'occasion de parler DAE en Essonne et en IdF A+ Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Par pur plaisir, Christophe, par pur plaisir :) On 24 juillet 2014 19:00:47 UTC+02:00, Christophe Merlet red...@redfoxcenter.org wrote: Le 24/07/2014 16:28, Stéphane Péneau a écrit : Par hasard, je viens de tomber sur le message ci-dessous qui n'est pas arrivé sur la ML. Je pense que c'est quelqu'un qui est inscrit sur nabble, mais pas sur la mailing-list, ce qui expliquerait pourquoi il est indiqué This post has NOT been accepted by the mailing list yet. : http://gis.19327.n5.nabble.com/Pourquoi-je-quitte-OSM-tp5810862p5812264.html = Je voudrais apporter quelques compléments sur l'origine du nom officiel de la commune de Vers : Les dénominations officielles successives ont été : XVIIIème siècle : la carte de Cassini indique « Ver » pour la localité est « la Celle » pour la rivière. 1793 : Vers-Hébécourt. (Convention Nationale an II) 1801 : Vers et Hébécourt. (Bulletin des Lois) XIXème siècle : la minute de levé de la carte de l’état-major reporte « Vers », le nom de la rivière est devenu « la Selle ». Nom mais franchement, si la rivière qui traverse la commune s'appelle La Selle, je ne comprends même pas que cette discussion ai pu s'éterniser si longtemps ! Ce point de détail a t'il été mentionné précédemment ? 1878 : Vers, à la suite de la création de la commune de Hébécourt. (Ministère de l’Intérieur) 1919 : Vers est renommée Vers-sur-Selles, très probablement pour la différencier des sept autres communes françaises se nommant Vers. « Selles » y est écrit avec un « s » final alors que la rivière est dénommée « la Selle », ce qui peut résulter d’une erreur de transcription faite à l’époque, officialisée alors par les services de l’État (ministère de l’intérieur à l’époque) et conservée ainsi depuis près d’un siècle. Ces éléments peuvent être versés à l’appui d’une demande que ferait le maire de Vers-sur-Selles conformément aux dispositions de l’article L. 2111-1 du code général des collectivités territoriales. Jean-sébastien Majka Unité de toponymie de l'IGN. = ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Ne plus ajouter les rond-points donnerait dans l'éditeur de relations de JOSM l'impression que la route n'est pas continue. Dans le rendu pareil. Ce n'est donc pas une option. Quant à la proposition: Il s'agit de relations routes qui utilisent une hiérarchie supplémentaire de relations routes, qui eux décrivent de parties d'itinéraires, qui peuvent être réutilisés par plusieurs variations d'itinéraire de bus. Je pense que j'aurai besoin d'un autre exemple. Peut-être que j'en fabriquerai un ce soir. J'ai ajouté une relation au sud-ouest de Mouscron hier qui est composé de 20 variations et point de vue itinéraire bus, il était dans terrain vierge. J'utiliserai celui-là comme guinea pig. Pour les route master, là je suis la proposition de transport en commun villifiée par ceux qui font le rendu, mais que les mappeurs semblent plus ou moins adopter. je dis plus ou moins, car moi aussi j'utilise plutôt une version 'light' pour la plupart des arrêts. C'est une modellisation de la réalité. Le niveau route master représente ce que les gens comprennent comme 'la ligne telle'. Est-ce une catégorie déguisé? D'un coté je suis content qu'elles soient présentes, car je les utilise pour ajouter des ref qui sont commun pour toutes les variations. Mais si quelqu'un veut combattre les moulins-à-vent, c'est un bon cible, je suppose. Jo 2014-07-24 18:12 GMT+02:00 Muselaar musel...@ouvaton.org: Nouvelle réflexion qui s'ajoute aux précédentes : je ne comprends en fait pas l'utilité des « routes master » : il me semble que c'est une sorte de catégorie déguisée, précédemment vilipendée… Si l'on veut chercher toutes les routes d'une même ligne, il est bien facile de recouper l'opérateur avec le numéro de la ligne en question… ? Le 24/07/2014 17:48, Muselaar a écrit : Sur la question du découpage des ronds-points, j'en suis venu à penser différemment (bien que j'avoue, j'en ai découpé quelques uns pour plus de clarté, mais tous les autres, non), il me semble à moi aussi maintenant que c'est uniquement un problème de rendu : Une solution élégante, et qui allègerait les données, serait de s'abstenir de taguer la route sur les ronds-points, et que la continuité soit reconnue par le fait que 2 nodes différents d'un même rond-point appartiennent à la même route. Je n'arrive pas à imaginer un cas où il pourrait y avoir ambiguité. La route serait alors d'office le parcours obligatoire d'un node à l'autre, étant donné le sens de circulation. Si l'on considère le rond-point comme un carrefour en un même et unique objet, il n'y aurait effectivement en toute logique aucune raison de le taguer, dans la mesure ou les nodes d'entrée et de sortie appartiennent au même carrefour. Un rond-point est un cas particulier de chemin, il n'est pas linéaire, mais circulaire, il revient sur lui-même, on ne peut pas lui appliquer les raisonnements adaptés aux autres chemins. Il y a bien sûr des cas particuliers dans lesquels un parcours peut débuter ou se terminer sur un rond-point, mais à mon sens, ça ne peut en aucun cas être le node d'entrée ou de sortie, mais seulement un node intermédiaire, ce qui n'interfèrerait pas avec ma proposition. Mais cette solution demanderait des adaptations logicielles. Qu'en disent les techniciens ? Pour ton exemple de routes « intermédiaires », je ne comprends pas exactement ce que tu as fait, étant donné que le rendu n'est actuellement pas apte à le prendre en compte… Tu as mis à la fois les chemins, les stops, et les plateformes, c'est ça ? Je ne pense pas que ce soit une bonne idée d'intégrer les arrêts à ces niveaux intermédiaires : d'une part, les arrêts peuvent être différents d'une ligne à l'autre (rien qu'à Belfort qui est une petite ville, il y a plusieurs exemples d'arrêts qui sont « sautés » par certaines lignes), d'autre part, les arrêts, que ce soit les stop_positions ou les plateformes, n'interfèrent quasiment pas avec le reste de la cartographie, donc cela ne crée pas de perturbation pour l'édition des autres usages. De plus, concernant le nombre élevé, je ne crois pas qu'un même point d'arrêt puisse être utilisé par 63 routes de bus, ça doit faire une sacrée queue de bus, et ils n'auraient pas le temps de s'arrêter. Dans mes deux exemples de 20 et 22 relations-routes, il n'y a aucun arrêt qui soit partagé par toutes les relations présentes sur la rue. Sur tout le réseau du Territoire de Belfort, ville comprise, je ne vois que 3 stop_positions (parce que 2 sens confondus) qui totalisent 14 ou 15 routes, et plusieurs autres 11 routes, en raison essentiellement des variations de parcours selon le moment de la journée. Avec l'éditeur de relations de JOSM, ce nombre de relations différentes sur un même objet local est très facile à gérer. La question qui reste est de savoir si c'est techniquement réalisable. Pour taguer, on peut toujours, mais si ensuite ce n'est pas exploitable, ça ne présente pas d'intérêt. Cette solution demanderait donc
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Nom mais franchement, si la rivière qui traverse la commune s'appelle La Selle, je ne comprends même pas que cette discussion ai pu s'éterniser si longtemps ! Ce point de détail a t'il été mentionné précédemment ? Dans un des premiers courriers du fil. Jo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne demain ?
Vu qu'on n'a pas annoncé, on risque d'avoir quelques personnes qui viennent à l'adresse habituelle. Je resterai sur le Chez Papa pour ce coup-ci, mais pour le prochain, c'est open ! Le 24 juillet 2014 19:30, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Cool ! Par contre, on ne pourrait pas retourner au père foutard svp ? Il n'y a pas de terrasse chez papa. Je proposerai bien un autre lieu mais la veille c'est un peu court ;) Le 24 juil. 2014 19:17, Christian Quest cqu...@openstreetmap.fr a écrit : Et 10 ans d'OSM au NUMA... donc demain 19h Chez PAPA Le 24 juillet 2014 18:51, Marc SIBERT m...@sibert.fr a écrit : J'en profite pour vous dire que sera l'occasion de parler DAE en Essonne et en IdF A+ Le 24 juillet 2014 16:58, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelques personnes présentes à Paris demain ? (dernier vendredi du mois) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr