[Talk-ca] CanVec Reverts

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

unfortunately posting via Gmane does not seem to work (the website is
down but NNTP still works), that's why I have to start a new thread. :-(

Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> After reading through the changeset discussion, I discovered that
> one of my imports in Northern Manitoba made Worst of OSM. 
> (http://worstofosm.tumblr.com/post/22180046353/dear- 
> openstreetmap-isnt-it-strange-how-the). As someone who spends a
> some time amount of time in some of relatively unpopulated areas of
> Canada and makes an effort to check the quality of Canvec data
> (which is usually pretty good), I do agree that it is impossible to
> do everything to the same level of quality that we would provide in
> Toronto or Timmins or even small prairie towns.

First of all, it is ok that an import takes a few years and therefore
creates ugly green rectancles on the map. If an import is "unavoidable"
:-), a manual import is the best thing that can be happen. But if
someone uploads a changeset without a manual review beforehand, he
counteracts the aim of a manual import: addind good data to
OpenStreetMap. That's what I am mainly fighting against. If a users
uploads much more than 100 objects per minute [1], you can be sure that
he has not done any manual review. A manual review by myself confirmed
this these. I am fighting against such changesets/users.

A good imports must be reviewed *before* it is being uploaded. The
review contains:
- - Run JOSM validator, fix all warnings and errors. This includes all
warnings regarding validity of areas. (you can argue if all warnings
about "deprecated" tagging have to be fixed)
- - Compare the data with available imagery. Is the forest really a forest
or is another tag more appropiate? Right-click on a Bing tile at JOSM
and have a look how old/recent the imagery is.
- - Check if CanVec data fits to itself.
http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
it-strange-how-the
- - Check if there has been any other data before. If yes, adapt the
either the CanVec data or the old data.
https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
ide-Cutting.png
https://www.openstreetmap.org/way/439631732
- - Ways should not overlap with other ways if it is not necessary. The
outer ring of a lake should also be inner member of the forest
multipolygon. Maybe the program which created the OSM files should be
imprved?
- - Keep the history.
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history

If a tile has been imported without being checked manually and no
post-upload fixes have been done (i.e. upload without any checks), I
will not shrink from reverting it. If a tile has been uploaded to OSM
without a review and if it has not been fixed within a month, it is
worthless and can easily be reimported at a later time if someone has
the time to check and fix it.

For the future, I will abstain from reverting changesets which have been
imported before September 1, 2016 and whose users are currently doing
the fixes that should already have been done. But if I come across an
imported tile of low quality which has not been touched for a few weeks
and is full of errors, it is just a question of time until it is reverte
d.

Best regards

Michael



[1] I had a look on a few of my changesets which added a large number of
buildings to OSM. The fastest changeset contained about 60 objects per
minute and was full of missing buildings as I later detected while
collecting the housenumbers and usage of the buildings.

- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXx77+AAoJEB87G9rMCMyI95YQAJyCMY/Qtnqu4C3MpLPrrwTH
vN2aVBNoKHL+i6r5VBTPFy4JhcacjbAZSseMCbmQHo6CSdPgVk9Jvnk/Keh3ihH6
r//EqwqRnSPPE+JIBktW0DG50jzcogWun3UQmOyA/blRfYEZaIDhjRDjMcivBWvs
x8EGZsuX/mraX74ucTbfhy13Xoy4M4Yjf4ibNS7ZmJKlT4Zj8HDwlPKRzFxZ6iWG
JGfibU4wxxvJlQDWqjrVRN6zacbt8SKh9sHU3M88kNRhM+eido/rYY9LiKBFdO21
TBGM/XkvxcqM7F9u9uC03caDFi0cTb7PLZgv90QhXTi2DuFobfHf3sc1czq8lGeB
Wa8ZZqRI6Y9/SV06P/wydA48caKeeO3OiiuH8UXzEZJPauUhLjpEVxY1OixkgNkC
GR79KbVcx0AyFK66Jnrdn2pqa2HotJ2rM6RLSi68mMOYPbHcUvujcb7XQW5dvubF
L3TamnVs8u1qiifpfTCAp/AJFxd/9UDnGi2VsjSHrIPdZgJaCAcHmhiUSXkcZa55
hjfL+4b+itj48PRcfJRzXTRE3I9Q7oAyMkbwMKVFvSOe9GwgUNw5nvspWvPUriUo
pDoDHFJt3k4RE6hHVhsb0+L/OyVr6NFpjex2aoEbX0990Gvi+G6uabkNAOn4o0Ub
nAQhtQWnI5dlwMWhcYOH
=vPJv
-END PGP SIGNATURE-

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

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

Hi Matthijs,

+1 to keep Map Feature pages up to date.

It would be great to sync definitions with info boxes (with some template
tricks but it more looks like wiki-data than simple wikimedia templates)
TagInfo already got it from wiki

All the best
Francois
Le 1 sept. 2016 12:45 AM, "Matthijs Melissen"  a
écrit :

> Hi,
>
> We have currently a Map Features page on the wiki:
> http://wiki.openstreetmap.org/wiki/Map_Features
>
> The page also contains definitions for all features. We therefore
> store the definitions now in two places: in the map features tables
> and in the infoboxes on the pages themselves.
>
> Duplication of definitions seems not ideal to me. Even though a lot of
> people try to update this, there are still quite a lot differences
> between the definitions on the map feature pages and the definitions
> in the infoboxes.
>
> Do we want to keep the Map Features page? If yes, do we have technical
> means to keep the definitions synchronised? Could we perhaps generate
> it from Taginfo, or somehow include the definition from the Infobox on
> the Map Features page?
>
> -- Matthijs
>
> ___
> 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] Map features page on wiki

[Jochen Topf]

On Do, Sep 01, 2016 at 12:42:10 +0200, Matthijs Melissen wrote:
> We have currently a Map Features page on the wiki:
> http://wiki.openstreetmap.org/wiki/Map_Features
> 
> The page also contains definitions for all features. We therefore
> store the definitions now in two places: in the map features tables
> and in the infoboxes on the pages themselves.
> 
> Duplication of definitions seems not ideal to me. Even though a lot of
> people try to update this, there are still quite a lot differences
> between the definitions on the map feature pages and the definitions
> in the infoboxes.
> 
> Do we want to keep the Map Features page? If yes, do we have technical
> means to keep the definitions synchronised? Could we perhaps generate
> it from Taginfo, or somehow include the definition from the Infobox on
> the Map Features page?

A solution using Taginfo has been available for about a year now, but
nobody took this up. (I guess because not many people know that this
exists, and I didn't have time to promote it really.)

See https://wiki.openstreetmap.org/wiki/Taginfo/Taglists . This "just"
needs some people going through every tag list in the wiki and replacing
it by the special syntax. The problem ist, as you say, the differing
descriptions and such, which need to be consolidated in the process.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-ca] broken forests in eastern Canada

[Antoine Beaupré]

On 2016-08-29 23:47:28, Gordon Dewis wrote:
>> I believe it would be more important to map out park boundaries than
>> actual forest limits which, quite unfortunately, change in pretty
>> dramatic ways in Québec, due to massive logging that has been happening
>> for decades.
>
> Park boundaries are mostly in already, aren’t they? They are fairly easy 
> features to import compared to forests.

Not in Québec, they are not - a bunch of parks are missing still. Some
of the larger areas (like Parc de la Vérendrye, a 22 000 km² area) are
daunting in and of themselves.

No freely available datasource for those either.

A.

-- 
While the creative works from the 16th century can still be accessed
and used by others, the data in some software programs from the 1990s
is already inaccessible.
 - Lawrence Lessig

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

Re: [Talk-ca] What's up with those forests in Canada section

[James]

+1 a lot more detailed than what I wrote

On Aug 31, 2016 10:26 PM, "Sam Dyck"  wrote:

> Here's my suggestion for a sort of FAQ (in wiki markup), incorporating
> what James already wrote. I'm posting it here for comment because I have a
> tendency to get unhelpfully passive aggressive.
>
> The squared off sections of forest in Canada are the result of unfinished
> CanVec data import. CanVec tiles are broken up into squares called the NTS
> grid to better manage the data. If you see a forest that's squared off with
> a empty section beside it, it's most likely that that grid has not been
> imported yet.
>
> ''What is Canvec?''
>
> [[Canvec]] is a digital product produced by the federal government that is
> a combination of various federal geodata databases into 1:5 tiles.
> These tiles were converted by Natural Resources Canada into OSM XML and put
> on a government FTP server for importation into OSM. After several years of
> licensing discussion.
>
> ''Some of the data in a Canvec import changeset has something weird going
> on (forests overlapping in lakes, islands where there don't appear to
> islands, wetlands where there sohuld be lakes). Why are you importing this
> garbage?''
>
> Canvec is generally accurate, it was collected from high quality satellite
> imagery collected for the federal government, and has generally withstood
> our attempts to ground truth it. However there are errors and apparent
> errors. Some of these can be explained by natural changes: lakeshores shift
> with the years and seasons, lakes become wetlands, forests burn or are cut
> down and regrow.
>
> The simple reason we have to do this import is because Canada is enormous
> and has very few people, consequently there are large areas that have a
> very light human presence. For example the territory of Nunavut, the
> largest subnational division in Canada, is larger than of France, Ukraine,
> Sweden and the United Kingdom combined and has less than 40,000 people.
> Most people in Canada live in a handful of cities a short distance from the
> US border. There is a lot of blank area to fill, and so we make an effort
> to import quality data, but there is a lot of area to cover, so after long
> discussions we arrived at the consensus that importing Canvec data was the
> best solution, providing we followed a set of practices.
>
> ''Don't you have local mappers in these communities who could check the
> data?''
>
> Most likely no. See the note about population density above. Also much of
> non-urban Canada, especially Northern communities, have to rely on
> satellite internet, which is both extremely expensive and has both
> effective download speeds measured in kbps and small data caps of 5 or 10
> GB.
>
> ''I see some issues with Canvec data, what should I do?''
>
> If you think the data itself is in error, try and check to see if it could
> not possibly be an accurate reflection of what might be at some point.
> Canvec importers have been criticized for importing data, that while it
> looks suspicious, accurately reflects what is on the ground. If it's an
> obvious error that's easy to fix, go ahead and correct it. If there's
> something bigger, talk to the mapper or post on the talk-ca mailing list.
>
> ''I see something wrong with the actual structure of the data (overly
> complex ways, duplicate ways).''
>
> These should have been fixed in the import, but sometimes things get
> missed. Please go ahead and fix them.
>
> ''I found a Canvec import that didn't comply with the import policy!''
>
> Please don't revert it, despite the appearance of wholesale importing, a
> proper Canvec import takes a lot of time and effort on the part of the
> importer. Canvec imports began before the current import policy, and so
> some importers continued what they had already been doing unaware of the
> policy. Hopefully everyone is in compliance now, but if you do see
> importing incorrectly please assume good faith.
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] What's up with those forests in Canada section

[Sam Dyck]

Here's my suggestion for a sort of FAQ (in wiki markup), incorporating what
James already wrote. I'm posting it here for comment because I have a
tendency to get unhelpfully passive aggressive.

The squared off sections of forest in Canada are the result of unfinished
CanVec data import. CanVec tiles are broken up into squares called the NTS
grid to better manage the data. If you see a forest that's squared off with
a empty section beside it, it's most likely that that grid has not been
imported yet.

''What is Canvec?''

[[Canvec]] is a digital product produced by the federal government that is
a combination of various federal geodata databases into 1:5 tiles.
These tiles were converted by Natural Resources Canada into OSM XML and put
on a government FTP server for importation into OSM. After several years of
licensing discussion.

''Some of the data in a Canvec import changeset has something weird going
on (forests overlapping in lakes, islands where there don't appear to
islands, wetlands where there sohuld be lakes). Why are you importing this
garbage?''

Canvec is generally accurate, it was collected from high quality satellite
imagery collected for the federal government, and has generally withstood
our attempts to ground truth it. However there are errors and apparent
errors. Some of these can be explained by natural changes: lakeshores shift
with the years and seasons, lakes become wetlands, forests burn or are cut
down and regrow.

The simple reason we have to do this import is because Canada is enormous
and has very few people, consequently there are large areas that have a
very light human presence. For example the territory of Nunavut, the
largest subnational division in Canada, is larger than of France, Ukraine,
Sweden and the United Kingdom combined and has less than 40,000 people.
Most people in Canada live in a handful of cities a short distance from the
US border. There is a lot of blank area to fill, and so we make an effort
to import quality data, but there is a lot of area to cover, so after long
discussions we arrived at the consensus that importing Canvec data was the
best solution, providing we followed a set of practices.

''Don't you have local mappers in these communities who could check the
data?''

Most likely no. See the note about population density above. Also much of
non-urban Canada, especially Northern communities, have to rely on
satellite internet, which is both extremely expensive and has both
effective download speeds measured in kbps and small data caps of 5 or 10
GB.

''I see some issues with Canvec data, what should I do?''

If you think the data itself is in error, try and check to see if it could
not possibly be an accurate reflection of what might be at some point.
Canvec importers have been criticized for importing data, that while it
looks suspicious, accurately reflects what is on the ground. If it's an
obvious error that's easy to fix, go ahead and correct it. If there's
something bigger, talk to the mapper or post on the talk-ca mailing list.

''I see something wrong with the actual structure of the data (overly
complex ways, duplicate ways).''

These should have been fixed in the import, but sometimes things get
missed. Please go ahead and fix them.

''I found a Canvec import that didn't comply with the import policy!''

Please don't revert it, despite the appearance of wholesale importing, a
proper Canvec import takes a lot of time and effort on the part of the
importer. Canvec imports began before the current import policy, and so
some importers continued what they had already been doing unaware of the
policy. Hopefully everyone is in compliance now, but if you do see
importing incorrectly please assume good faith.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Qualiuty of OSM data

[Stewart C. Russell]

On 2016-08-31 06:31 PM, Adam Martin wrote:
> I would also like to take a read through that document. Sounds interesting.

It *may* have been this one: “Node location anomaly — Jochen Topf”
 but
I may be misremembering.

> A giant blank gap
> for Canada would not be very good for the map in general and us
> specifically.

I agree completely. Roads, lakes, powerlines, train lines: all useful.
Millions of land-use polygons that might as well say "Trees (or
something)" are not so useful.

cheers,
 Stewart

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

[OSM-talk-fr] Le Havre

[Yannick]

Bonsoir,

Chers amis qui habitez Le HAVRE (76) pourriez-vous me donner une liste
d'hôtels pas chers vers le centre des congrès Véga quai de la Réunion
(selon google)?

Ou au moins aisément accessible dans les deux sens depuis ce lieu. En
effet je dois préparer ma venue l'an prochain en septembre pour un
congrès de généalogie.
J'ai regardé sur OSM et je n'ai pas vu grand chose à proximité.

Je vais suggérer aux organisateurs prendre la carte OSM en lieu et place
qui vous savez. Si vous pouviez me faire une carte avec le centre des
congrès parfaitement localisé cela serait génial.
Si vous osiez vous placeriez aussi les hôtels et les restaurants proches
de ces derniers.

L'idéal serait une carte qui aurait:
Le centre des congrès
Les hôtels avec restaurants inclus
Les hôtels sans restaurants
Les restaurants proches (dans lesquels vous iriez vous-mêmes)
Soit donc 4 couleurs d'identifiants

Je vous dis merci d'avance pour ce que vous allez pouvoir me préparer.

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org

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

Re: [talk-au] Tagging for the router

[Ian Sergeant]

Hi,

I'd suggest the easiest solution is just to change the wiki.

Ian.

On 1 September 2016 at 09:37, Nick Hocking  wrote:

> "My suggestion is that the map data is the best place to store that
> information."
>
> Actually - the wiki page is very specific on this.
>
> "When a particular turn restriction is *the default* for a given
> jurisdiction *and* is *not signed* *don't map them*. It is much better to
> ensure that routing engines embody the regional rule rather than mapping
> every occurrence as a turn restriction."
>
>
> Ok so how do we "ensure that routing engines embody the regional rule:?
>
> E-mailing their support address and asking them to study the road rules
> for every jurisdiction in the world is not going to cut it. So maybe the
> only way is to name and shame them in a public forum somewhere, but where?
>
>
> I don't think that there is a routing engine out there that won't suggest
> crazy +90 degree turns on a high speed road.
>
>
>
> Probably, the only solution is to advise users to always check the "don't
> allow u-turns" box on their navigators.
>
> Also - how do we map a signed "U turn permitted" at traffic lights where
> the default is "not permitted"?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging for the router

[Nick Hocking]

When I said that Gosmore (YourNavgation) website had done something stupid,
I was wrong.

It was the data that was incorrect. I have fixed the data to make the acute
angle , where the two carriageways meet up, far more acute (which agrees
with the imagery.

Once the Yournavigation site updates it's maps, I'm sure Gosmore will do a
perfect job.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging for the router

[Phillip and Kerrie]

If the wiki says no then I withdraw my suggestion. Don't want to ruffle too
many feathers.
Sorry for not having read the mapping guidelines.

On 1 Sep 2016 9:38 AM, "Nick Hocking"  wrote:

> "My suggestion is that the map data is the best place to store that
> information."
>
> Actually - the wiki page is very specific on this.
>
> "When a particular turn restriction is *the default* for a given
> jurisdiction *and* is *not signed* *don't map them*. It is much better to
> ensure that routing engines embody the regional rule rather than mapping
> every occurrence as a turn restriction."
>
>
> Ok so how do we "ensure that routing engines embody the regional rule:?
>
> E-mailing their support address and asking them to study the road rules
> for every jurisdiction in the world is not going to cut it. So maybe the
> only way is to name and shame them in a public forum somewhere, but where?
>
>
> I don't think that there is a routing engine out there that won't suggest
> crazy +90 degree turns on a high speed road.
>
>
>
> Probably, the only solution is to advise users to always check the "don't
> allow u-turns" box on their navigators.
>
> Also - how do we map a signed "U turn permitted" at traffic lights where
> the default is "not permitted"?
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging for the router

[Nick Hocking]

"My suggestion is that the map data is the best place to store that
information."

Actually - the wiki page is very specific on this.

"When a particular turn restriction is *the default* for a given
jurisdiction *and* is *not signed* *don't map them*. It is much better to
ensure that routing engines embody the regional rule rather than mapping
every occurrence as a turn restriction."


Ok so how do we "ensure that routing engines embody the regional rule:?

E-mailing their support address and asking them to study the road rules for
every jurisdiction in the world is not going to cut it. So maybe the only
way is to name and shame them in a public forum somewhere, but where?


I don't think that there is a routing engine out there that won't suggest
crazy +90 degree turns on a high speed road.



Probably, the only solution is to advise users to always check the "don't
allow u-turns" box on their navigators.

Also - how do we map a signed "U turn permitted" at traffic lights where
the default is "not permitted"?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-ca] broken forests in eastern Canada

[dega]

On Aug 31, Daniel Bégin wrote:
> On the same topic, it has been suggested to split wooded areas in smaller 
> chunks by using features on the ground as outer limits (mostly roads,
> streams, rivers) and get rid of arbitrary rectangles from Canvec.
> Is it something we are aiming at?

