[talk-ph] Drones (UAV's) in Th ePhilippines

[Mark Cupitt]

 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

[Martin Koppenhoefer]

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

[Randy Meech]

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?

[Stefan Keller]

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?

[Pierre Béland]

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 Keller]

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?

[Pierre Béland]

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?

[Stefan Keller]

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?

[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.


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

[François Lacombe]

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?

[Pieren]

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

[Jóhannes Birgir Jensson]

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?

[Pierre Béland]

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

[Florian Lohoff]

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?

[mmd]

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

[Simon Poole]

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

[Andreas Goss]

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

[Rob Nickerson]

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?

[Stefan Keller]

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

[Andreas Goss]

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?

[mmd]

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

[François Lacombe]

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

[Frederik Ramm]

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

[François Lacombe]

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?

[Christian Quest]

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

[Frederik Ramm]

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

[John Packer]

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

[Rob Nickerson]

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)

[Rob Nickerson]

 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

[Tobias Knerr]

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

[Steve Doerr]

+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

[Clifford Snow]

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

[Andreas Goss]

 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

[Andreas Goss]

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

[marekskleciak]

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

[Aun Johnsen]

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

[Paulo Carvalho]

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

[Alexandre Magno Brito de Medeiros]

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

[Aun Johnsen]

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

[Alexandre Magno Brito de Medeiros]

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

[Alexandre Magno Brito de Medeiros]

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.

[Fernando Trebien]

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

[Fernando Trebien]

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

[wille]

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.

[Fernando Trebien]

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.

[Aun Johnsen]

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

[Tarcisio Oliveira]

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!

[Johannes]

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

[Martin Koppenhoefer]

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

[Luca Delucchi]

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

[Simone Saviolo]

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

[sabas88]

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

[emmexx]

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

[Carlo Stemberger]

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

[Any File]

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

[Lorenzo Mastrogiacomi]

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

[Martin Koppenhoefer]

 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

[John Andersson]

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

[Ander Pijoan]

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

[rupert THURNER]

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

[Enock Seth Nyamador]

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

[Rich]

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

[lenny]

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

[Christian Quest]

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

[Francescu GAROBY]

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

[Pieren]

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

[Tetsuo Shima]

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

[Tetsuo Shima]

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 ?

[HParv]

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 ?

[Plop76]

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 ?

[Sylvain Maillard]

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

[Régis Bouguin]

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 ?

[Christian Quest]

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

[Christian Quest]

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

[Pieren]

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

[Christian Quest]

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

[Muselaar]

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

[François Lacombe]

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..)

[Stéphane Péneau]

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

[Stéphane Péneau]

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

[David Crochet]

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

[Jo]

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

[François Lacombe]

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 ?

[Jean-Baptiste Holcroft]

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 ?

[Christian Quest]

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

[David Crochet]

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

[Pieren]

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

[François Lacombe]

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

[Muselaar]

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 ?

[Jean-Baptiste Holcroft]

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

[Muselaar]

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 ?

[Marc SIBERT]

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 ?

[Marc SIBERT]

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

[Christophe Merlet]

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 ?

[Christian Quest]

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 ?

[Jean-Baptiste Holcroft]

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

[Yves]

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

[Jo]

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

[Jo]

 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 ?

[Christian Quest]

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