The grid is an important source of problems. Here are some examples:
1) If a lake is on the grid, it will be split in 2 parts. Each part will have 
a name tag and and 2 identical names will be displayed on the map, one on each 
part. This problem exist in thousands of lakes. I even saw a lake with a 
triplicated name.
Merging the parts would require modifying 2 or more relations and many 
importers don't do it (even if they use JOSM) because of the complexity. Some 
have used a quick fix where they remove names from the parts and put it in a 
POI. It looks fine but that's bad for database integrity.

2) A addr:interp way may be split in 2 parts. 2 consequences:
- the interpolation way become useless because it's now 2 different objects.
- the mid-point becomes 2 superposed nodes. Useless duplication.

3) A grid tile has a fixed size. It may be appropriate for unpopulated areas 
but it is too large for urban areas where editors work at a high zoom level 
(17 and up). It's easy to damage a relation without knowing it.

But there are other problems (not related to the grid):
4) the relations seem to be designed to be stand-alone. Thus the relation 
borders don't share a way. They use 2 superposed ways. Useless duplication. 
It's very confusing and we frequently alter the wrong way.

5) lakes are represented by 2 superposed identical objects, one for the hole 
and one for the lake. If the hole happen to be on top, the name will not be 
displayed. It's an unjustifiable complexity for the casual user.
I've also seen triplicated contour (one for the lake, on for the inner role 
and one for the outer role)

Yes, all these quirks can be fixed manually but it's time-consuming and error-
prone.

Ideally, the contour of a forest must not split any object and it's not 
possible with a grid.
The sole advantage of a grid IMHO is to simplify the CanVec exports.

Some years ago I would have proposed that someone write a guide "How to fix a 
CanVec import". But now I would rather propose that someone write a "How to 
pre-process a CanVec export before importing it into OSM".

dega


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

[OSM-talk] Map features page on wiki

[Matthijs Melissen]

Hi,

We have currently a Map Features page on the wiki:
http://wiki.openstreetmap.org/wiki/Map_Features

The page also contains definitions for all features. We therefore
store the definitions now in two places: in the map features tables
and in the infoboxes on the pages themselves.

Duplication of definitions seems not ideal to me. Even though a lot of
people try to update this, there are still quite a lot differences
between the definitions on the map feature pages and the definitions
in the infoboxes.

Do we want to keep the Map Features page? If yes, do we have technical
means to keep the definitions synchronised? Could we perhaps generate
it from Taginfo, or somehow include the definition from the Infobox on
the Map Features page?

-- Matthijs

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

Re: [Talk-it] Terremoto Rieti

[Alessandro Sarretta]

Grande! :-)

Ale


On 31/08/2016 22:22, Fabrizio Carrai wrote:
Vi allego la query per overpass-turbo per la visualizzazione dei danni 
del terremoto. Ho adattato una già usata per il tifone Haiyan che 
colpi le Filippine. Per ora è solo relativa ai buildings, ma può 
essere rapidamente adattata anche alle strade o altro.


Ho cercato di seguire la scala di earthquake:damage che è stata 
discussa in lista.


Potete vedere un esempio dei risultati su http://overpass-turbo.eu/s/i80.

Se utile posso caricare una copia su GitHub.

FabC




  


  
  
  
  
  


  
  
  
  
  



  
  
  
  
  


  
  
  
  
  


  
  
  
  

{{style:

way[building]
{ color:blue; fill-color:blue;opacity:0.4;
  fill-opacity:0.4;}

way[earthquake:damage=collapsed]
{ color:Yellow; fill-color:darkred;width:1;
dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=severe]
{ color:Yellow; fill-color:red;width:1;
dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=moderate]
{ color:Yellow; fill-color:pink;width:1;
dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=negligible]
{ color:Yellow; fill-color:MistyRose;width:1;
dashes:5,5;opacity:1;fill-opacity:0.8;}

}}


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


--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-it] Terremoto Rieti

[Alessandro Sarretta]

Grazie Lorenzo,

On 31/08/2016 21:20, Lorenzo Mastrogiacomi wrote:
Io mi sono affidato ai vettoriali, sicuramente più semplice. Non mi 
sembra il caso di mettermi a valutare personalmente quando il lavoro è 
già stato fatto a monte. Le immagini comunque utili se c'è da 
sistemare le geometrie.


Per me puoi anche aggiornare, vedrò di controllare o sbloccare le tile 
interessate. Per il futuro non so...se ci sono modifiche sostanziali e 
ci vengono segnalate  possiamo ricontrollarle

allora, intanto ho aggiornato i dati vettoriali aggregati.
Li trovate qui 
(https://github.com/emergenzeHack/terremotocentro_geodata/tree/gh-pages/copernicus/r05/shape_file) 
aggiornati a fine giornata 31/8/2016.
Qui trovate maggiori informazioni: 
https://github.com/emergenzeHack/terremotocentro_geodata/blob/gh-pages/copernicus/r05/elaborazione_dati.md

Per il WMS, ditemi voi se vale la pena aggiornarlo.

'notte

Ale


--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-ca] Qualiuty of OSM data

[Adam Martin]

I would also like to take a read through that document. Sounds interesting.

CANVEC has been good for the Canadian mapping efforts, but it is stale data
and not highly accurate. Yet it provides us a base to work from and has the
benefit of filling the map with ... something. A giant blank gap for Canada
would not be very good for the map in general and us specifically.

On Aug 31, 2016 7:38 PM, "James"  wrote:

> I've read it in the past, I do agree cavec is not 100% accurate, but  in
> areas with absolutely nothing, it is better than a blank map: which is
> useless.
>
> On Aug 31, 2016 6:02 PM, "dega"  wrote:
>
> Hi everybody!
> On 2016-08-31 Stewart C. Russell wrote:
> > A paper published in the last couple of years (by Anita Graser, maybe?)
> > showed that CanVec imports were the largest source of spurious precision
> > in the entire OSM database.
>
> If somebody has a link to that document, I would like to get it.
>
> Thanks!
>
> dega
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk] Analysis of usage of similar tags over time

[Matthijs Melissen]

Hi all,

Recently, a new tool was created by Martin Raifer (@tyrasd) to
generate graphs of the usage of tags over time. This is a great tool
that gives us more insight in what drives the choice of tags by
mappers. The tool can be found at http://taghistory.raifer.tech/.

I wrote an OSM diary to discuss some results:
http://www.openstreetmap.org/user/Math1985/diary/39404#comment35887

-- Matthijs

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

Re: [Talk-ca] Qualiuty of OSM data

[James]

I've read it in the past, I do agree cavec is not 100% accurate, but  in
areas with absolutely nothing, it is better than a blank map: which is
useless.

On Aug 31, 2016 6:02 PM, "dega"  wrote:

Hi everybody!
On 2016-08-31 Stewart C. Russell wrote:
> A paper published in the last couple of years (by Anita Graser, maybe?)
> showed that CanVec imports were the largest source of spurious precision
> in the entire OSM database.

If somebody has a link to that document, I would like to get it.

Thanks!

dega

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

[Talk-ca] Qualiuty of OSM data

[dega]

Hi everybody!
On 2016-08-31 Stewart C. Russell wrote:
> A paper published in the last couple of years (by Anita Graser, maybe?)
> showed that CanVec imports were the largest source of spurious precision
> in the entire OSM database.

If somebody has a link to that document, I would like to get it.

Thanks!

dega

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

[Talk-GB] Tools for using Food Hygiene data e.g. quickly adding addresses/postcodes

[Greg]

Hi all,

I posted to the West Midlands list in April (and a reply was CC'd here)
regarding some tools I've developed for visualising Food Hygiene Rating
Scheme (FHRS) and OSM data, finding possible matches between it and
importing useful tags into JOSM.

I have now set up these tools on the dev server to provide comparison
maps and statistics for the whole of Great Britain. They should be
updated weekly. Just go to [http://gregrs.dev.openstreetmap.org/fhrs/]
and select a district.

I think the FHRS data is a useful source of postcodes and addresses, and
it can also be a helpful reminder of local establishments to add to the
map. It is my hope that these tools could help us to efficiently add and
verify data in our local areas. Please do have a look at the link above.

If anyone would like to improve or re-use parts of the code, it's
available on GitHub: [https://github.com/gregrs-uk/python-fhrs-osm]

Thanks,
Greg.

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

Re: [Talk-it] Terremoto Rieti

[Fabrizio Carrai]

Vi allego la query per overpass-turbo per la visualizzazione dei danni del
terremoto. Ho adattato una già usata per il tifone Haiyan che colpi le
Filippine. Per ora è solo relativa ai buildings, ma può essere rapidamente
adattata anche alle strade o altro.

Ho cercato di seguire la scala di earthquake:damage che è stata discussa in
lista.

Potete vedere un esempio dei risultati su http://overpass-turbo.eu/s/i80.

Se utile posso caricare una copia su GitHub.

FabC




  


  
  
  
  

  


  
  
  
  

  



  
  
  
  

  


  
  
  
  

  


  
  
  
  


{{style:

way[building]
{ color:blue; fill-color:blue;opacity:0.4;
  fill-opacity:0.4;}

way[earthquake:damage=collapsed]
{ color:Yellow; fill-color:darkred;width:1;
  dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=severe]
{ color:Yellow; fill-color:red;width:1;
  dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=moderate]
{ color:Yellow; fill-color:pink;width:1;
  dashes:5,5;opacity:1;fill-opacity:0.8;}

way[earthquake:damage=negligible]
{ color:Yellow; fill-color:MistyRose;width:1;
  dashes:5,5;opacity:1;fill-opacity:0.8;}

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

Re: [Talk-it] overpass xapi e wget

[Martin Raifer]

L'endpoint /xapi/* dell' Overpass API è stato disattivato dopo i
problemi del server due settimane fa: Qualcuno o qualcun' applicazione
fa troppe richieste tipo XAPI. Sarà disattivato fino a quando le
richieste diminuiscono a un livello "normale". Vedi
http://wiki.openstreetmap.org/wiki/Overpass_API/status per ulteriori
informazioni.

Nel frattempo puoi provare ad usare un server alternativo. Per esempio
questo dovrebbe funzionare al momento:
http://overpass.osm.rambler.ru/cgi/xapi/…

2016-08-31 16:11 GMT+02:00 emmexx :
> Ho usato per un po' di anni wget con il seguente url per ottenere i dati
> all'interno di un bbox:
>
> http://www.overpass-api.de/api/xapi?map?bbox=long1,lat1,long2,lat2
>
> Da qualche settimana mi appare un errore:
>
> HTTP request sent, awaiting response... 404 Not Found
>
> E' cambiato qualcosa nelle api? Bisogna usare altri sistemi. Ho guardato
> la documentazione online ma non ho visto avvisi che indicano che questa
> sintassi non e' piu' usata.
>
> grazie
> maxx
>
> ___
> 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-au] Tagging for the router

[Phillip and Kerrie]

I think that the idea that car navigation is for visitors would mean that
it was very important that the routes that get displayed know about local
custom.
My suggestion is that the map data is the best place to store that
information.

On 31 Aug 2016 11:42 PM, "Nick Hocking"  wrote:

> "I'm assuming you mean the Intersection with Lane Cove Rd.
>
> If so it's not permitted to make a u-turn here anyway, as there is no
> sign permitting u-turns at the traffic signals.
>
> So I'd not add it as a restriction as anyone driving there should know
> that they can not make a u-turn there."
>
>
> Ok - since you ask - all routers I just tried , both on osm data and
> commercial data allowed the U-turn at the traffic lights at lane cove
> road.   So do we contact all known writers of routing software and ask them
> to obey the local traffic norms, or do we force their hand and put in the
> restriction.
>
> Actually Gosmore nearly got it right but then spoiled it by doing
> something even more stupid immediately afterwards. I think that routing
> engine need to be made a lot smarter to handle edge cases where drivers can
> evaluate geometry a lot better and accurately than routers.
>
>
> PS - it is my belief that car navigation is mainly for visitors, not
> locals, so I think that routing engines should not try to be aware of local
> customs.
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Jérôme Seigneuret]

A l’intérieur de cette agglomération, "*concernant le code de la route*",
il y a aussi la réglementation de stationnement, l'utilisation de
l'avertisseur sonore, l'utilisation des feux de route, 
Et bien d'autre chose.

Oui en effet,
Le stationnement on le met autrement. Et les avertisseurs sonores et les
feux de route c'est vrai que dans la base c'est pas saisie. Mais bon ok.

Dans ce cas il ne faut oublier d'ajouter la direction de la face par
rapport au nord en dégrée avec le nord à 0 et le sens de rotation horaire.
;-)

Le 31 août 2016 à 20:56, Philippe Verdy  a écrit :

> Et il reste le cas des agglomérations qui ne sont pas des communes mais
> pourtant à cheval entre plusieurs communes (j'en ai vu réellement, les
> panneaux EB10 et EB20 sont différents et il n'y a aucun panneau de sortie
> d'agglomération sur la frontière intercommunale au coeur du village partagé
> entre les deux communes). Ces agglomérations ne sont pas compliquées à
> trouver, souvent ce sont des villages tout en longueur où les habitants
> sont le long de la même route, souvent une départementale, avec quelques
> carrefours pour des voies résidentielles transversales, et parfois un feu
> de signalisation ou un stop si c'est un carrefour de deux départementales.
> La vitesse y est souvent limitée à 70 (avec panneau explicites) sinon 50
> (avec les panneaux EB10 et EB20 seulement).
>
> Il n'y a aucune mairie (même locale) mais souvent quelques commerces de
> proximité (supérette, boulangerie, café-tabac, parfois une station-service)
> et parfois même une petite église ou chapelle : ce village a bien un nom
> mais n'a jamais été une commune, son évolution en agglomération
> (résidentielle, autrefois une ancienne grosse ferme) est assez récente dans
> l'histoire des communes concernées et liée justement à la desserte par
> l'infrastructure routière. La population résidente locale est souvent d'une
> centaine d'habitants environ, parfois un peu plus si on n'est pas loin de
> certaines grandes villes (ce développement est un effet de rurbanisation
> quand les prix de l'immobilier urbain de la ville centre sont trop élevés).
> On trouve aussi des arrêts de bus scolaires.
>
> L'autre cas ce sont des agglomérations rurales décentrées qui se sont
> développées autour de petites gares ferroviaires décentrées, ou autour d'un
> pont ou d'une écluse sur une rivière ou un canal, ou près d'une zone de
> loisirs (étang ou lac de barrage).
>
> Ces villages cependant viennent souvent d'anciennes fermes reconverties en
> habitat après le remembrement des années 1960-1970 et ayant profité de des
> liaisons routières avec une ville proche avant que ne soit créés dans les
> communes concernées les premiers "plans d'occupation des sols" (POS)
> restreignant l'implantation résidentielle et les permis de construire.
> Aujourd'hui ces nouveaux villages ne pourraient plus se développer aussi
> facilement même si la pression immobilière sur le milieu rural reste forte:
> les communes préfèrent rester centrées et éviter l'habitat dispersé et
> tiennent à garder leurs "ceintures vertes" (elles sont soutenues aussi par
> le monde agricole et les assos environnementales).
>
> Le 31 août 2016 à 19:06, Paul Desgranges  a
> écrit :
>
>> Non, je rebondissais sur la discussion sur la défininition des
>> agglomérations et ce que je cherchais à faire c'est de voir s'il était
>> possible de délimiter un zonage simple et uniquement pour la problématique
>> des "panneaux publicitaires scellés au sol", donc ça ne concerne pas les
>> autres formes de publicités, ni les enseignes, ni les préenseignes pour
>> lequelles les règles sont plus compliquées.
>>
>> Ces "panneaux publicitaires scellés au sol" sont interdits dans les
>> agglomérations de moins de 10 000 habitants ne faisant pas partie d'unité
>> urbaine de plus de 100 000 habitants.
>>
>> Il y a 61 unités urbaines de plus de 100 000 habitants en France et elles
>> sont listées par l'INSEE ici  : http://www.insee.fr/fr/themes/
>> tableau.asp?ref_id=NATTEF01204
>> Donc toutes les communes ou agglomérations situées dans ces unités
>> urbaines, et quelques soient leurs populations, sont soumises à la règle
>> des unités urbaines de plus de 100 000 habitants pour ce qui concerne les
>> "panneaux publicitaires scellés au sol" : ils y sont autorisés.
>>
>> En dehors de ces unités urbaines de plus de 100 000 habitants, ces mêmes
>> "panneaux publicitaires scellés au sol" sont autorisés également dans
>> toutes les agglomérations de plus de 10 000 habitants, la population
>> s'évaluant par commune, et par agglomération si la commune est constituée
>> de plusieurs agglomérations.
>> - Exemple 1 : si une agglomération est constituée de 3 communes de 11
>> 000 habitants, 3 000 habitants et 1 000 habitants, par exemple, la
>> population s'évaluant par commune, les "panneaux publicicitaires scellés au
>> sol" ne sont autorisés que dans la première commune.
>> - Exemple 

Re: [Talk-it] Tag preset JOSM x terremoto

[Lorenzo Mastrogiacomi]

Il giorno mer, 31/08/2016 alle 18.49 +0200, Martin Koppenhoefer ha
scritto: 

> 
> 2016-08-31 15:24 GMT+02:00 Martin Koppenhoefer
> :
> 
> > Completely Destroyed > collapsed
> > Highly Damaged > severe
> > Moderately Damaged > moderate
> > Negligible to slight Damage > negligible
> > Not affected > no
> > Not evaluated > not_evaluated
> 
> 
> ottimo, mi sembrano sensati (tranne "not evaluated" forse) ,
> avevo timore che si usasse ancora building=collapsed o
> simili... 
> 
> 
> 
> in realtà da remoto e a solo base di foto aeree si possono distinguere
> soltanto i casi collapsed e severe, forse moderate, il resto non credo
> sia visibile, e non si dovrebbe mettere un "no" o "negligible" o
> "moderate", perché impossibile vederlo su queste foto (i danni
> potrebbero essere alle pareti per esempio).
> 
> 
> Ciao,
> 
> Martin


Inizialmente si era taggato in base alle sole foto usando come valori
collapsed_building e partially_collapsed. Poi con l'ultimo task
inizialmente avevamo a disposizione il solo vettoriale di Copernicus con
gli edifici colorati su una scala di 5 colori:
http://imgur.com/a/cfOfA
perciò ci siamo inventati lo schema sopra. 
Penso sia il caso di mettere su una pagina wiki di documentazione, anche
perché a questo punto mi sembra che questo assomiglia molto ad un
import, almeno per come l'ho interpretato io.

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

Re: [Talk-it] Terremoto Rieti

[Lorenzo Mastrogiacomi]

Il giorno mer, 31/08/2016 alle 00.34 +0200, Alessandro Sarretta ha
scritto:

> Ciao a tutti, mi reinserisco nella conversazione, sperando di non fare
> confusione.
> 
> Intanto vi chiedo se i 3 WMS che sono stati creati (vettoriali dei
> poligoni, merge delle immagini aeree a piccola scale, immagini aeree
> ad alta risoluzione) sono utili per la mappatura oppure se
> effettivamente chi ci lavora non li usa e si scarica pezzo per
> pezzo...
> 
> Io l'ho fatto perché così risultano visibili solamente le ultime
> versioni dei file e uno non si deve smazzare a capire qual è quella
> giusta per mapparci sopra.
> 
> 
> Vi vorrei chiedere però come agire in funzione degli aggiornamenti dei
> dati Copernicus EMS.
> 
> Ad es. oggi hanno aggiornato 4 mappe:
> 
>   * [EMSR177] Capodacqua Aerial: Grading Map 
>   * [EMSR177] Arquata del Tronto Aerial: Grading Map 
>   * [EMSR177] Sant'Angelo Aerial: Grading Map 
>   * [EMSR177] Amatrice Aerial: Grading Map 
> 
> Le prime 3 sono state aggiornate su mia segnalazione, in quanto le
> immagini aeree (e i TIFF ad esempio) mostravano gravi danneggiamenti
> nelle aree, mentre i vettoriali avevano informazioni non compilate o
> incomplete. Ora vettoriali e immagini corrispondono.
> 
> Questo significa che il WMS dei poligoni
> http://osmit3.wmflabs.org/cgi-bin/qgis_mapserv.fcgi?map=/srv/Copernicus/settlements_grading.qgs=WMS=GetCapabilities=1.3
>  non era corretto nelle aree corrispondenti alle mappe aggiornate oggi.
> 
> I WMS delle immagini aeree invece dovrebbero essere validi.
> 
> Io avrei preparato i dati per aggiornare il WMS, ma vorrei sapere se è
> meglio:
> 
>   * creare un nuovo WMS con tutti i dati aggiornati 
>   * sostituire i dati all'interno dello stesso WMS 
>   * creare un WMS nuovo con solamente i layer aggiornati 
> 
> oppure smetterla di inseguire Copernicus e i dati sulle valutazioni
> dei danni tanto non è quello che ci interessa (?).
> 
> 
> Grazie a tutti,
> 
> Ale
> 

Io mi sono affidato ai vettoriali, sicuramente più semplice. Non mi
sembra il caso di mettermi a valutare personalmente quando il lavoro è
già stato fatto a monte. Le immagini comunque utili se c'è da sistemare
le geometrie.

Per me puoi anche aggiornare, vedrò di controllare o sbloccare le tile
interessate. Per il futuro non so...se ci sono modifiche sostanziali e
ci vengono segnalate  possiamo ricontrollarle

Lorenzo


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

Re: [OSM-talk-fr] [OSM-talk-fr-bzh] Arrivée d'un itinéraire de pélerinage en Bretagne à mapper

[Christian Rogel]

> Le 30 août 2016 à 15:54, Christian Rogel  a 
> écrit :
> J’ai le plaisir de vous annoncer qu’Yvon Autret, propriétaire des trace de 
> l’itinéraire moderne du pélerinage du Tro Breiz(h) a achevé leur transfert 
> sur OpenStreetMap sous son nom Yvon Autret.
> 
> Il a réparti les traces GPX en 9 séquences qu’il m’a indiquées ainsi :
> 
> 
> Liste des dépôts :
> 
>// Itinéraire Tro Breizh de St-Pol-de-Léon à Tréguier
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247226 
> 
> 
>// Itinéraire Tro Breizh de Tréguier à Saint-Brieuc
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247229 
> 
> 
>// Itinéraire Tro Breizh de Saint-Brieuc à Saint-Malo
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247232 
> 
> 
>// Itinéraire Tro Breizh de Saint-Malo à Dol-de-Bretagne
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247233 
> 
> 
>// Itinéraire Tro Breizh de Dol-de-Bretagne à Vannes
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247234 
> 
> 
>// Itinéraire Tro Breizh de Vannes à Quimper par Brec'h
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247254 
> 
> 
>// Itinéraire Tro Breizh de Quimper à Saint-Pol-de-Léon
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247258 
> 
> 
>// Variante Tro Breizh de Saint-Anne d'Auray à Hennebont par Erdeven
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247274 
> 
> 
>// Variante Tro Breizh de Quimper à Brasparts par Le Faou
>// http://www.openstreetmap.org/user/Yvon%20Autret/traces/2247275 
> 
> 
> Rappel : le pélerinage comporte 7 étapes, mais les étapes Quimper-St-Pol et 
> Vannes-Quimper sont coupées en deux.
> 
> 
> Ceux qui le souhaitent peuvent donc qualifier sur la carte OSM les tronçons 
> d’itinéraire et créer une relation Tro Breizh (comme le suggérait l’autre 
> Yvon) afin de ne pas empiéter sous les éventuels droits de l’association « 
> Les Chemins du Tro Breiz ».


Yvon Autret apporte les précisions suivntes :
«  Les sections Vannes-Quimper et Quimper-St-Pol ne sont pas coupées en 2. Pour 
ces sections il y a une variante en plus de l'itinéraire normal.
Pour Vannes-Quimper comme il y a beaucoup de routes goudronnées entreSte-Anne 
d'Auray et Hennebont par le chemin direct (Brec'h, Landaul, Landévant), une 
variante par Auray, Erdeven et Merlevenez est proposée.
Même chose entre Quimper et Brasparts. Au lieu de passer par Pleyben,  on 
propose une variante par Locronan, le Menez-Hom, Le Faou, Rumengol. » 

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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Philippe Verdy]

Et il reste le cas des agglomérations qui ne sont pas des communes mais
pourtant à cheval entre plusieurs communes (j'en ai vu réellement, les
panneaux EB10 et EB20 sont différents et il n'y a aucun panneau de sortie
d'agglomération sur la frontière intercommunale au coeur du village partagé
entre les deux communes). Ces agglomérations ne sont pas compliquées à
trouver, souvent ce sont des villages tout en longueur où les habitants
sont le long de la même route, souvent une départementale, avec quelques
carrefours pour des voies résidentielles transversales, et parfois un feu
de signalisation ou un stop si c'est un carrefour de deux départementales.
La vitesse y est souvent limitée à 70 (avec panneau explicites) sinon 50
(avec les panneaux EB10 et EB20 seulement).

Il n'y a aucune mairie (même locale) mais souvent quelques commerces de
proximité (supérette, boulangerie, café-tabac, parfois une station-service)
et parfois même une petite église ou chapelle : ce village a bien un nom
mais n'a jamais été une commune, son évolution en agglomération
(résidentielle, autrefois une ancienne grosse ferme) est assez récente dans
l'histoire des communes concernées et liée justement à la desserte par
l'infrastructure routière. La population résidente locale est souvent d'une
centaine d'habitants environ, parfois un peu plus si on n'est pas loin de
certaines grandes villes (ce développement est un effet de rurbanisation
quand les prix de l'immobilier urbain de la ville centre sont trop élevés).
On trouve aussi des arrêts de bus scolaires.

L'autre cas ce sont des agglomérations rurales décentrées qui se sont
développées autour de petites gares ferroviaires décentrées, ou autour d'un
pont ou d'une écluse sur une rivière ou un canal, ou près d'une zone de
loisirs (étang ou lac de barrage).

Ces villages cependant viennent souvent d'anciennes fermes reconverties en
habitat après le remembrement des années 1960-1970 et ayant profité de des
liaisons routières avec une ville proche avant que ne soit créés dans les
communes concernées les premiers "plans d'occupation des sols" (POS)
restreignant l'implantation résidentielle et les permis de construire.
Aujourd'hui ces nouveaux villages ne pourraient plus se développer aussi
facilement même si la pression immobilière sur le milieu rural reste forte:
les communes préfèrent rester centrées et éviter l'habitat dispersé et
tiennent à garder leurs "ceintures vertes" (elles sont soutenues aussi par
le monde agricole et les assos environnementales).

Le 31 août 2016 à 19:06, Paul Desgranges  a
écrit :

> Non, je rebondissais sur la discussion sur la défininition des
> agglomérations et ce que je cherchais à faire c'est de voir s'il était
> possible de délimiter un zonage simple et uniquement pour la problématique
> des "panneaux publicitaires scellés au sol", donc ça ne concerne pas les
> autres formes de publicités, ni les enseignes, ni les préenseignes pour
> lequelles les règles sont plus compliquées.
>
> Ces "panneaux publicitaires scellés au sol" sont interdits dans les
> agglomérations de moins de 10 000 habitants ne faisant pas partie d'unité
> urbaine de plus de 100 000 habitants.
>
> Il y a 61 unités urbaines de plus de 100 000 habitants en France et elles
> sont listées par l'INSEE ici  : http://www.insee.fr/fr/themes/
> tableau.asp?ref_id=NATTEF01204
> Donc toutes les communes ou agglomérations situées dans ces unités
> urbaines, et quelques soient leurs populations, sont soumises à la règle
> des unités urbaines de plus de 100 000 habitants pour ce qui concerne les
> "panneaux publicitaires scellés au sol" : ils y sont autorisés.
>
> En dehors de ces unités urbaines de plus de 100 000 habitants, ces mêmes
> "panneaux publicitaires scellés au sol" sont autorisés également dans
> toutes les agglomérations de plus de 10 000 habitants, la population
> s'évaluant par commune, et par agglomération si la commune est constituée
> de plusieurs agglomérations.
> - Exemple 1 : si une agglomération est constituée de 3 communes de 11
> 000 habitants, 3 000 habitants et 1 000 habitants, par exemple, la
> population s'évaluant par commune, les "panneaux publicicitaires scellés au
> sol" ne sont autorisés que dans la première commune.
> - Exemple 2 : si une commune est constituée de 3 agglomérations de 7
> 000 habitants, 3 000 habitants et 1 000 habitants, alors les "panneaux
> publicicitaires scellés au sol" sont interdits dans toutes les
> agglomérations de la commune.
>
> Cdlt
> Paul
>
> On 31/08/2016 17:53, Christian Quest wrote:
>
>> J'avoue m'y perdre dans les descriptions... et ce qu'on cherche à
>> identifier.
>>
>> J'ai trouvé ce document assez compréhensible:
>> http://www.cher.gouv.fr/content/download/9302/62414/file/
>> Pblicite_plaquette_information_2014.pdf
>>
>> Les unités urbaines de plus 100.000 habitants, il n'y en a pas des
>> centaines, les identifier ne devrait pas être bien complexe.
>>
>> Ensuite, hors de ces unités urbaines, 

Re: [OSM-talk-nl] Tagging van winkel-ketens

[Ronald Stroethoff]

Misschien ben ik niet duidelijk geweest, op de pagina 
https://wiki.openstreetmap.org/wiki/WikiProject_Netherlands/Shops

moet het aantal winkels van multivlaai en supervlaai bijgewerkt worden.
Er staan in openstreetmap inmiddels wat meer.

Johan C wrote:

> Voor diegeen die Multivlaai en Supervlaai wil bijwerken:
> https://openkvk.nl/zoeken/Multivlaai  /
> https://openkvk.nl/zoeken/Supervlaai
> 
> Gr., Johan
> 
> Op 31 augustus 2016 19:07 schreef Ronald Stroethoff
> :
> 
>> Ik las op deze webpagina:
>> http://forum.openstreetmap.org/viewtopic.php?id=33909
>> een discussie over het taggen van winkelketens.
>> Iemand vermelde dat hij de volgende webpagina heeft bijgewerkt:
>> https://wiki.openstreetmap.org/wiki/WikiProject_Netherlands/Shops
>>
>> Op deze webpagina komt ook de volgende tekst voor:
>> shop=bakery
>> Multivlaai (9x)
>>
>> Ik hoop dat iemand tijd kan vinden om dit aantal bij te werken, het zijn
>> er inmiddels wat meer geworden.
>> En kan dan ook de winkelketen supervlaai erbij genoemd worden?
>>
>>
>> ___
>> Talk-nl mailing list
>> Talk-nl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-nl
>>



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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[JurKis]

"kuomet užsidėjęs ant auto stogo bagažinę ("cepeliną") nuvažiavau pasiimti
grynų į bankomatą". Atsiprašau, žvingtelėjau 
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Žilvinas Jonaitis]

> Sutinku su Tomu, kad tvarka žymėjimuose yra geriau negu įkyrūs
> validatoriai. Tačiau žiūrint iš praktinės naudos pusės, ji realiame
> gyvenime, mano nuomone, yra minimali, nes ši informacija naudinga tik
> sunkvežimių maršrutizatoriams, kuriuose galima nustatyti transporto
> priemonės realų aukštį. Bent jau man neteko susidurti su plataus vartojimo
> maršrutizatoriais, kurie turėtų tokią galimybę. Pritariu Aidui, kad aukštų
> ir nestandartinių transporto priemonių vairuotojai vargu ar pasitikėtų OSM
> informacija, o komerciniam transportui yra skirtos komercinės priemonės.
> Bet dėl bendros tvarkos, esant galimybei ir ženklui, manau, tikrai nesunku
> tokį žymėjimą atlikti. Beje, jeigu jau daryti tvarką  [čia anas laiškas
> pabėgo nepabaigtas:)], tai, ar nevertėtų aukščio apribojimus sudėlioti ir
> prie požeminių/daugiaaukščių automobilių stovėjimo aikštelių?  Gal ateityje
> paprasti maršrutizatoriai turės aukščio nustatymo galimybę ir tuomet ši
> info bus naudinga paprastiems mirtingiems.
>

Turėjau čia tokį linksmą-pamokančią gyvenimo patirtį, kuomet užsidėjęs ant
auto stogo bagažinę ("cepeliną") nuvažiavau pasiimti grynų į bankomatą.
Kadangi arčiausiai tuo metu buvo Panoramos bankomatas, tai iš įpročio
įlėkiau į -2 per maxheight=2 apribojimą. Aišku išgirdau kaip kabantis
aukščio kontrolės barjeras nučiuožė bagažinės stogu, bet atbulas išvažiuoti
jau nesugebėjau. Teko atsargiai leistis gilyn į aikštelę ir bandyti laimę
pasiekti jos išvažiavimą. Deja, sraigės greičiu paklaidžiojęs po -2 aukštą
ir padaręs šiokią tokią žvalgybą kojomis, supratau, kad jokių šansų
išsikapstyti nėra išskyrus tuo pačiu keliu kaip įvažiavau. Tad, dar kartą
braukiant aukščio barjerą, teko prieš eismą išlįsti į atgal laisvę :).
Dabar bent jau žinau, kad 2,13 m yra galimas, bet ne praktiškas parkavimosi
aukštis Panoramos -2 aukšte. :D

Linkėjimai,
Žilvinas



>
> 2016 m. rugpjūčio 31 d. 11:20, Tomas Straupis 
> rašė:
>
>> Sveiki
>>
>>   Gal turite minčių, kur būtų galima rasti tunelių/tiltų aukščius?
>>
>>   Norisi užpildyti tuneliams „maxheight“ žymą, kad validatoriai
>> nebesikabinėtų ir kad sunkvežimių maršrutizatoriai žinotų, kur
>> pravažiuoti galima/negalima.
>>
>> --
>> Tomas
>>
>> ___
>> Talk-lt mailing list
>> Talk-lt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-lt
>>
>
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Žilvinas Jonaitis]

Sveiki,

Sutinku su Tomu, kad tvarka žymėjimuose yra geriau negu įkyrūs
validatoriai. Tačiau žiūrint iš praktinės naudos pusės, ji realiame
gyvenime, mano nuomone, yra minimali, nes ši informacija naudinga tik
sunkvežimių maršrutizatoriams, kuriuose galima nustatyti transporto
priemonės realų aukštį. Bent jau man neteko susidurti su plataus vartojimo
maršrutizatoriais, kurie turėtų tokią galimybę. Pritariu Aidui, kad aukštų
ir nestandartinių transporto priemonių vairuotojai vargu ar pasitikėtų OSM
informacija, o komerciniam transportui yra skirtos komercinės priemonės.
Bet dėl bendros tvarkos, esant galimybei ir ženklui, manau, tikrai nesunku
tokį žymėjimą atlikti. Beje, jeigu jau daryti tvarką

2016 m. rugpjūčio 31 d. 11:20, Tomas Straupis 
rašė:

> Sveiki
>
>   Gal turite minčių, kur būtų galima rasti tunelių/tiltų aukščius?
>
>   Norisi užpildyti tuneliams „maxheight“ žymą, kad validatoriai
> nebesikabinėtų ir kad sunkvežimių maršrutizatoriai žinotų, kur
> pravažiuoti galima/negalima.
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-in] India - Bangladesh enclaves/exclaves on OSM

[Arun Ganesh]

Wow, thats the first time I'm seeing a boundary agreement document and its
fascinating to read. And pretty impressive from the MEA, thanks for sharing.

On Wed, Aug 31, 2016 at 3:49 PM, Devdatta Tengshe 
wrote:

> Here is a more readable document from the MEA: https://www.mea.gov.in/
> Uploads/PublicationDocs/24529_LBA_MEA_Booklet_final.pdf
>
> Regards,
> Devdatta
>
> On Wed, Aug 31, 2016 at 3:12 PM, Devdatta Tengshe 
> wrote:
>
>> You can get the list of enclaves in the actual 1974 agrement which was
>> signed, and is mentioned in the 119th Amendment of the Constitution.
>>
>> You can get more details here: http://www.prsindia.org/
>> billtrack/the-constitution-119th-amendment-bill-2013-3049/
>>
>> The actual list is present pg 5 onward in this pdf:
>> http://www.prsindia.org/uploads/media/Constitution%2011
>> 9/Constitution%20%28119th%29%20Bill,%202013.pdf
>>
>>
>>
>> Regards,
>> Devdatta
>>
>> On Wed, Aug 31, 2016 at 2:50 PM, Jinal Foflia 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Came across this blog [1] on the enclaves and exclaves issue related to
>>> India - Bangladesh. Do we have any official document about the swap of
>>> enclaves between Bangladesh and India? Also the data on OpenStreetMap says
>>> that we have 2 remaining exclaves, was there a complete swap of
>>> enclaves/exclaves? How should the data be updated on OSM?
>>>
>>>
>>>
>>> [1] - http://www.gearthblog.com/blog/archives/2016/08/india-bang
>>> ladesh-enclaves.html
>>>
>>> Some more articles (These are articles from different sources)
>>>
>>> - https://www.washingtonpost.com/news/worldviews/wp/2015/08/
>>> 01/say-goodbye-to-the-weirdest-border-dispute-in-the-world/?tid=a_inl
>>> - http://zeenews.india.com/news/west-bengal/celebrations-erupt
>>> -in-cooch-behar-after-india-bangladesh-ratify-lba_1608611.html
>>> - http://zeenews.india.com/tags/land-boundary-agreement.html
>>> - http://www.thehindu.com/news/national/indiabangladesh-land-b
>>> oundary-agreement-security-a-prime-concern-after-enclaves-ex
>>> change/article7491756.ece
>>>
>>> Cheers,
>>> Jinal Foflia
>>>
>>> ___
>>> Talk-in mailing list
>>> Talk-in@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-in
>>>
>>>
>>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk] Mailing lists archive not in Google

[Matthijs Melissen]

On 31 August 2016 at 18:32, Andy Townsend  wrote:
> Maybe I'm missing something, but a web search of e.g. "something
> site:https://lists.openstreetmap.org/pipermail/talk/; finds relevant posts?
> Is there something I'm not understanding here?

You're right, something must have gone wrong on my side.

-- Matthijs

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

Re: [OSM-talk-nl] Tagging van winkel-ketens

[Johan C]

Voor diegeen die Multivlaai en Supervlaai wil bijwerken:
https://openkvk.nl/zoeken/Multivlaai  /
https://openkvk.nl/zoeken/Supervlaai

Gr., Johan

Op 31 augustus 2016 19:07 schreef Ronald Stroethoff :

> Ik las op deze webpagina:
> http://forum.openstreetmap.org/viewtopic.php?id=33909
> een discussie over het taggen van winkelketens.
> Iemand vermelde dat hij de volgende webpagina heeft bijgewerkt:
> https://wiki.openstreetmap.org/wiki/WikiProject_Netherlands/Shops
>
> Op deze webpagina komt ook de volgende tekst voor:
> shop=bakery
> Multivlaai (9x)
>
> Ik hoop dat iemand tijd kan vinden om dit aantal bij te werken, het zijn er
> inmiddels wat meer geworden.
> En kan dan ook de winkelketen supervlaai erbij genoemd worden?
>
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Tagging van winkel-ketens

[Ronald Stroethoff]

Ik las op deze webpagina:
http://forum.openstreetmap.org/viewtopic.php?id=33909
een discussie over het taggen van winkelketens.
Iemand vermelde dat hij de volgende webpagina heeft bijgewerkt:
https://wiki.openstreetmap.org/wiki/WikiProject_Netherlands/Shops

Op deze webpagina komt ook de volgende tekst voor:
shop=bakery
Multivlaai (9x)

Ik hoop dat iemand tijd kan vinden om dit aantal bij te werken, het zijn er 
inmiddels wat meer geworden.
En kan dan ook de winkelketen supervlaai erbij genoemd worden?


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

Re: [OSM-talk-fr] mhs:inscription_date et osmose

[David Crochet]

Bonjour


Le 31/08/2016 à 08:53, Ralf Treinen a écrit :

Il y a aussi la question des MH inscrits/classés plusieurs fois (par
exemple des parties différentes d'un bâtiment), ou inscrit d'abord et
classé plus tard. Dans ces cas, on prend quelle date ? Seulement la
dernière, ou toutes les dates séparées par ";" ?


Pour moi, OSM, c'est : " aujourd'hui, c'est quoi. Ok, donc c'est dans 
OSM comme çà"


un MHS avant, des photos, des descritif, des notes, c'est une autre base 
de données (base du ministère par exemple).


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Paul Desgranges]

Non, je rebondissais sur la discussion sur la défininition des 
agglomérations et ce que je cherchais à faire c'est de voir s'il était 
possible de délimiter un zonage simple et uniquement pour la 
problématique des "panneaux publicitaires scellés au sol", donc ça ne 
concerne pas les autres formes de publicités, ni les enseignes, ni les 
préenseignes pour lequelles les règles sont plus compliquées.


Ces "panneaux publicitaires scellés au sol" sont interdits dans les 
agglomérations de moins de 10 000 habitants ne faisant pas partie 
d'unité urbaine de plus de 100 000 habitants.


Il y a 61 unités urbaines de plus de 100 000 habitants en France et 
elles sont listées par l'INSEE ici  : 
http://www.insee.fr/fr/themes/tableau.asp?ref_id=NATTEF01204
Donc toutes les communes ou agglomérations situées dans ces unités 
urbaines, et quelques soient leurs populations, sont soumises à la règle 
des unités urbaines de plus de 100 000 habitants pour ce qui concerne 
les "panneaux publicitaires scellés au sol" : ils y sont autorisés.


En dehors de ces unités urbaines de plus de 100 000 habitants, ces mêmes 
"panneaux publicitaires scellés au sol" sont autorisés également dans 
toutes les agglomérations de plus de 10 000 habitants, la population 
s'évaluant par commune, et par agglomération si la commune est 
constituée de plusieurs agglomérations.
- Exemple 1 : si une agglomération est constituée de 3 communes de 
11 000 habitants, 3 000 habitants et 1 000 habitants, par exemple, la 
population s'évaluant par commune, les "panneaux publicicitaires scellés 
au sol" ne sont autorisés que dans la première commune.
- Exemple 2 : si une commune est constituée de 3 agglomérations de 
7 000 habitants, 3 000 habitants et 1 000 habitants, alors les "panneaux 
publicicitaires scellés au sol" sont interdits dans toutes les 
agglomérations de la commune.


Cdlt
Paul

On 31/08/2016 17:53, Christian Quest wrote:
J'avoue m'y perdre dans les descriptions... et ce qu'on cherche à 
identifier.


J'ai trouvé ce document assez compréhensible: 
http://www.cher.gouv.fr/content/download/9302/62414/file/Pblicite_plaquette_information_2014.pdf


Les unités urbaines de plus 100.000 habitants, il n'y en a pas des 
centaines, les identifier ne devrait pas être bien complexe.


Ensuite, hors de ces unités urbaines, on a les agglomérations de plus 
de 1 habitants, qui peuvent s'étendre sur plusieurs communes ou 
n'être qu'une partie d'une commune... ce que j'ai essayé de retrouver 
en n'utilisant justement pas les limites de communes mais le cumul des 
habitants par carreau de 200m.


De toute façon, je pense que l'on ne peut que faire une pré-sélection 
des agglomérations de plus de 1 habitants, sans connaitre leur 
limite bien précisément. Cela permettra déjà d'identifier de très 
nombreuses zones comme ne pouvant pas avoir de publicité scellée au sol.




Le 31/08/2016 à 16:41, Paul Desgranges a écrit :


Je comprends l'idée, et merci de me montrer les possibilités de 
postgis !  Et des données carroyées ! Effectivement on peut faire 
beaucoup !!


Mais les infractions au Code de l'environnement relatifs à 
l'affichage illégal ("panneaux publicitaires scellés au sol" hors 
agglomération par exemple) sont jugés par les Tribunaux 
Administratifs (TA) , et devant les TA, il n'y a pas de "en gros" :


 - en cas de litige sur le périmètre de l'agglomération 
(agglomération administrative et agglomération géographique ne 
coïncident pas), c'est la situation physique réellement constatée qui 
fait foi.  (Mais là, OSM pourrait aider à définir le périmètre des 
agglomérations, comme tu l'as fait.)


- la population ne peut pas être estimée par carreaux de 200m de 
coté, car la population d'une agglomération est évaluée 'par 
commune'  (les carreaux de 200 m de coté peuvent être à cheval entre 
plusieurs communes), et uniquement pour la partie agglomérée de la 
commune. D'autre part, si la commune est constituée de plusieurs 
agglomérations, il faut évaluer la population 'par agglomération'. 
C'est alors le maire qui est sollicité pour fournir ces données qui 
n'existent pas par ailleurs.


C'est pour ça que les publicitaires/afficheurs ont la vie belle, et 
peuvent faire pratiquement ce qu'ils veulent, et enfreindre la loi en 
toute connaissance de cause ; le Code de l'environnement est 
suffisammemnt complexe et les régles d'agglomération et de population 
sont difficiles à estimer, il faut plusieurs années parfois pour 
faire aboutir un dossier. De plus, les préfets sont passifs, ils 
laissent faire  et n'interviennent que lorsqu'une association de 
défense de paysage porte plainte. Mais quand ça se produit, les 
préfets se font à chaque fois condamner ; car ils ne font pas 
respecter la réglementation que l'Etat (c'est à dire eux-mêmes) a mis 
en place.



Donc pour résumer, ce qui peut intéresser une association de défense 
de paysage, ce sont les périmètres précis des agglomérations de plus 
de 10 000 habitants en dehors des 

Re: [Talk-it] Terremoto Rieti

[girarsi_liste]

Grazie ancora per l'info.

-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-it] Tag preset JOSM x terremoto

[Martin Koppenhoefer]

2016-08-31 15:24 GMT+02:00 Martin Koppenhoefer :

> > Completely Destroyed > collapsed
> > Highly Damaged > severe
> > Moderately Damaged > moderate
> > Negligible to slight Damage > negligible
> > Not affected > no
> > Not evaluated > not_evaluated
>
>
> ottimo, mi sembrano sensati (tranne "not evaluated" forse) , avevo timore
> che si usasse ancora building=collapsed o simili...



in realtà da remoto e a solo base di foto aeree si possono distinguere
soltanto i casi collapsed e severe, forse moderate, il resto non credo sia
visibile, e non si dovrebbe mettere un "no" o "negligible" o "moderate",
perché impossibile vederlo su queste foto (i danni potrebbero essere alle
pareti per esempio).

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

Re: [Talk-it] Terremoto Rieti

[Fabrizio Tambussa]

Tornato UP adesso. C'è stata una manutenzione nella server farm che ha
comportato circa un'ora di fuori linea.

Saluti

Il 31/Ago/2016 18:00, "girarsi_liste"  ha scritto:

> Il 31/08/2016 17:45, Stefano ha scritto:
> > Mi comunicano dalla regia che è in corso una manutenzione sulla rete e
> > tornerà online verso le 6
> >
> > Stefano
>
> Ok, meglio così, pensavo ad un'altro attacco come overpass.
>
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> 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: [OSM-talk] Mailing lists archive not in Google

[Andy Townsend]

On 31/08/2016 17:23, Matthijs Melissen wrote:

Hi,

The mailing list archives at
https://lists.openstreetmap.org/pipermail/ are currently not indexed
by Google. I suppose this is caused by the  tag that is included in every page of the
archive.


Maybe I'm missing something, but a web search of e.g. "something 
site:https://lists.openstreetmap.org/pipermail/talk/; finds relevant 
posts?  Is there something I'm not understanding here?


Cheers,
Andy


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

Re: [Talk-ca] broken forests in eastern Canada

[James]

If anyone has anything to add:
http://wiki.openstreetmap.org/wiki/WikiProject_Canada#What.27s_with_the_forests_in_Canada.3F

On Wed, Aug 31, 2016 at 11:53 AM, Sam Dyck  wrote:

> Or even a just a section of the Wikiproject Canada page.
>
> On Wed, Aug 31, 2016 at 10:50 AM, James  wrote:
>
>> We could add it as a subpage to: http://wiki.openstreetmap.org/
>> wiki/WikiProject_Canada seeing as it involves all of Canada and list out
>> why it's this way etc
>>
>> On Wed, Aug 31, 2016 at 10:40 AM, Begin Daniel 
>> wrote:
>>
>>> “Whats up with the forests in Canada?” A wiki page is a good idea!
>>>
>>>
>>>
>>> And while talking about forest in eastern Canada…
>>>
>>>
>>>
>>> It would be very helpful to have a plugin in JOSM that deals with Canvec
>>> water/wooded area integration in multipolygon.  I am not really a developer
>>> but since the merging operations are repeated over and over again over
>>> large areas... might it be possible to do something?
>>>
>>>
>>>
>>> On the same topic, it has been suggested to split wooded areas in
>>> smaller chunks by using features on the ground as outer limits (mostly
>>> roads, streams, rivers) and get rid of arbitrary rectangles from Canvec. Is
>>> it something we are aiming at?
>>>
>>>
>>>
>>> Daniel
>>>
>>>
>>>
>>> *From:* john whelan [mailto:jwhelan0...@gmail.com]
>>> *Sent:* Wednesday, 31 August, 2016 07:00
>>> *To:* Sam Dyck
>>> *Cc:* Talk-CA OpenStreetMap
>>> *Subject:* Re: [Talk-ca] broken forests in eastern Canada
>>>
>>>
>>>
>>> > we need to have a "Whats up with the forests in Canada?" page on the
>>> wiki to explain our situation and how we've tried to deal with it
>>>
>>> Sounds like a plan.
>>>
>>> Cheerio John
>>>
>>>
>>>
>>> On 30 August 2016 at 22:41, Sam Dyck  wrote:
>>>
>>> After reading through the changeset discussion, I discovered that one of
>>> my imports in Northern Manitoba made Worst of OSM. (
>>> http://worstofosm.tumblr.com/post/22180046353/dear-openstre
>>> etmap-isnt-it-strange-how-the). As someone who spends a some time
>>> amount of time in some of relatively unpopulated areas of Canada and makes
>>> an effort to check the quality of Canvec data (which is usually pretty
>>> good), I do agree that it is impossible to do everything to the same level
>>> of quality that we would provide in Toronto or Timmins or even small
>>> prairie towns.
>>>
>>> One of the things that seems to bother Nakaner and the WoO people (if I
>>> may put words in their mouths) is that the boundaries are a bit funky in
>>> Canvec. Forests, lakes and wetlands spill into each other, and they are
>>> often out of alignment with the Bing imagery. In some ways this reflects a
>>> degree of natural ambiguity: if we look at the above Hudson's bay
>>> coastline, their is hourly variation in coastlines, and even the long term
>>> patterns change over time. The Manitoba-Nunavut boundary is more or less
>>> fixed by so we can't correct it, and a glance at satellite imagery shows
>>> that the vegetation tends to be spaced off of the shoreline.
>>>
>>> That being said sometimes there is some weird stuff happening in Canvec
>>> data that is out of sync with what is on the ground. These should be
>>> corrected when detected, but are rare enough that they shouldn't be a
>>> problem. I confess I haven't always been great in following the rules when
>>> doing imports (I think the last few years I've been fully in compliance),
>>> and have sometimes caused problems, people on this list have generally
>>> understanding. Perhaps we need to have a "Whats up with the forests in
>>> Canada?" page on the wiki to explain our situation and how we've tried to
>>> deal with it.
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-be] newsletter, issue 2

[joost schouppe]

Hi,

I made a draft for the next post to our 300 member newsletter subscribers.

Feel free to check, extend and/or translate to Dutch and French.

https://hackpad.com/OSMbe-Newsletter-2-S6stsFmKCCn



-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

[OSM-talk] Mailing lists archive not in Google

[Matthijs Melissen]

Hi,

The mailing list archives at
https://lists.openstreetmap.org/pipermail/ are currently not indexed
by Google. I suppose this is caused by the  tag that is included in every page of the
archive.

Would it be possible to remove this tag? I think it would be very
useful if the mailing list archives were searchable.

-- Matthijs

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

Re: [Talk-it] taginfo Italia

[Martin Koppenhoefer]

sent from a phone

> Il giorno 31 ago 2016, alle ore 18:07, Alessandro  ha 
> scritto:
> 
> E' una macchina remota o si potrebbe fare un minicolletta per comprare 
> qualche giga di ram? (o se non sono ram ECC potrei spedirtene gratis qualcuna 
> se sono DDR2 o DDR3)


la macchina è di Simone Cortesi, e credo sta in un collocation da wikimedia it 
(non lo so per certo dove fisicamente sta)

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

Re: [Talk-it] taginfo Italia

[Volker Schmidt]

A che cosa servono taginfo regionali?

Volker

2016-08-31 17:57 GMT+02:00 Martin Koppenhoefer :

> Come forse avete già scoperto, da qualche settimana non funziona più il
> nostro taginfo regionale. Si sono cambiate alcune cose upstream e non ho
> ancora avuto modo di fare gli aggiornamenti sulle 20 istanze che abbiamo
> per la versione regionale.
>
> Francamente sarebbe più facile avere una versione italiana unica per tutto
> il paese, cosa ne pensate?
>
> Il problema con la versione nazionale era che non ci sta RAM a sufficienza
> sulla macchina in uso attualmente.
>
> Ciao,
> Martin
>
> sent from a phone
> ___
> 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] taginfo Italia

[Alessandro]

Il 31/08/2016 17:57, Martin Koppenhoefer ha scritto:



Il problema con la versione nazionale era che non ci sta RAM a sufficienza 
sulla macchina in uso attualmente.



E' una macchina remota o si potrebbe fare un minicolletta per comprare 
qualche giga di ram? (o se non sono ram ECC potrei spedirtene gratis 
qualcuna se sono DDR2 o DDR3)


Alessandro

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

Re: [Talk-it] taginfo Italia

[girarsi_liste]

Il 31/08/2016 17:57, Martin Koppenhoefer ha scritto:
> Come forse avete già scoperto, da qualche settimana non funziona più il 
> nostro taginfo regionale. Si sono cambiate alcune cose upstream e non ho 
> ancora avuto modo di fare gli aggiornamenti sulle 20 istanze che abbiamo per 
> la versione regionale.
> 
> Francamente sarebbe più facile avere una versione italiana unica per tutto il 
> paese, cosa ne pensate?
> 
> Il problema con la versione nazionale era che non ci sta RAM a sufficienza 
> sulla macchina in uso attualmente.
> 

Sono d'acordo a metà, nel senso, la cernita regionale ha senso solo per
particolarità regionali, mentre le descrizioni italiane generalmente
valgono per tutto il territorio.

Per cui chiedo se è possibile creare un'interfaccia diversa, cioè con
query risolte per tutto il territorio nazionale, mentre possibilità,
magari tramite un menu a discesa, di selezionare una regione o più
regioni, con metodo avanzato, o pagina dedicata a ciò.


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-it] Terremoto Rieti

[girarsi_liste]

Il 31/08/2016 17:45, Stefano ha scritto:
> Mi comunicano dalla regia che è in corso una manutenzione sulla rete e
> tornerà online verso le 6
> 
> Stefano

Ok, meglio così, pensavo ad un'altro attacco come overpass.


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

[Talk-it] taginfo Italia

[Martin Koppenhoefer]

Come forse avete già scoperto, da qualche settimana non funziona più il nostro 
taginfo regionale. Si sono cambiate alcune cose upstream e non ho ancora avuto 
modo di fare gli aggiornamenti sulle 20 istanze che abbiamo per la versione 
regionale.

Francamente sarebbe più facile avere una versione italiana unica per tutto il 
paese, cosa ne pensate?

Il problema con la versione nazionale era che non ci sta RAM a sufficienza 
sulla macchina in uso attualmente.

Ciao,
Martin 

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

Re: [Talk-ca] broken forests in eastern Canada

[Sam Dyck]

Or even a just a section of the Wikiproject Canada page.

On Wed, Aug 31, 2016 at 10:50 AM, James  wrote:

> We could add it as a subpage to: http://wiki.openstreetmap.org/
> wiki/WikiProject_Canada seeing as it involves all of Canada and list out
> why it's this way etc
>
> On Wed, Aug 31, 2016 at 10:40 AM, Begin Daniel  wrote:
>
>> “Whats up with the forests in Canada?” A wiki page is a good idea!
>>
>>
>>
>> And while talking about forest in eastern Canada…
>>
>>
>>
>> It would be very helpful to have a plugin in JOSM that deals with Canvec
>> water/wooded area integration in multipolygon.  I am not really a developer
>> but since the merging operations are repeated over and over again over
>> large areas... might it be possible to do something?
>>
>>
>>
>> On the same topic, it has been suggested to split wooded areas in smaller
>> chunks by using features on the ground as outer limits (mostly roads,
>> streams, rivers) and get rid of arbitrary rectangles from Canvec. Is it
>> something we are aiming at?
>>
>>
>>
>> Daniel
>>
>>
>>
>> *From:* john whelan [mailto:jwhelan0...@gmail.com]
>> *Sent:* Wednesday, 31 August, 2016 07:00
>> *To:* Sam Dyck
>> *Cc:* Talk-CA OpenStreetMap
>> *Subject:* Re: [Talk-ca] broken forests in eastern Canada
>>
>>
>>
>> > we need to have a "Whats up with the forests in Canada?" page on the
>> wiki to explain our situation and how we've tried to deal with it
>>
>> Sounds like a plan.
>>
>> Cheerio John
>>
>>
>>
>> On 30 August 2016 at 22:41, Sam Dyck  wrote:
>>
>> After reading through the changeset discussion, I discovered that one of
>> my imports in Northern Manitoba made Worst of OSM. (
>> http://worstofosm.tumblr.com/post/22180046353/dear-openstre
>> etmap-isnt-it-strange-how-the). As someone who spends a some time amount
>> of time in some of relatively unpopulated areas of Canada and makes an
>> effort to check the quality of Canvec data (which is usually pretty good),
>> I do agree that it is impossible to do everything to the same level of
>> quality that we would provide in Toronto or Timmins or even small prairie
>> towns.
>>
>> One of the things that seems to bother Nakaner and the WoO people (if I
>> may put words in their mouths) is that the boundaries are a bit funky in
>> Canvec. Forests, lakes and wetlands spill into each other, and they are
>> often out of alignment with the Bing imagery. In some ways this reflects a
>> degree of natural ambiguity: if we look at the above Hudson's bay
>> coastline, their is hourly variation in coastlines, and even the long term
>> patterns change over time. The Manitoba-Nunavut boundary is more or less
>> fixed by so we can't correct it, and a glance at satellite imagery shows
>> that the vegetation tends to be spaced off of the shoreline.
>>
>> That being said sometimes there is some weird stuff happening in Canvec
>> data that is out of sync with what is on the ground. These should be
>> corrected when detected, but are rare enough that they shouldn't be a
>> problem. I confess I haven't always been great in following the rules when
>> doing imports (I think the last few years I've been fully in compliance),
>> and have sometimes caused problems, people on this list have generally
>> understanding. Perhaps we need to have a "Whats up with the forests in
>> Canada?" page on the wiki to explain our situation and how we've tried to
>> deal with it.
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
>
> --
> 外に遊びに行こう！
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Terremoto Rieti

[Stefano]

Il giorno 31 agosto 2016 17:26, girarsi_liste  ha
scritto:

> Ho provato ad accedere al task 15 adesso, mi da 502 Bad Gateway, è stato
> chiuso?
>

Mi comunicano dalla regia che è in corso una manutenzione sulla rete e
tornerà online verso le 6

Stefano

>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> 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: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Christian Quest]

J'avoue m'y perdre dans les descriptions... et ce qu'on cherche à 
identifier.


J'ai trouvé ce document assez compréhensible: 
http://www.cher.gouv.fr/content/download/9302/62414/file/Pblicite_plaquette_information_2014.pdf


Les unités urbaines de plus 100.000 habitants, il n'y en a pas des 
centaines, les identifier ne devrait pas être bien complexe.


Ensuite, hors de ces unités urbaines, on a les agglomérations de plus de 
1 habitants, qui peuvent s'étendre sur plusieurs communes ou n'être 
qu'une partie d'une commune... ce que j'ai essayé de retrouver en 
n'utilisant justement pas les limites de communes mais le cumul des 
habitants par carreau de 200m.


De toute façon, je pense que l'on ne peut que faire une pré-sélection 
des agglomérations de plus de 1 habitants, sans connaitre leur 
limite bien précisément. Cela permettra déjà d'identifier de très 
nombreuses zones comme ne pouvant pas avoir de publicité scellée au sol.




Le 31/08/2016 à 16:41, Paul Desgranges a écrit :


Je comprends l'idée, et merci de me montrer les possibilités de 
postgis !  Et des données carroyées ! Effectivement on peut faire 
beaucoup !!


Mais les infractions au Code de l'environnement relatifs à l'affichage 
illégal ("panneaux publicitaires scellés au sol" hors agglomération 
par exemple) sont jugés par les Tribunaux Administratifs (TA) , et 
devant les TA, il n'y a pas de "en gros" :


 - en cas de litige sur le périmètre de l'agglomération (agglomération 
administrative et agglomération géographique ne coïncident pas), c'est 
la situation physique réellement constatée qui fait foi.  (Mais là, 
OSM pourrait aider à définir le périmètre des agglomérations, comme tu 
l'as fait.)


- la population ne peut pas être estimée par carreaux de 200m de coté, 
car la population d'une agglomération est évaluée 'par commune'  (les 
carreaux de 200 m de coté peuvent être à cheval entre plusieurs 
communes), et uniquement pour la partie agglomérée de la commune. 
D'autre part, si la commune est constituée de plusieurs 
agglomérations, il faut évaluer la population 'par agglomération'. 
C'est alors le maire qui est sollicité pour fournir ces données qui 
n'existent pas par ailleurs.


C'est pour ça que les publicitaires/afficheurs ont la vie belle, et 
peuvent faire pratiquement ce qu'ils veulent, et enfreindre la loi en 
toute connaissance de cause ; le Code de l'environnement est 
suffisammemnt complexe et les régles d'agglomération et de population 
sont difficiles à estimer, il faut plusieurs années parfois pour faire 
aboutir un dossier. De plus, les préfets sont passifs, ils laissent 
faire  et n'interviennent que lorsqu'une association de défense de 
paysage porte plainte. Mais quand ça se produit, les préfets se font à 
chaque fois condamner ; car ils ne font pas respecter la 
réglementation que l'Etat (c'est à dire eux-mêmes) a mis en place.



Donc pour résumer, ce qui peut intéresser une association de défense 
de paysage, ce sont les périmètres précis des agglomérations de plus 
de 10 000 habitants en dehors des unités urbaines de plus de 100 000 
habitants, car en dehors de ces agglomérations les "panneaux 
publicitaires scellés au sol" sont interdits :


 - Exploiter les données OSM, comme tu l'as fait, pour déterminer les 
zones de bâti rapproché  :  définir cette notion d'agglomération  (là 
je comprends qu'il faut que je me mette à postgis ?! Comment, je ne 
sais pas.)


 - Ensuite ne garder dans ces agglomérations que celles qui ne sont 
pas dans le périmètre d'une unité urbaine de plus de 100 000 habitants 
(pour lesquelles la réglementation est différente, par exemple les 
"panneaux publicitaires scellés au sol" y sont autorisés).


 - Et au cas par cas,  pour savoir si on est au-dessous ou au-dessus 
du seuil des 10 000 habitants, et en cas de dossier d'infraction 
construit par une association de défense du paysage, il faut ensuite 
demander aux communes la population de ces agglomérations. Car je ne 
pense pas que les données carroyées sont exploitables dans ce cadre.





--
Christian Quest - OpenStreetMap France


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

Re: [Talk-ca] broken forests in eastern Canada

[James]

We could add it as a subpage to:
http://wiki.openstreetmap.org/wiki/WikiProject_Canada seeing as it involves
all of Canada and list out why it's this way etc

On Wed, Aug 31, 2016 at 10:40 AM, Begin Daniel  wrote:

> “Whats up with the forests in Canada?” A wiki page is a good idea!
>
>
>
> And while talking about forest in eastern Canada…
>
>
>
> It would be very helpful to have a plugin in JOSM that deals with Canvec
> water/wooded area integration in multipolygon.  I am not really a developer
> but since the merging operations are repeated over and over again over
> large areas... might it be possible to do something?
>
>
>
> On the same topic, it has been suggested to split wooded areas in smaller
> chunks by using features on the ground as outer limits (mostly roads,
> streams, rivers) and get rid of arbitrary rectangles from Canvec. Is it
> something we are aiming at?
>
>
>
> Daniel
>
>
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Wednesday, 31 August, 2016 07:00
> *To:* Sam Dyck
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] broken forests in eastern Canada
>
>
>
> > we need to have a "Whats up with the forests in Canada?" page on the
> wiki to explain our situation and how we've tried to deal with it
>
> Sounds like a plan.
>
> Cheerio John
>
>
>
> On 30 August 2016 at 22:41, Sam Dyck  wrote:
>
> After reading through the changeset discussion, I discovered that one of
> my imports in Northern Manitoba made Worst of OSM. (
> http://worstofosm.tumblr.com/post/22180046353/dear-
> openstreetmap-isnt-it-strange-how-the). As someone who spends a some time
> amount of time in some of relatively unpopulated areas of Canada and makes
> an effort to check the quality of Canvec data (which is usually pretty
> good), I do agree that it is impossible to do everything to the same level
> of quality that we would provide in Toronto or Timmins or even small
> prairie towns.
>
> One of the things that seems to bother Nakaner and the WoO people (if I
> may put words in their mouths) is that the boundaries are a bit funky in
> Canvec. Forests, lakes and wetlands spill into each other, and they are
> often out of alignment with the Bing imagery. In some ways this reflects a
> degree of natural ambiguity: if we look at the above Hudson's bay
> coastline, their is hourly variation in coastlines, and even the long term
> patterns change over time. The Manitoba-Nunavut boundary is more or less
> fixed by so we can't correct it, and a glance at satellite imagery shows
> that the vegetation tends to be spaced off of the shoreline.
>
> That being said sometimes there is some weird stuff happening in Canvec
> data that is out of sync with what is on the ground. These should be
> corrected when detected, but are rare enough that they shouldn't be a
> problem. I confess I haven't always been great in following the rules when
> doing imports (I think the last few years I've been fully in compliance),
> and have sometimes caused problems, people on this list have generally
> understanding. Perhaps we need to have a "Whats up with the forests in
> Canada?" page on the wiki to explain our situation and how we've tried to
> deal with it.
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] Artwork problems

[Martin Koppenhoefer]

sent from a phone

> Il giorno 31 ago 2016, alle ore 13:30, Oleksiy Muzalyev 
>  ha scritto:
> 
> The artwork icon resembles the Academy Award, or "Oscar" statuette 
> https://en.wikipedia.org/wiki/Academy_Awards . It does not evoke art either 
> inside or outside the museum.


while I agree, this design was chosen by the osm-carto team in the usual 
process and after discussion, so we should accept it for now. There's no good 
icon anyway that can represent all kinds of artwork, from landart to sculpture 
to wall paintings etc. 
You can find other proposals for artwork icons in the github issue of the style 
(my favorite "idea" was a small generic square)

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

Re: [Talk-it] Terremoto Rieti

[girarsi_liste]

Ho provato ad accedere al task 15 adesso, mi da 502 Bad Gateway, è stato
chiuso?

-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

[OSM-talk-nl] Microsoft Lost a City Because They Used Wikipedia Data

[Pander OpenTaal]

Microsoft Lost a City Because They Used Wikipedia Data

https://news.slashdot.org/story/16/08/27/2344213/microsoft-lost-a-city-because-they-used-wikipedia-data

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

[Talk-ca] Crowdsourcing buildings with Statistics Canada

[Ellefsen, Bjenk (STATCAN)]

Hello everyone,

I am back from vacation and doing my best to catch up! Things are moving fast 
so I will jump right into some updates:

I added the project on the OSM Canada wiki page on both English and French page.
I would like to add a separate page where we will document the project in 
detail and we can add the link in the subsection for the project.

I also made a small change to the French page to make both language pages be 
more similar. The section for Canada sub projects was just called "Objectifs". 
I hope this is ok with everyone!

I have more updates to give but I will come back later!

Bjenk Ellefsen, PhD

Data Exploration and Integration Lab (DEIL) | Lab d'exploration et intégration 
de données (LEID)
Center for Special Business Projects | Centre des Projets Spéciaux sur les 
entreprises
Statistics Canada | Statistique Canada
(343) 998-3004

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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Paul Desgranges]

Je comprends l'idée, et merci de me montrer les possibilités de postgis 
!  Et des données carroyées ! Effectivement on peut faire beaucoup !!


Mais les infractions au Code de l'environnement relatifs à l'affichage 
illégal ("panneaux publicitaires scellés au sol" hors agglomération par 
exemple) sont jugés par les Tribunaux Administratifs (TA) , et devant 
les TA, il n'y a pas de "en gros" :


 - en cas de litige sur le périmètre de l'agglomération (agglomération 
administrative et agglomération géographique ne coïncident pas), c'est 
la situation physique réellement constatée qui fait foi.  (Mais là, OSM 
pourrait aider à définir le périmètre des agglomérations, comme tu l'as 
fait.)


- la population ne peut pas être estimée par carreaux de 200m de coté, 
car la population d'une agglomération est évaluée 'par commune'  (les 
carreaux de 200 m de coté peuvent être à cheval entre plusieurs 
communes), et uniquement pour la partie agglomérée de la commune. 
D'autre part, si la commune est constituée de plusieurs agglomérations, 
il faut évaluer la population 'par agglomération'. C'est alors le maire 
qui est sollicité pour fournir ces données qui n'existent pas par ailleurs.


C'est pour ça que les publicitaires/afficheurs ont la vie belle, et 
peuvent faire pratiquement ce qu'ils veulent, et enfreindre la loi en 
toute connaissance de cause ; le Code de l'environnement est 
suffisammemnt complexe et les régles d'agglomération et de population 
sont difficiles à estimer, il faut plusieurs années parfois pour faire 
aboutir un dossier. De plus, les préfets sont passifs, ils laissent 
faire  et n'interviennent que lorsqu'une association de défense de 
paysage porte plainte. Mais quand ça se produit, les préfets se font à 
chaque fois condamner ; car ils ne font pas respecter la réglementation 
que l'Etat (c'est à dire eux-mêmes) a mis en place.



Donc pour résumer, ce qui peut intéresser une association de défense de 
paysage, ce sont les périmètres précis des agglomérations de plus de 10 
000 habitants en dehors des unités urbaines de plus de 100 000 
habitants, car en dehors de ces agglomérations les "panneaux 
publicitaires scellés au sol" sont interdits :


 - Exploiter les données OSM, comme tu l'as fait, pour déterminer les 
zones de bâti rapproché  :  définir cette notion d'agglomération  (là je 
comprends qu'il faut que je me mette à postgis ?! Comment, je ne sais pas.)


 - Ensuite ne garder dans ces agglomérations que celles qui ne sont pas 
dans le périmètre d'une unité urbaine de plus de 100 000 habitants (pour 
lesquelles la réglementation est différente, par exemple les "panneaux 
publicitaires scellés au sol" y sont autorisés).


 - Et au cas par cas,  pour savoir si on est au-dessous ou au-dessus du 
seuil des 10 000 habitants, et en cas de dossier d'infraction construit 
par une association de défense du paysage, il faut ensuite demander aux 
communes la population de ces agglomérations. Car je ne pense pas que 
les données carroyées sont exploitables dans ce cadre.



Merci
Cdlt,
Paul
Le 31 août 2016 à 13:30, Paul Desgranges > a écrit :


Effectivement, il est possible de sortir les agglomérations ! Si
je savais faire ça  :-) !!


On dit merci à postgis ;)




En gros besoin de savoir combien il y a d'habitants dans chaque 
polygone... et on a ces infos via les données INSEE de population 
carroyées, c'est à dire réparties sur des carreaux de 200m de coté.


Pour les 200m, ça fait un buffer de 100m comme ça 2 bâtiments éloignés 
de 200m on leur buffer qui se rejoint.


Voilà ce que ça donne pour le 89, avec uniquement les polygone de plus 
de 5000 habitants.


http://bl.ocks.org/d/6fff0c54abf31d31e05b38cb433aeb2e

--
Christian Quest - OpenStreetMap France



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

Re: [Talk-ca] broken forests in eastern Canada

[Begin Daniel]

“Whats up with the forests in Canada?” A wiki page is a good idea!

And while talking about forest in eastern Canada…

It would be very helpful to have a plugin in JOSM that deals with Canvec 
water/wooded area integration in multipolygon.  I am not really a developer but 
since the merging operations are repeated over and over again over large 
areas... might it be possible to do something?

On the same topic, it has been suggested to split wooded areas in smaller 
chunks by using features on the ground as outer limits (mostly roads, streams, 
rivers) and get rid of arbitrary rectangles from Canvec. Is it something we are 
aiming at?

Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Wednesday, 31 August, 2016 07:00
To: Sam Dyck
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] broken forests in eastern Canada

> we need to have a "Whats up with the forests in Canada?" page on the wiki to 
> explain our situation and how we've tried to deal with it
Sounds like a plan.
Cheerio John

On 30 August 2016 at 22:41, Sam Dyck 
> wrote:
After reading through the changeset discussion, I discovered that one of my 
imports in Northern Manitoba made Worst of OSM. 
(http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-it-strange-how-the).
 As someone who spends a some time amount of time in some of relatively 
unpopulated areas of Canada and makes an effort to check the quality of Canvec 
data (which is usually pretty good), I do agree that it is impossible to do 
everything to the same level of quality that we would provide in Toronto or 
Timmins or even small prairie towns.

One of the things that seems to bother Nakaner and the WoO people (if I may put 
words in their mouths) is that the boundaries are a bit funky in Canvec. 
Forests, lakes and wetlands spill into each other, and they are often out of 
alignment with the Bing imagery. In some ways this reflects a degree of natural 
ambiguity: if we look at the above Hudson's bay coastline, their is hourly 
variation in coastlines, and even the long term patterns change over time. The 
Manitoba-Nunavut boundary is more or less fixed by so we can't correct it, and 
a glance at satellite imagery shows that the vegetation tends to be spaced off 
of the shoreline.
That being said sometimes there is some weird stuff happening in Canvec data 
that is out of sync with what is on the ground. These should be corrected when 
detected, but are rare enough that they shouldn't be a problem. I confess I 
haven't always been great in following the rules when doing imports (I think 
the last few years I've been fully in compliance), and have sometimes caused 
problems, people on this list have generally understanding. Perhaps we need to 
have a "Whats up with the forests in Canada?" page on the wiki to explain our 
situation and how we've tried to deal with it.

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

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

[Talk-it] overpass xapi e wget

[emmexx]

Ho usato per un po' di anni wget con il seguente url per ottenere i dati
all'interno di un bbox:

http://www.overpass-api.de/api/xapi?map?bbox=long1,lat1,long2,lat2

Da qualche settimana mi appare un errore:

HTTP request sent, awaiting response... 404 Not Found

E' cambiato qualcosa nelle api? Bisogna usare altri sistemi. Ho guardato
la documentazione online ma non ho visto avvisi che indicano che questa
sintassi non e' piu' usata.

grazie
maxx

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

Re: [talk-au] Tagging for the router

[Nick Hocking]

"I'm assuming you mean the Intersection with Lane Cove Rd.

If so it's not permitted to make a u-turn here anyway, as there is no
sign permitting u-turns at the traffic signals.

So I'd not add it as a restriction as anyone driving there should know
that they can not make a u-turn there."


Ok - since you ask - all routers I just tried , both on osm data and
commercial data allowed the U-turn at the traffic lights at lane cove
road.   So do we contact all known writers of routing software and ask them
to obey the local traffic norms, or do we force their hand and put in the
restriction.

Actually Gosmore nearly got it right but then spoiled it by doing something
even more stupid immediately afterwards. I think that routing engine need
to be made a lot smarter to handle edge cases where drivers can evaluate
geometry a lot better and accurately than routers.


PS - it is my belief that car navigation is mainly for visitors, not
locals, so I think that routing engines should not try to be aware of local
customs.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Erreurs Osmose à l'édition

[Francois Gouget]

On Wed, 31 Aug 2016, Francois Gouget wrote:

> On Thu, 18 Aug 2016, Frédéric Rodrigo wrote:
> [...]
> > > Puis j'ai coché "Reuse changeset" et c'est passé (heureusement le
> > > changeset précédent était du même tonneau, mais maintenant il est un peu
> > > gros). Depuis plus de problème.
> > J'ai mis des trace de debug. Il faut maintenant attendre que le problème 
> > se reproduise.
> 
> J'en tiens un mais c'est pas exactement le même :
> readyState: 4
> status: 504 (et non 500)
> 
> En plus là "Reuse changeset" est coché mais rien ne change si je le 
> décoche.
> 
> Il y a 50 objets modifiés mais entre le début et la fin il y a 
> probablement 3 à 4 heures (j'ai été interrompu en cours de route). 
> D'ailleurs je soupçonne que ce délai a son importance. Bon, je garde la 
> fenêtre Osmose ouverte...

Une nouvelle tentative ~15 minutes plus tard a été couronnée de succès.


-- 
Francois Gouget   http://fgouget.free.fr/
  E-Voting: It's not the people who vote that count.
 It's the people who count the votes.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Christian Quest]

Le 31 août 2016 à 13:30, Paul Desgranges  a
écrit :

> Effectivement, il est possible de sortir les agglomérations ! Si je savais
> faire ça  :-) !!
>

On dit merci à postgis ;)

Aiglun est une commune de moins de 2000 habitants, c'est une commune
> rurale, elle ne fait pas partie de l'unité urbaine de Digne (qui a plus de
> 10 000 habitants) donc, et pour la problématique qui m'intéresse, les
> "panneaux publicitaires scellés au sol" sont interdits partout, que ce soit 
> dans
> les zones agglomérées montrées par la carte que tu as produite
>  ou
> ailleurs.
>
> Ce qui serait intéressant, mais je mets toujours dans l'idée de pouvoir
> vérifier la réglementation sur la publicité extérieure (plus
> particulièrement celle des "panneaux publicitaires scellés au sol") , c'est
> une carte  montrant les agglomérations (donc bien les agglomérations, et
> non pas les communes) qui ont plus de 10 000 habitants et qui ne font pas
> partie d'une unité urbaine de plus de 100 000 habitants. Pour ceci, il
> faudrait savoir faire ce que tu as fait sur cette carte
>  et
> en plus savoir rapprocher ceci des données des populations (mais là encore
> les populations des agglomérations et non pas celles des communes) sachant
> que ces données-là (population des agglomérations) n'existent pas de
> manière centralisée (comme peuvent exister les données de population des
> communes).
> De plus, si l'Insee définit les "unités urbaines" comme une commune ou un
> ensemble de communes présentant une zone de bâti continu (pas de coupure de
> plus de 200 mètres entre deux constructions), pour les agglomérations" la
> définition n'est pas aussi claire en terme de distance entre deux
> constructions  : zone de "bâti rapproché" avec entrées et sorties signalés
> par les panneaux eb10/eb20.  Donc pour les agglomérations, il faudrait peut
> être choisir 200 mètres aussi ?
>
>
En gros besoin de savoir combien il y a d'habitants dans chaque polygone...
et on a ces infos via les données INSEE de population carroyées, c'est à
dire réparties sur des carreaux de 200m de coté.

Pour les 200m, ça fait un buffer de 100m comme ça 2 bâtiments éloignés de
200m on leur buffer qui se rejoint.

Voilà ce que ça donne pour le 89, avec uniquement les polygone de plus de
5000 habitants.

http://bl.ocks.org/d/6fff0c54abf31d31e05b38cb433aeb2e

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

Re: [Talk-it] Tag preset JOSM x terremoto

[Martin Koppenhoefer]

sent from a phone

> Il giorno 31 ago 2016, alle ore 13:40, Alessandro Sarretta 
>  ha scritto:
> 
> earthquake:damage=*
> 
> Completely Destroyed > collapsed
> Highly Damaged > severe
> Moderately Damaged > moderate
> Negligible to slight Damage > negligible
> Not affected > no
> Not evaluated > not_evaluated


ottimo, mi sembrano sensati (tranne "not evaluated" forse) , avevo timore che 
si usasse ancora building=collapsed o simili...


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

Re: [talk-au] Tagging for the router

[Nick Hocking]

"I'm assuming you mean the Intersection with Lane Cove Rd."

No - the intersection with Chiltern Street although it looks as though
someone has just added it.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Aurimas Fišeras]

2016.08.31 15:22, Ramas rašė:

Kiek žinau, Mapillary yra legalus šaltinis:

Taip,
https://www.mapillary.com/osm.html



https://www.mapillary.com/app/?lat=54.642522=25.2794417=17=oVBw-VNQINH6DE4bP5IU_A=photo


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

Re: [talk-au] Tagging for the router

[Ross]

I'm assuming you mean the Intersection with Lane Cove Rd.

If so it's not permitted to make a u-turn here anyway, as there is no 
sign permitting u-turns at the traffic signals.


So I'd not add it as a restriction as anyone driving there should know 
that they can not make a u-turn there.


Cheers

Ross



On 31/08/16 20:49, Nick Hocking wrote:

What do people think about the intersection at

-33.6793339   151.264475

The road geometry clearly indicates that there is no way you can do a  
turn from Moan Vale Road Eastbound back down Mona Vale Road Westbound, 
yet there are no signs saying so and I believe that most routers would 
suggest this if you were caught out going  to opposite way that you 
intended. Trying to do a u turn here would cause a crash quite often, 
I believe.



So should I add a no-u-turn restriction or not?




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


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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Ramas]

Kiek žinau, Mapillary yra legalus šaltinis:

https://www.mapillary.com/app/?lat=54.642522=25.2794417=17=oVBw-VNQINH6DE4bP5IU_A=photo

2016-08-31 14:58 GMT+03:00 Aidas Kasparas :

> On 2016.08.31 13:16, Tomas Straupis wrote:
>
> Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?
>
>   Osmose:
>   http://osmose.openstreetmap.fr/lt/errors/?source=6641=7130=71301
>
>
> Ok, šitas rodo. Bet wiki.osm yra parašyta:
>
> *Warning: do not map for Osmose/keepright etc. Only fix real errors which
> you understand and know how to improve correctly!!!*
>
> http://wiki.openstreetmap.org/wiki/Osmose
>
> O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už tai, kad
> ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra pakankamai
> aukštas arba yra pažymėtas apribojimas. Taip nepridėliotumėm
> bereikšmių/neteisingų duomenų.
>
>   Na čia keli pastebėjimai:
>   1. Jei yra nuostatai, kad tunelis yra bent 5 metrų aukščio, tai
> nereiškia, kad jis negali būti 6 metrų aukščio. Potencialiems tokios
> informacijos naudotojams (sunkvežimiams su negabaritiniais kroviniais)
> tokia info bus įdomi.
>   2. Jei Lietuvoje yra standartas 5m., kitose šalyse gali būti 6
> metrai arba tarkim 4,5. Kadangi OSM - pasaulinė db, tai gal vertėtų
> įrašyti ir „standartinį Lietuvos“ aukštį. Sutinku, kad su tokia
> argumentacija labai daug nereikalingų žymų galim pradėti dėlioti (pvz.
> horse=no ant visų trunk:), bet tokių tunelių Osmose randa labai nedaug
> (19)...
>
>
>
> Dėl negabaritinių krovinių vežėju, aš labai abejoju, kad jie pasitikėtų
> OSM. Gal nebent laAabai preliminariai primesti galimus maršrutus.
>
> O dabar praktiniai klausimai:
>
> Jei vis tik aukščius dėlioti, tai kokius dėti -- nurodytus ženkluose ar
> esančius fiziškai? O jei fiziškai, tai ar minimumą, kuris yra virš
> važiuojamosios dalies, ar su kelkraščiais, ar apskritai minimumą
> pravažiavimo arkoje?
>
> Jei importuoti iš lakis ar kitų sistemų, ar mes turime teisę tai daryti?
>
> Jei importuoti teisės neturime, tai kaip priėję prie tilto galime tą
> aukštį nustatyti? Prisipažinkite, kas kišenėje nešiojatės 5m+ ruletę. Ir
> kaip pažiūrėsite, kur yra tilto apačia, jei jo skerspjūvis yra T formos?
> Nebent lazeriniu tolimačiu iš apačios. Bet vėlgi, kiek iš mūsų turime tokį?
> Jau nekalbant apie nešiojimąsi pastoviai.
>
> Žodžiu, jei nepavyksta importas, aš manyčiau, kad būtų prasmė apsiriboti
> vietomis, kur yra pastatyti aukštį/plotį ribojantys ženklai. Visa kita
> neverta tam skirto laiko. Bent jau mano.
>
> --
> Aidas Kasparas
>
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-it] Tag preset JOSM x terremoto

[Damjan Gerl]

Da: "Alessandro Sarretta"
> 
> Completely Destroyed > collapsed
> Highly Damaged > severe
> Moderately Damaged > moderate
> Negligible to slight Damage > negligible
> Not affected > no
> Not evaluated > not_evaluated
> 
> Confermo che sarebbero da inserire nel task.

Ciao!
Concordo, direi solamente ancora che l'ultimo, il not_evaluated, non lo 
metterei proprio, siccome è già sottinteso che se non c'è, non è stato valutato.

Damjan

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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Aidas Kasparas]

On 2016.08.31 13:16, Tomas Straupis wrote:

Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?

   Osmose:
   http://osmose.openstreetmap.fr/lt/errors/?source=6641=7130=71301


Ok, šitas rodo. Bet wiki.osm yra parašyta:

*Warning: do not map for Osmose/keepright etc. Only fix real errors 
which you understand and know how to improve correctly!!!*


http://wiki.openstreetmap.org/wiki/Osmose


O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už tai, kad
ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra pakankamai
aukštas arba yra pažymėtas apribojimas. Taip nepridėliotumėm
bereikšmių/neteisingų duomenų.

   Na čia keli pastebėjimai:
   1. Jei yra nuostatai, kad tunelis yra bent 5 metrų aukščio, tai
nereiškia, kad jis negali būti 6 metrų aukščio. Potencialiems tokios
informacijos naudotojams (sunkvežimiams su negabaritiniais kroviniais)
tokia info bus įdomi.
   2. Jei Lietuvoje yra standartas 5m., kitose šalyse gali būti 6
metrai arba tarkim 4,5. Kadangi OSM - pasaulinė db, tai gal vertėtų
įrašyti ir „standartinį Lietuvos“ aukštį. Sutinku, kad su tokia
argumentacija labai daug nereikalingų žymų galim pradėti dėlioti (pvz.
horse=no ant visų trunk:), bet tokių tunelių Osmose randa labai nedaug
(19)...



Dėl negabaritinių krovinių vežėju, aš labai abejoju, kad jie pasitikėtų 
OSM. Gal nebent laAabai preliminariai primesti galimus maršrutus.


O dabar praktiniai klausimai:

Jei vis tik aukščius dėlioti, tai kokius dėti -- nurodytus ženkluose ar 
esančius fiziškai? O jei fiziškai, tai ar minimumą, kuris yra virš 
važiuojamosios dalies, ar su kelkraščiais, ar apskritai minimumą 
pravažiavimo arkoje?


Jei importuoti iš lakis ar kitų sistemų, ar mes turime teisę tai daryti?

Jei importuoti teisės neturime, tai kaip priėję prie tilto galime tą 
aukštį nustatyti? Prisipažinkite, kas kišenėje nešiojatės 5m+ ruletę. Ir 
kaip pažiūrėsite, kur yra tilto apačia, jei jo skerspjūvis yra T formos? 
Nebent lazeriniu tolimačiu iš apačios. Bet vėlgi, kiek iš mūsų turime 
tokį? Jau nekalbant apie nešiojimąsi pastoviai.


Žodžiu, jei nepavyksta importas, aš manyčiau, kad būtų prasmė apsiriboti 
vietomis, kur yra pastatyti aukštį/plotį ribojantys ženklai. Visa kita 
neverta tam skirto laiko. Bent jau mano.


--
Aidas Kasparas

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

Re: [Talk-cz] OSM stánek na Linuxdays?

[Pavel Machek]

On Tue 2016-08-30 06:58:41, Marián Kyral wrote:
> Ahoj,
> moc lidí jabber konferenci nesleduje, tak přeposílám.
> 
> [16:39:43]  Ahoj. Omlouvam se ze email ale tato moznost se mi libi :).
> Chtel bych se zeptat jestli by vase komunita nemela zajem o stanek ma akci 
> linuxdays. Klidne muzete pridat prednasku do konciciho CFP na https://www.
> linuxdays.cz/2016/cfp/ cas je do konce mesice
> [16:40:57]  videl jsem pekny stanek na Chemnitzer Linux Tage http://
> wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2016 umime neco takoveho i
> v CR?
> [16:41:50]  kontakt na nas je o...@linuxdays.cz
> *** 2016-08-30
> 
> LinuxDays 2016 - 8. a 9. října 2016, Praha
> 
> Měl by o to někdo zájem? Já se tam možná objevím, pokud bude můj příspěvek o
> OSM vybrán,

Pokud vezmou prispevek, tak tam budu 9. Pokud ne, tak se tam mozna
take objevim...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

Re: [talk-au] Tagging for the router

[Andrew Davidson]

On 31/08/16 21:23, Leon Kernan wrote:

> After all that, i'd only tag a turn restriction if there is a sign
> advising such.

That's a nice theory but it does mean that there is no way to tell if 
you are allowed to drive from one incoming way to another outgoing way. 
Turn restrictions are, after all, entirely tagging for the router (it's 
not like they get rendered on the map).



I'm pretty sure noname is a no no these days as well.


I'm equally sure that noname is perfectly fine. They're handy for 
tagging those short turn lanes, service roads, tracks, etc that don't 
have a name so that mappers coming along later can filter them out when 
they're looking for unnamed streets.


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

Re: [Talk-it] Tag preset JOSM x terremoto

[Alessandro Sarretta]

Ciao


On 31/08/2016 12:47, Martin Koppenhoefer wrote:

Il giorno 31 ago 2016, alle ore 11:38, Cascafico Giovanni  
ha scritto:

Ho visto che i tag sono basati su Haiti. Non ci sono state evoluzioni dopo il 
Nepal?

scusate se intervengo solo ora, non avevo molto tempo ultimamente e stavo in 
vacanza  al momento del terremoto. Anch'io non ho ben capito quali siano i tags 
preferibili di questo task, e concordo con Giovanni che i tags ad hoc di Haiti 
si sono poi svelati un po' troppo improvvisati (per non dire tagging per il 
renderer). Ho cercato nel wiki ma non ho trovato niente al riguardo di questo 
terremoto (visto il nostro wiki non vuol dire che non ci siano ;-) ).


se non erro i tag su cui si è concordato sono:

earthquake:damage=*

Completely Destroyed > collapsed
Highly Damaged > severe
Moderately Damaged > moderate
Negligible to slight Damage > negligible
Not affected > no
Not evaluated > not_evaluated

Confermo che sarebbero da inserire nel task.

Ale

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [OSM-talk] Artwork problems

[Oleksiy Muzalyev]

On 25.08.2016 22:11, Martin Koppenhoefer wrote:


sent from a phone


Il giorno 25 ago 2016, alle ore 15:28, Daniel Koć  ha scritto:

there are some places, where the indoor artworks just make noise and I still 
don't know how to avoid this clutter in general:

http://www.openstreetmap.org/#map=18/48.86064/2.33631


these look like artwork in a museum, I guess they don't meet the definition for 
the osm tag according to the wiki (public artwork) and should be fixed 
(different tagging)

cheers,
Martin
___

The artwork icon resembles the Academy Award, or "Oscar" statuette 
https://en.wikipedia.org/wiki/Academy_Awards . It does not evoke art 
either inside or outside the museum.



On the other hand, what an icon can possibly resemble such a statue 
outside this museum 
https://commons.wikimedia.org/wiki/File:Louis_XIV_Bernin_r%C3%A9plique_Cour_Napol%C3%A9on_Louvre.jpg 
?



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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Paul Desgranges]

Effectivement, il est possible de sortir les agglomérations ! Si je 
savais faire ça  :-) !!


Aiglun est une commune de moins de 2000 habitants, c'est une commune 
rurale, elle ne fait pas partie de l'unité urbaine de Digne (qui a plus 
de 10 000 habitants) donc, et pour la problématique qui m'intéresse, les 
"panneaux publicitaires scellés au sol" sont interdits partout, que ce 
soit dans les zones agglomérées montrées par la carte que tu as produite 
 ou 
ailleurs.


Ce qui serait intéressant, mais je mets toujours dans l'idée de pouvoir 
vérifier la réglementation sur la publicité extérieure (plus 
particulièrement celle des "panneaux publicitaires scellés au sol") , 
c'est une carte  montrant les agglomérations (donc bien les 
agglomérations, et non pas les communes) qui ont plus de 10 000 
habitants et qui ne font pas partie d'une unité urbaine de plus de 100 
000 habitants. Pour ceci, il faudrait savoir faire ce que tu as fait sur 
cette carte 
 et 
en plus savoir rapprocher ceci des données des populations (mais là 
encore les populations des agglomérations et non pas celles des 
communes) sachant que ces données-là (population des agglomérations) 
n'existent pas de manière centralisée (comme peuvent exister les données 
de population des communes).


De plus, si l'Insee définit les "unités urbaines" comme une commune ou 
un ensemble de communes présentant une zone de bâti continu (pas de 
coupure de plus de 200 mètres entre deux constructions), pour les 
agglomérations" la définition n'est pas aussi claire en terme de 
distance entre deux constructions  : zone de "bâti rapproché" avec 
entrées et sorties signalés par les panneaux eb10/eb20.  Donc pour les 
agglomérations, il faudrait peut être choisir 200 mètres aussi ?


Cdlt,
Paul


On 31/08/2016 12:25, Christian Quest wrote:
Le 31 août 2016 à 11:08, Paul Desgranges > a écrit :


On 31/08/2016 08:42, Christian Quest wrote:

Il est possible à partir des emprises des batiments de tracer un
buffer de 50m et d'agglomérer tout ça pour avoir une approximation
et détecter les manques.
Il est "possible", mais moi perso je ne sais pas faire, si
quelqu'un veut bien m'apprendre, je compléterais volontiers les
cartes que j'avais fait fin 2015/début 2016
 pour le concours
dataconnexion


avec une carte de France donnant toutes les zones d'habitations
agglomérées.


ça peut donner ça: 
http://bl.ocks.org/anonymous/raw/e211c35a5f86fde3e73bf36e4e62146b/


J'ai sorti la surface de chaque polygone et le nombre de polygone 
building=* qui sont à l'intérieur.


Le buffer est de 50m, les polygones avec moins de 3 polygones de b^ati 
sont éliminés ainsi que ceux de moins de 1m2.



--
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: [talk-au] Tagging for the router

[Leon Kernan]

Sorry, scratch the oneways, i'm half asleep :-)

On Wed, Aug 31, 2016 at 9:23 PM, Leon Kernan  wrote:

> I'd fix the fact the oneways are pointed in the wrong direction, change
> trunk to trunk_link and add lanes=1.
> I'm pretty sure noname is a no no these days as well.
>
> After all that, i'd only tag a turn restriction if there is a sign
> advising such.
>
> On Wed, Aug 31, 2016 at 8:49 PM, Nick Hocking 
> wrote:
>
>> What do people think about the intersection at
>>
>> -33.6793339   151.264475
>>
>> The road geometry clearly indicates that there is no way you can do a
>> turn from Moan Vale Road Eastbound back down Mona Vale Road Westbound, yet
>> there are no signs saying so and I believe that most routers would suggest
>> this if you were caught out going  to opposite way that you intended.
>> Trying to do a u turn here would cause a crash quite often, I believe.
>>
>>
>> So should I add a no-u-turn restriction or not?
>>
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Tagging for the router

[Leon Kernan]

I'd fix the fact the oneways are pointed in the wrong direction, change
trunk to trunk_link and add lanes=1.
I'm pretty sure noname is a no no these days as well.

After all that, i'd only tag a turn restriction if there is a sign advising
such.

On Wed, Aug 31, 2016 at 8:49 PM, Nick Hocking 
wrote:

> What do people think about the intersection at
>
> -33.6793339   151.264475
>
> The road geometry clearly indicates that there is no way you can do a
> turn from Moan Vale Road Eastbound back down Mona Vale Road Westbound, yet
> there are no signs saying so and I believe that most routers would suggest
> this if you were caught out going  to opposite way that you intended.
> Trying to do a u turn here would cause a crash quite often, I believe.
>
>
> So should I add a no-u-turn restriction or not?
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Paulius Masiliūnas]

Dar vienas variantas yra pasiimti irgi iš LAKD kelio ženklus kurie yra
pažymėti 316 - Ribotas aukštis, manau čia net ir geresnis variantas nei aš
siunčiau anksčiau, OSM sudelioti ženklus kurie riboja aukštį.
http://lakis.lakd.lt/ArcGIS/rest/services/LAKD/MapServer/30/query?where=Kodas%3D316=true=*=html

2016-08-31 13:42 GMT+03:00 Paulius Masiliūnas :

> Truputi užmečiau akį tarp savo žinomu webservice ir atradau vieną įdomų
> service.
> http://www.visimarsrutai.lt/arcgis/rest/services/EIS_
> SALYGOS/MapServer/4/query?where=EAT_KODAS%3D%27RA%27&
> outFields=*=false=html
>
> Čia yra sužymėti visi tiltai kurie turi aukščio apribojimus (yra galimybė
> papildomai išsitraukti: Ribojama masė, Ribojamas plotis).
> Tik įdomu dalyką pastebėjau, tarkim yra šitame webservice nurodyta, kad
> apribotas aukštis 4.63 (ID 9770
> ),
> bet pagal Google street view  aš matau kad ženklas stovi kuris riboja
> aukštį iki 4.4 (Google Street View
> ),
> nujaučiu kad čia toks ženklas dedamas kad jei koks sunkvežimis 4.4 m.
> aukščio bandytu pravažiuoti, kad po tiltu nestriktu ir dar liktu šiuo
> atveju 13 cm.
>
> Bet šiaip galima užmesti akį ar būtu naudinga iš šito service, jei taip
> tai galima bandyti tada kreiptis į LAKD. Šiaip LAKD turi sistema vadinama
> LAKIS kurioje jie turi labai daug visokios informacijos ir kartu
> webservice, iš kurių ta iformaciją būtu galima pasiimti. LAKIS aprašymas
> "Valstybinės reikšmės kelių informacinėje sistemoje (LAKIS) centralizuotai
> kaupiami, tvarkomi, apdorojami ir teikiami valstybinės reikšmės kelių ir
> tiltų duomenys."
>
>
> -- Forwarded message --
> From: Tomas Straupis 
> Date: 2016-08-31 13:16 GMT+03:00
> Subject: Re: [Talk-lt] Tunelių/tiltų aukščiai
> To: OSM Talk LT 
>
>
> > Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?
>
>   Osmose:
>   http://osmose.openstreetmap.fr/lt/errors/?source=6641=
> 7130=71301
>
> > O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už tai,
> kad
> > ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra pakankamai
> > aukštas arba yra pažymėtas apribojimas. Taip nepridėliotumėm
> > bereikšmių/neteisingų duomenų.
>
>   Na čia keli pastebėjimai:
>   1. Jei yra nuostatai, kad tunelis yra bent 5 metrų aukščio, tai
> nereiškia, kad jis negali būti 6 metrų aukščio. Potencialiems tokios
> informacijos naudotojams (sunkvežimiams su negabaritiniais kroviniais)
> tokia info bus įdomi.
>   2. Jei Lietuvoje yra standartas 5m., kitose šalyse gali būti 6
> metrai arba tarkim 4,5. Kadangi OSM - pasaulinė db, tai gal vertėtų
> įrašyti ir „standartinį Lietuvos“ aukštį. Sutinku, kad su tokia
> argumentacija labai daug nereikalingų žymų galim pradėti dėlioti (pvz.
> horse=no ant visų trunk:), bet tokių tunelių Osmose randa labai nedaug
> (19)...
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [OSM-talk] Artwork problems

[Janko Mihelić]

čet, 25. kol 2016. u 15:30 Daniel Koć  napisao je:

>
> I've also noticed that the line between artworks and memorials is
> blurred, especially with statues
>

In my opinion, we can use both tags. If something is a sculpture, add
tourism=artwork+artwork_type=sculpture. If it is a sculpture whose main
purpose is to remind us of a person or an event, add historic=memorial.

About the icon, I think we should add a new key, something like
sculpture_shape. It could have countless values, and only the most frequent
would have their unique icon. Values would be: human, child, human_sitting,
human_standing, human_on_horse, bust, horse, dog, abstract. Those account
for about 95% of sculptures. Others get the default icon. Having an
approximate shape of a sculpture on a map helps a lot with orientation in
space.

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

Re: [Talk-ca] broken forests in eastern Canada

[john whelan]

> we need to have a "Whats up with the forests in Canada?" page on the wiki
to explain our situation and how we've tried to deal with it

Sounds like a plan.

Cheerio John

On 30 August 2016 at 22:41, Sam Dyck  wrote:

> After reading through the changeset discussion, I discovered that one of
> my imports in Northern Manitoba made Worst of OSM. (
> http://worstofosm.tumblr.com/post/22180046353/dear-
> openstreetmap-isnt-it-strange-how-the). As someone who spends a some time
> amount of time in some of relatively unpopulated areas of Canada and makes
> an effort to check the quality of Canvec data (which is usually pretty
> good), I do agree that it is impossible to do everything to the same level
> of quality that we would provide in Toronto or Timmins or even small
> prairie towns.
>
> One of the things that seems to bother Nakaner and the WoO people (if I
> may put words in their mouths) is that the boundaries are a bit funky in
> Canvec. Forests, lakes and wetlands spill into each other, and they are
> often out of alignment with the Bing imagery. In some ways this reflects a
> degree of natural ambiguity: if we look at the above Hudson's bay
> coastline, their is hourly variation in coastlines, and even the long term
> patterns change over time. The Manitoba-Nunavut boundary is more or less
> fixed by so we can't correct it, and a glance at satellite imagery shows
> that the vegetation tends to be spaced off of the shoreline.
>
> That being said sometimes there is some weird stuff happening in Canvec
> data that is out of sync with what is on the ground. These should be
> corrected when detected, but are rare enough that they shouldn't be a
> problem. I confess I haven't always been great in following the rules when
> doing imports (I think the last few years I've been fully in compliance),
> and have sometimes caused problems, people on this list have generally
> understanding. Perhaps we need to have a "Whats up with the forests in
> Canada?" page on the wiki to explain our situation and how we've tried to
> deal with it.
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[talk-au] Tagging for the router

[Nick Hocking]

What do people think about the intersection at

-33.6793339   151.264475

The road geometry clearly indicates that there is no way you can do a  turn
from Moan Vale Road Eastbound back down Mona Vale Road Westbound, yet there
are no signs saying so and I believe that most routers would suggest this
if you were caught out going  to opposite way that you intended. Trying to
do a u turn here would cause a crash quite often, I believe.


So should I add a no-u-turn restriction or not?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Tag preset JOSM x terremoto

[Martin Koppenhoefer]

sent from a phone

> Il giorno 31 ago 2016, alle ore 11:38, Cascafico Giovanni 
>  ha scritto:
> 
> Ho visto che i tag sono basati su Haiti. Non ci sono state evoluzioni dopo il 
> Nepal?


scusate se intervengo solo ora, non avevo molto tempo ultimamente e stavo in 
vacanza  al momento del terremoto. Anch'io non ho ben capito quali siano i tags 
preferibili di questo task, e concordo con Giovanni che i tags ad hoc di Haiti 
si sono poi svelati un po' troppo improvvisati (per non dire tagging per il 
renderer). Ho cercato nel wiki ma non ho trovato niente al riguardo di questo 
terremoto (visto il nostro wiki non vuol dire che non ci siano ;-) ).

Ciao,
Martin


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

Re: [OSRM-talk] Release OSRM 5.3.2

[Moritz Kobitzsch]

Hey,

we released OSRM 5.3.3 fixing multiple small issues. The full list is as
follows:

# 5.3.3

  Changes from 5.3.2

- Bugfixes

  - Fixed an issue that would result in segfaults for viaroutes with an
invalid intermediate segment when u-turns were allowed at the via-location

  - Fixed an issue that could result in segfaults when querying roads
that could require looping back to the start of a way while using a core
factor

  - Fixed an issue that could break some testcases when using a core
factor

  - Fixed an issue with parallel edges that could result in weird routes

As always the release comes with node-osrm binaries.

Cheers,
Moritz

On Tue, Aug 9, 2016 at 2:01 PM, Moritz Kobitzsch  wrote:

> Hey,
>
> we released OSRM 5.3.2 fixing an issue that occurs when removing very
> short segments at the begin/end of a route.
>
> # 5.3.2
>
>   Changes from 5.3.1
>
> - Bugfixes
>
>   - fixed a bug that occurred when trimming very short segments at the
> begin/end of a route (less than 1 meter)
>
> As always the release comes with node-osrm binaries.
>
> Cheers,
> Moritz
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Philippe Verdy]

Il reste à relier les zones liées par une route publique mais séparées de
moins de 150 mètres environ (selon les distances réglementaires de
visibilite des panneaux en zone rurale). Dansces cas ka on ne sirt pas de
l'agglomeration et il n'y a aucun panneau entre les deux zones sauf si on
change de communes.

Le 31 août 2016 12:28, "Christian Quest"  a écrit :

> Le 31 août 2016 à 11:08, Paul Desgranges  a
> écrit :
>
>> On 31/08/2016 08:42, Christian Quest wrote:
>>
>
>
>> Il est possible à partir des emprises des batiments de tracer un buffer
>> de 50m et d'agglomérer tout ça pour avoir une approximation et détecter les
>> manques.
>>
>> Il est "possible", mais moi perso je ne sais pas faire, si quelqu'un veut
>> bien m'apprendre, je compléterais volontiers les cartes que j'avais fait
>> fin 2015/début 2016  pour le concours
>> dataconnexion
>> 
>> avec une carte de France donnant toutes les zones d'habitations
>> agglomérées.
>>
>>
> ça peut donner ça: http://bl.ocks.org/anonymous/raw/
> e211c35a5f86fde3e73bf36e4e62146b/
>
> J'ai sorti la surface de chaque polygone et le nombre de polygone
> building=* qui sont à l'intérieur.
>
> Le buffer est de 50m, les polygones avec moins de 3 polygones de b^ati
> sont éliminés ainsi que ceux de moins de 1m2.
>
>
> --
> 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: [Talk-lt] Tunelių/tiltų aukščiai

[Eduardas Kriščiūnas]

Teisinga pastaba. Jei važiuoja didesnis automobilis – jam reikalingas 
spec. leidimas ir sudaromas maršrutas. Tuo rūpinasi kelios institucijos.

Leidimas nereikalingas, kai TP aukštis yra iki 4,00m.
https://www.e-tar.lt/portal/lt/legalAct/TAR.B3618189BEF5

Aidas Kasparas rašė:

On 2016.08.31 11:20, Tomas Straupis wrote:

Sveiki

   Gal turite minčių, kur būtų galima rasti tunelių/tiltų aukščius?

   Norisi užpildyti tuneliams „maxheight“ žymą, kad validatoriai
nebesikabinėtų ir kad sunkvežimių maršrutizatoriai žinotų, kur
pravažiuoti galima/negalima.



Tomai,

Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?

Antra. aš įsivaizduoju, kad statybos normose yra kažkur reikalavimas, 
kad statant tiltą virš gatvės reikia naudoti mažiausiai tam tikrą 
aukštį. Jei tokio nepavyksta padaryti, tiltas turi būti paženklintas 
ženklu „Ribotas aukštis“. Spėju, kad tas aukštis yra 5 m. Nes kiek 
teko sutikti ženklus LT, visi buvo 4 su trupučiu arba mažiau.


O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už 
tai, kad ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra 
pakankamai aukštas arba yra pažymėtas apribojimas. Taip 
nepridėliotumėm bereikšmių/neteisingų duomenų.






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

Re: [OSM-talk-fr] Voie de "services" des autoroutes

[Philippe Verdy]

Tout bonnement ces voies de service donnent accès au parking du personnel
de la station et servent aux livraisons des commerces ou au ramassage des
poubelles ou pour les facteurs ou cinduisent aux depots des intervenants de
sécurité de la societe d'autoroute (les gilets jaunes) ou la police ou
gendarmerie et les pompiers, ou pour le delestage en cas de fermeture ou
pour acceder aux depots de sel ou sable en hiver afin de pouvoir resortir
de la station sans faire de contresens. Il y a aussi des voies de setvice
accessibles au public ou aux camions et les voies vers la station essence
sont aussi des voies de service comme aussi celles vers les parkings
voitures ou camions/bus/camping cars/attelages.
Toute la station en fait est faite de voies de service.

Le 31 août 2016 12:23, "Jérôme Seigneuret"  a
écrit :

> Salut,
>
> Je mets pour les voies d'accès réservé à l'usage de service et d'urgence
> qui sont fermé par un portail:
> highway=service + access=private + emergency=yes
>
> access=no et access=private et un peu problématique pour moi aussi.
> access=no c'est pour un access impossible au grand public donc à moins d'y
> ajouter une clause access:conditonal ...
>
> Il y a aussi les portails d'accès pour les salariés pour entrer sur les
> zones aires de repos ou de péage.
>
> J'ai mis access=private car c'est géré par un opérateur qui peut
> explicitement donner le droit à des sociétés d'accéder par ces portails
> (contract de maintenace en sous-traitance et inventaires écologiques)
>
> Ce n'est pas utilisé seulement pour des raisons urgence mais pour l'accès
> au service afin d'arriver sur la voie pour faire l'entretien et la
> vérification de certains tronçons.
> Je pense qu'il y a différents cas possibles.
>
> Jérôme
>
> Le 31 août 2016 à 09:55, Frédéric Rodrigo  a
> écrit :
>
>> Bonjour,
>>
>> Je n'ai rien trouvé sur le wiki et les usages en France sont variées.
>>
>> Je me pose la question de savoir comment doivent être taggé les voies
>> connectées aux autoroutes ou parfois dans les aires et qui sont fermées
>> avec des portails.
>>
>> Typiquement ce genre de chose :
>>
>> http://www.openstreetmap.org/#map=19/48.05394/0.35439
>>
>> J'ai analysé comment c'est fait en France, le cas le plus fréquent est
>> highway=service + access=no (1473) devant highway=service +
>> service=emergency_access + access=no (514)
>>
>> Je n'ai pas analysé les tags des portails.
>>
>> Voilà le détail :
>>
>>  count |highway|  service  |   access
>> ---+---+---+-
>>  5 | cycleway  |   |
>>  8 | emergency_bay |   |
>>  1 | escape|   | no
>> 50 | escape|   |
>> 10 | footway   |   | emergency
>>  1 | footway   |   | permissive
>>  6 | footway   |   |
>>  2 | path  |   |
>>  2 | pedestrian|   |
>>  3 | residential   |   | destination
>>  2 | residential   |   |
>>  2 | rest_area |   |
>>  2 | road  |   |
>>  9 | service   | alley | designated
>>  7 | service   | alley | no
>>  2 | service   | alley | private
>>  2 | service   | busway| no
>>  1 | service   | drive-through | no
>>  1 | service   | driveway  | designated
>> 81 | service   | driveway  | no
>>  6 | service   | driveway  | private
>>  4 | service   | emergency | no
>>  3 | service   | emergency_access  | destination
>>  4 | service   | emergency_access  | emergency
>>514 | service   | emergency_access  | no
>> 43 | service   | emergency_access  | private
>>  2 | service   | emergency_exit| no
>>  2 | service   | parking_aisle | designated
>>  4 | service   | parking_aisle | no
>>  1 | service   | parking_aisle | private
>>  5 | service   | parking_aisle | yes
>>  2 | service   | Service autoroute | no
>>  7 | service   |   | designated
>>  3 | service   |   | destination
>> 50 | service   |   | emergency
>>   1473 | service   |   | no
>>  1 | service   |   | official
>>  9 | service   |   | permissive
>>273 | service   |   | private
>>  2 | service   |   | psv
>>  3 | service   |   | service
>>  1 | service   |   | yes
>>  3 | services  |   |
>>  1 | track | driveway  |
>> 16 | track |   | 

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Philippe Verdy]

Le 31 août 2016 11:52, "Jérôme Seigneuret a écrit
> Il y a plein d'endroit on la vitesse est différente selon le sens de
circulation. Sachant que le rôle des panneaux EB10 et EB20 n'est que de
définir la vitesse par défaut dans et le nom de l'agglomération traversé.
Hors le nom on l'à par le découpage communale dans OSM.

Totalement faux. Le nom de l'agglomeration n'est pas le nom de la commune
qui n'est qu'une indication supplementaire (et optionelle) sur les panneaux
eb10 et eb20. Nomreuses sont les communes ayant plusieurs agglomerations
avec chacune leur nom et on a aussi des tas d'agglomérations a cheval sur
plusieurs communes. Le zonage urbain des agglomérations ne correspond pas
du tout au decoupage administratuf des communes. Meme pour les petites
communes rurales on trouve des agglomerztions multiples et ce cas est de
plus en plus tresuent maintenznt que les communes se regroupent.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Christian Quest]

Le 31 août 2016 à 11:08, Paul Desgranges  a
écrit :

> On 31/08/2016 08:42, Christian Quest wrote:
>


> Il est possible à partir des emprises des batiments de tracer un buffer de
> 50m et d'agglomérer tout ça pour avoir une approximation et détecter les
> manques.
>
> Il est "possible", mais moi perso je ne sais pas faire, si quelqu'un veut
> bien m'apprendre, je compléterais volontiers les cartes que j'avais fait
> fin 2015/début 2016  pour le concours
> dataconnexion
> 
> avec une carte de France donnant toutes les zones d'habitations
> agglomérées.
>
>
ça peut donner ça:
http://bl.ocks.org/anonymous/raw/e211c35a5f86fde3e73bf36e4e62146b/

J'ai sorti la surface de chaque polygone et le nombre de polygone
building=* qui sont à l'intérieur.

Le buffer est de 50m, les polygones avec moins de 3 polygones de b^ati sont
éliminés ainsi que ceux de moins de 1m2.


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

Re: [OSM-talk-fr] Voie de "services" des autoroutes

[Jérôme Seigneuret]

Salut,

Je mets pour les voies d'accès réservé à l'usage de service et d'urgence
qui sont fermé par un portail:
highway=service + access=private + emergency=yes

access=no et access=private et un peu problématique pour moi aussi.
access=no c'est pour un access impossible au grand public donc à moins d'y
ajouter une clause access:conditonal ...

Il y a aussi les portails d'accès pour les salariés pour entrer sur les
zones aires de repos ou de péage.

J'ai mis access=private car c'est géré par un opérateur qui peut
explicitement donner le droit à des sociétés d'accéder par ces portails
(contract de maintenace en sous-traitance et inventaires écologiques)

Ce n'est pas utilisé seulement pour des raisons urgence mais pour l'accès
au service afin d'arriver sur la voie pour faire l'entretien et la
vérification de certains tronçons.
Je pense qu'il y a différents cas possibles.

Jérôme

Le 31 août 2016 à 09:55, Frédéric Rodrigo  a écrit :

> Bonjour,
>
> Je n'ai rien trouvé sur le wiki et les usages en France sont variées.
>
> Je me pose la question de savoir comment doivent être taggé les voies
> connectées aux autoroutes ou parfois dans les aires et qui sont fermées
> avec des portails.
>
> Typiquement ce genre de chose :
>
> http://www.openstreetmap.org/#map=19/48.05394/0.35439
>
> J'ai analysé comment c'est fait en France, le cas le plus fréquent est
> highway=service + access=no (1473) devant highway=service +
> service=emergency_access + access=no (514)
>
> Je n'ai pas analysé les tags des portails.
>
> Voilà le détail :
>
>  count |highway|  service  |   access
> ---+---+---+-
>  5 | cycleway  |   |
>  8 | emergency_bay |   |
>  1 | escape|   | no
> 50 | escape|   |
> 10 | footway   |   | emergency
>  1 | footway   |   | permissive
>  6 | footway   |   |
>  2 | path  |   |
>  2 | pedestrian|   |
>  3 | residential   |   | destination
>  2 | residential   |   |
>  2 | rest_area |   |
>  2 | road  |   |
>  9 | service   | alley | designated
>  7 | service   | alley | no
>  2 | service   | alley | private
>  2 | service   | busway| no
>  1 | service   | drive-through | no
>  1 | service   | driveway  | designated
> 81 | service   | driveway  | no
>  6 | service   | driveway  | private
>  4 | service   | emergency | no
>  3 | service   | emergency_access  | destination
>  4 | service   | emergency_access  | emergency
>514 | service   | emergency_access  | no
> 43 | service   | emergency_access  | private
>  2 | service   | emergency_exit| no
>  2 | service   | parking_aisle | designated
>  4 | service   | parking_aisle | no
>  1 | service   | parking_aisle | private
>  5 | service   | parking_aisle | yes
>  2 | service   | Service autoroute | no
>  7 | service   |   | designated
>  3 | service   |   | destination
> 50 | service   |   | emergency
>   1473 | service   |   | no
>  1 | service   |   | official
>  9 | service   |   | permissive
>273 | service   |   | private
>  2 | service   |   | psv
>  3 | service   |   | service
>  1 | service   |   | yes
>  3 | services  |   |
>  1 | track | driveway  |
> 16 | track |   | no
>  4 | track |   | private
> 40 | track |   |
> 21 | unclassified  |   | no
> 19 | unclassified  |   | private
>  2 | unclassified  |   | service
>  2 | unclassified  |   | unknown
> 31 | unclassified  |   |
>  1 |   |   | no
>  4 |   |   | permissive
>
> Selon vous qu'elle est la bonne façon de faire (voies+portail) ? Ces voies
> sont-elles uniquement des voies utilisés en cas d'urgence ? Besoin d'une
> analyse Osmose pour faire converger ça en France ?
>
> Personnellement le access=no me dérange toujours un peu.
>
> Frédéric.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Jérôme Seigneuret

[Talk-cz] Mapovani vysilacu v OSM a GSMweb

[jiri2]

Ahoj,

až teď sem si všiml poměrně rozsáhlé diskuze mapování vysílačů. Krátce sem 
ji prošel. Bez ohledu jestli je detailní mapování jednotlivých antén pro OSM
přínosem mi to, ale přijde jako dělání už hotového. Vysílači pro mobilní 
telefony se celkem detailně i odborně zabývají lidé klem stránky www.gsmweb.
cz(http://www.gsmweb.cz/). V diskuzi jsem o nich zmínku nenašel. Zkoušel je 
někdo kontaktovat?

Co se týče televizního a rozhlasového vysílaní určitě tak existuje hodně 
fandů, kteří se jimi zabývají. Navíc informace o nich jsou celkem hojně 
publikovány i oficiálně.

Tyto dvě skupiny vysílačů myslím pokrývají dominantní část existujících. 
Myslím, že není moc efektivní snažit se je mapovat znova vlastním úsilím.

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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Tomas Straupis]

> Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?

  Osmose:
  http://osmose.openstreetmap.fr/lt/errors/?source=6641=7130=71301

> O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už tai, kad
> ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra pakankamai
> aukštas arba yra pažymėtas apribojimas. Taip nepridėliotumėm
> bereikšmių/neteisingų duomenų.

  Na čia keli pastebėjimai:
  1. Jei yra nuostatai, kad tunelis yra bent 5 metrų aukščio, tai
nereiškia, kad jis negali būti 6 metrų aukščio. Potencialiems tokios
informacijos naudotojams (sunkvežimiams su negabaritiniais kroviniais)
tokia info bus įdomi.
  2. Jei Lietuvoje yra standartas 5m., kitose šalyse gali būti 6
metrai arba tarkim 4,5. Kadangi OSM - pasaulinė db, tai gal vertėtų
įrašyti ir „standartinį Lietuvos“ aukštį. Sutinku, kad su tokia
argumentacija labai daug nereikalingų žymų galim pradėti dėlioti (pvz.
horse=no ant visų trunk:), bet tokių tunelių Osmose randa labai nedaug
(19)...

-- 
Tomas

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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Aidas Kasparas]

On 2016.08.31 11:20, Tomas Straupis wrote:

Sveiki

   Gal turite minčių, kur būtų galima rasti tunelių/tiltų aukščius?

   Norisi užpildyti tuneliams „maxheight“ žymą, kad validatoriai
nebesikabinėtų ir kad sunkvežimių maršrutizatoriai žinotų, kur
pravažiuoti galima/negalima.



Tomai,

Pirma, o kokie validatoriai kabinėjasi prie trūkstamos žymos?

Antra. aš įsivaizduoju, kad statybos normose yra kažkur reikalavimas, 
kad statant tiltą virš gatvės reikia naudoti mažiausiai tam tikrą 
aukštį. Jei tokio nepavyksta padaryti, tiltas turi būti paženklintas 
ženklu „Ribotas aukštis“. Spėju, kad tas aukštis yra 5 m. Nes kiek teko 
sutikti ženklus LT, visi buvo 4 su trupučiu arba mažiau.


O jei dėl (2) punkto aš nesu labai toli nuo teisybės, tai būčiau už tai, 
kad ir OSM'e laikytumėmės principo, kad arba tiltas/tunelis yra 
pakankamai aukštas arba yra pažymėtas apribojimas. Taip nepridėliotumėm 
bereikšmių/neteisingų duomenų.



--
Aidas Kasparas


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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Jérôme Seigneuret]

Le 31 août 2016 à 09:56, operon85  a écrit :

> Bonjour,
>
> * Les panneaux EB10/EB20 : Il faut les mettre là où il sont sur le terrain
> : Assez souvent ils ne sont pas l'un en face de l'autre mais à plusieurs
> dizaine de mètres donc difficile de mettre un traffic_sign au croisement de
> la voie de circulation.
>

C'est ton choix.  Nous en avons fait un différent en projetant le point sur
le réseau. Jusqu’aù jour où il y a aura une décision réel de prendre un cas
ou l'autre. Même combat sur l’implantation des feux de signalisation et
d'autres panneaux mais c'est pas le sujet.
Quand au panneau placé hors réseau, il faudra ajouter des information
supplémentaire pour en indiquer l'orientation car le panneau peut aussi
être placé à gauche de la voie.

Le problème sur le décalage est aussi un faux problème car dans ce cas on
met deux points et de toute façon on qualifie la vitesse sur le réseau avec
maxspeed:forward et maxspeed:backward
Il y a plein d'endroit on la vitesse est différente selon le sens de
circulation. Sachant que le rôle des panneaux EB10 et EB20 n'est que de
définir la vitesse par défaut dans l'agglomération et le nom de
l'agglomération traversé. Hors le nom on l'à par le découpage communale
dans OSM.


>
> * " avoir accès aux textes (arrêtés municipaux ...) qui définissent les
> limites de ces agglomérations... " : C'est le cas avec la mise en place de
> RLP et RLPi (intercommunal) qui doivent comporter la positions des panneaux
> et le contour des zones. En 2016 la plupart des communes mettre à dispo les
> arrêtes municipaux sur internet.
>

En effet c'est une source intéressante pour le zonage. Reste à voir si elle
est cohérente en terme d'échelle de saisie avec celle des limites
d'agglomération défini par le code de la route.

Il y a un travail à faire de recensement des données sources et de
vérification de la qualité de ces informations.

* Tracer ces données dans OSM,  très ambitieux !!! : Certes mais pas plus
> que les passages piéton, les feux tricolores, 
>

Ca c'est clair mais on n'a pas besoin de grand chose sauf voir une ortho et
un passage sur le terrain. Ne pas confondre complexité à l'intégration et
masse de données à intégrer



> * Calcul automatique à partir de CLC : Pas possible pour plusieurs raisons:
>  - CLC, pas assez précis (dans la plupart des cas). CLC est censé
> représenté la réalité physique des contours des differentes zones pas les
> contours administratifs.
>
Qui à parler de ça... J'ai raté un passage? Bref c'est pas une réalité
physique mais une réalité de couverture à une échelle de saisie
complètement foireuse d'où l'ajout de nouveau landuse là où c'est
nécessaire et le coupage des landuse résultant d'un import CLC. OSM à pour
but de représenter les info à une précision métrique (voir inférieur) et la
CLC c'est une précision de 30m avec des entités d'une superficie minimum ce
qui n'est pas le cas dans OSM.


> - Les limites des agglomération ne correspondent pas avec " bâti
> rapproché". " il y a encore un cas où les panneaux ne correspondent pas à
> l'agglomération réelle : quand le maire prévoit l'étalement urbain et
> positionne les panneaux là où sera la limite quand après une révision du
> PLU les champs auront été transformés en lotissement." C'est vrai (très
> souvent) mais la position des panneaux EB10/EB20 sont ceux qui nous sont
> opposable pour la lois (Vitesse par exemple). Sinon il faut (avant que l'on
> nous oppose ces limites)  à faire annuler l’arrêté municipal fixant les
> limites de l'agglomération. D'où la différence entre CLC (réalité terrain)
> et Agglomération (réalité administrative).
>
J'ai pas compris le rapport mais dans tous les cas on ne peut pas se baser
sur une couverture pour définir un espace règlementaire.


>
> * Pour la publicité, des enclaves pour domaine privé et autres : C'est un
> faux problème (pour l'instant) je n'ai encore jamais vu (par exemple pour
> les vitesse) une voie privée affublé de "maxspeed=no_limit".
>
Le maxspeed n'a pas de rapport avec la publicité mais clairement un circuit
privé n'a pas de vitesse limité. Elle est limité par la personne privé et
par la qualité de la route à emprunter.


>
> * L'article R.110-2 du code de la route et l'Art. R.411-2 du code de la
> route ne sont pas antinomique, c'est juste une précision de Qui (R411) doit
> fixer les limites dans le respect du R110.
>
> * Tout à fait d'accord avec Christian, il ne faut pas pointer un usage
> particulier.
> Ces panneaux sont en place, les contours sont définis, ils peuvent servir
> à un ou plusieurs usage.
>
J'ai pointer en réponses @Paul Desgegranges


>
> Mon usages particulier (mais pas personnel) est la projection vertical des
> contours des agglomération pour en faire des zones aérienne à condition
> particulières afin de respecter la réglementation aérienne. Beaucoup
> utilise leur système de géoguidage (GPS) sur la route mais moi j'aimerais
> l'utiliser en vol parce que déplier une carte de 1 

Re: [Talk-in] India - Bangladesh enclaves/exclaves on OSM

[Devdatta Tengshe]

You can get the list of enclaves in the actual 1974 agrement which was
signed, and is mentioned in the 119th Amendment of the Constitution.

You can get more details here:
http://www.prsindia.org/billtrack/the-constitution-119th-amendment-bill-2013-3049/

The actual list is present pg 5 onward in this pdf:
http://www.prsindia.org/uploads/media/Constitution%20119/Constitution%20%28119th%29%20Bill,%202013.pdf



Regards,
Devdatta

On Wed, Aug 31, 2016 at 2:50 PM, Jinal Foflia  wrote:

> Hello everyone,
>
> Came across this blog [1] on the enclaves and exclaves issue related to
> India - Bangladesh. Do we have any official document about the swap of
> enclaves between Bangladesh and India? Also the data on OpenStreetMap says
> that we have 2 remaining exclaves, was there a complete swap of
> enclaves/exclaves? How should the data be updated on OSM?
>
>
>
> [1] - http://www.gearthblog.com/blog/archives/2016/08/india-
> bangladesh-enclaves.html
>
> Some more articles (These are articles from different sources)
>
> - https://www.washingtonpost.com/news/worldviews/wp/2015/
> 08/01/say-goodbye-to-the-weirdest-border-dispute-in-the-world/?tid=a_inl
> - http://zeenews.india.com/news/west-bengal/celebrations-
> erupt-in-cooch-behar-after-india-bangladesh-ratify-lba_1608611.html
> - http://zeenews.india.com/tags/land-boundary-agreement.html
> - http://www.thehindu.com/news/national/indiabangladesh-land-
> boundary-agreement-security-a-prime-concern-after-enclaves-
> exchange/article7491756.ece
>
> Cheers,
> Jinal Foflia
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-it] Tag preset JOSM x terremoto

[Cascafico Giovanni]

Ho cercato velocemente nel lunghi thread che ho trovato al.rientro dalle
ferie senza trovare: eventualmente scusatemi se mi è sfuggito.

Nelle istruzioni dei task manager non vedo riferimento a xml di preset
JOSM  per uniinformare la mappatura
Ci sono? Dove?

Ho visto che i tag sono basati su Haiti. Non ci sono state evoluzioni dopo
il Nepal?


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

Re: [Talk-lt] Tunelių/tiltų aukščiai

[Tomas Straupis]

> Be jokios abejonės - pas kelininkus. O ar jie turi db, ar leidžia ja
> naudotis tai geras klausimas.

  http://eismoinfo.lt/ nėra aukščių... Tada teks parašyti tiesiai LAKD
ir paklausti.

-- 
Tomas

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

Re: [OSM-talk-fr] Les limites des agglomérations (zones bâtit)

[Philippe Verdy]

Usage particulier, mais quand même on a déjà dans OSM des données pour
indiquer les limites de vitesse par défaut en "agglomération" et pas qu'en
France d'ailleurs. Mais impossible de voir dans les données OSM où sont ces
agglomérations.

De plus on le sait il n'y a pas de noeuds avec les panneaux partout (et
souvent même on n'a pas toujours des panneaux partout ni affichant les
mêmes noms : le "name" renseigne le nom de l'agglomération qui n'est pas
forcément une commune mais un village appartenant à une plusieurs communes,
mais ce nom est complété en dessous de la mention de la commune (en plus
petit et italique sur la panneaux français, la mention "Commune de" étant
souvent abrégée en "Cne de").

L'autre problème est que les panneaux d'entrée et de sortie d'agglomération
ne sont pas forcément juste en face du même point sur une route
bidirectionnelle. Et ces noeuds indiquent mal dans quelle direction ils
s'appliquent. On ne peut pas facilement les interpréter pour savoir quel
est la direction de la route dans ou hors de l'agglomération.

Ces noeuds ne sont donc pas toujours non plus directement sur le way si on
doit différencier deux positions sur la route pour l'entrée ou pour la
sortie (il est fréquent que l'entrée de l'agglomération d'un côté de la
route soit plus éloigné du centre mais que le panneau de sortie soit plus
tôt, à cause des distances de freinage ou des questions de visibilité quand
c'est dans un virage. Dans quelques cas, les noeuds sont placés directement
sur un croisement de routes et il y a ambiguité sur quelles routes on a une
entrée ou sortie d'agglomération.

Ce n'est pas simple. C'est pour ça qu'il est nettement plus facile de
taguer les limites de vitesse directement sur les voies, même sans poser
des noeuds pour les panneaux.


Le 31 août 2016 à 08:42, Christian Quest  a écrit :

> Attention à ne pas se concentrer sur un usage particulier de ce type de
> limite !
>
> Je pense ici aux références aux publicités... il y a tellement de
> paramètres à prendre en compte qu'il me semble difficile d'aller jusqu'à
> avoir globalement des zones précises dans OSM pour cet usage bien
> particulier. Il est possible de le faire au cas par cas, si l'on a des
> documents officiels sur lesquels s'appuyer, mais de là à généraliser...
> c'est un chantier titanesque.
>
> L'usage plus facile et direct me semble celui des limites de vitesses, en
> approximation, quand aucun maxspeed n'est indiqué sur les highway=*
>
> Les polygones CLC sont à affiner ET à compléter. Dans de nombreux petits
> villages, il n'y a aucun landuse=residential.
> Il est possible à partir des emprises des batiments de tracer un buffer de
> 50m et d'agglomérer tout ça pour avoir une approximation et détecter les
> manques.
>
> --
> 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