Re: [OSM-talk-fr] Suppression du tag ISO3166-1 sur la relation France Métrpolitaine

[Philippe Verdy]

Je pense que celui qui a supprimé ce code a pensé qu'il n'était pas
nécessaire, croytnat que FR est suffisant alors que ça inclue toute la
France y compris les outre-mer qui ont (pour certains mais pas tous) leur
propre code ISO 3166-1.
Quitte à remettre un code ISO (si l'identifiant Wikidata ne te semble pas
plus stable que les codes ISO), autant que ce soit sur un tag différent,
ISO3166-1 avec un suffixe de date mentionnant l'année où le code était
encore standard.


Le 19 mars 2017 à 00:56, Philippe Verdy  a écrit :

> C'est vrai qu'il n'y avait aucune obligation à le faire (même si le code a
> été rendu obsolète dans I'ISO, il reste inutilisé pour autre chose pour
> l'instant)
> Sinon tu peux toujours utiliser la recherche par nom, ou par
> wikidata=Q212429 qui garde un identifiant stable
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_-3320696704903509563_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Le 19 mars 2017 à 00:06, François Lacombe  a
> écrit :
>
>> Bonsoir,
>>
>> Tout est dans le titre, dans un changeset datant d'il y a 5 jours, la
>> relation "France métropolitaine" a perdu son tag ISO3166-1=FX.
>> https://www.openstreetmap.org/relation/1403916
>>
>> Résultat mes requêtes Overpass sont par terre, parce que je m'en servais
>> pour constituer une area.
>>
>> Il y a eu une décision provoquant ce changement à côté de laquelle je
>> serai passé ?
>> Sinon je suis pour un revert, parce que ca me semble très structurant.
>>
>> Sur la relation France, on voit apparaitre ISO3166-1:numeric,
>> ISO3166-1:alpha2...
>> https://www.openstreetmap.org/relation/2202162
>>
>> Merci par avance
>>
>> François
>>
>> --
>> *François Lacombe*
>>
>> fl dot infosreseaux At gmail dot com
>> www.infos-reseaux.com
>> @InfosReseaux 
>>
>> ___
>> 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-us] West Point

[Kevin Kenny]

On Sat, Mar 18, 2017 at 12:01 AM, Kevin Kenny 
wrote:

> But then I realized that West Point is mapped rather peculiarly - rather
> than being a multipolygon with landuse=military, as I'd have expected, it's
> mapped as a city, boundary=administrative, admin_level=8. It is not a city,
> it is a military base, no different from any other. It is large, and
> therefore it extends into three townships. The relevant parcels are part of
> the Towns of Woodbury, Cornwall and Highland. The boundary between Woodbury
> and Highland had been included in the relation for West Point, possibly in
> an effort to make it a city within the Town of Highland?
>
> In any case, I realized that in moving the boundaries of the reservation,
> I was also adjusting township lines. I'm fairly certain that I managed to
> put them back.
>

Committing the sin of following up to my own message:

The West Point polygon came from TIGER 2008, because West Point is a Census
Designated Place. When I discovered that, I refreshed my memory by going
through the painful exercise of reading through all the threads on CDP's
linked from
https://wiki.openstreetmap.org/wiki/United_States_admin_level#cite_ref-35.
New York mappers seem to have reached an overwhelming consensus that CDP's
here are simply for the convenience of the Census Bureau and have
relatively little relationship to facts on the ground. (The situation may
be different in other parts of the country.)

The inaccurate borders are substantially identical to the 2015 file of
CDP's digitized at 1:500,000 scale. At such a small scale, it's no surprise
that borders don't line up!

Even before I started touching the relation, other mappers have made
changes, so I am certain that the relation no longer reflects the CDP. In
the unlikely event that we need the Census Bureau's definition of the
place, the best approach would be to reimport it.

In the meantime, I'm making the unilateral decision to remove the TIGER
tagging and administrative boundary status from the thing, and work on
replacing it wholesale by building it from component ways that represent
the borders from Orange County's GIS. Of course, the boundaries will be
checked against Bing imagery where they appear to follow natural or
cultural features, and conflated with polygons from New York State Office
of Parks, Recreation and Historic Preservation and with existing OSM
features where appropriate.

I'll try to break up and share the ways in the places where the boundaries
of the reservation actually coincide with the boundaries of something else.
These boundaries will be the bank of the Hudson River, and the lines on the
ground where the reservation borders another property that we map, without
a public right of way in between. There are such land borders with at least
three state parks (Bear Mountain, Harriman and Storm King), the Black Rock
Forest, and a golf course in Central Valley. I plan to offset the ways at
highway rights-of-way and at the railroad, as the tax maps generally do.

 The result is bound to be better than the unholy mess that we have there
today. https://flic.kr/p/T1k89u 
https://flic.kr/p/T1k85m

Last night, I was quite afraid of breaking something, but I've realized
since that anything I'd break is already badly broken. Better just to
forget about the TIGER stuff and get the job done more nearly right.

Thanks to anyone that read this far!
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] OpenStreetMap sur Ixquick

[Philippe Verdy]

Moteur de recherche le "plus confidentiel" du monde... mais "renforcé par
Google". Tellement confidentiel que bien peu devaient même le connaitre.

Peut-être qu'ils ne communiquent pas directement nos données à google, mais
le site collecte bien des données pour lui (on ne sait pas ensuite à qui il
le communique, et cela ne l'empêche pas d'inclure des scripts de
partenaires publicitaires (indirectement ça retombe donc de toute façon sur
DoubleClick et consors).
Seulement bravo quand même car tout vient de leur propre domaine (ils
gardent le contrôle total des données de profilage).
Pas de cookie mais un identifiant de session quand même (mais je ne pense
pas qu'ils puissent faire mieux), et HTTPS par défaut.

Cependant chapeau pour Ixquick ! Ils ont mis leur serveur de tuile (ou un
proxy cache)
https://b-eu-map.ixquick.com/osm/{{{z}}}/{{{x}}}/{{{y}}}.png

Apparemment juste un HTTP GET, pas un seul cookie transmis ni
d'authorisation dans un entête MIME. Ce serveur est-il ouvert à tout le
monde ?
Exemple:
https://b-eu-map.ixquick.com/osm/6/31/22.png


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le 18 mars 2017 à 21:30,  a écrit :

> Sur le moteur de recherche Ixquick  les
> cartes par défaut sont maintenant des cartes OpenStreetMap (et non plus
> G...).
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression du tag ISO3166-1 sur la relation France Métrpolitaine

[Philippe Verdy]

C'est vrai qu'il n'y avait aucune obligation à le faire (même si le code a
été rendu obsolète dans I'ISO, il reste inutilisé pour autre chose pour
l'instant)
Sinon tu peux toujours utiliser la recherche par nom, ou par
wikidata=Q212429 qui garde un identifiant stable


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le 19 mars 2017 à 00:06, François Lacombe  a
écrit :

> Bonsoir,
>
> Tout est dans le titre, dans un changeset datant d'il y a 5 jours, la
> relation "France métropolitaine" a perdu son tag ISO3166-1=FX.
> https://www.openstreetmap.org/relation/1403916
>
> Résultat mes requêtes Overpass sont par terre, parce que je m'en servais
> pour constituer une area.
>
> Il y a eu une décision provoquant ce changement à côté de laquelle je
> serai passé ?
> Sinon je suis pour un revert, parce que ca me semble très structurant.
>
> Sur la relation France, on voit apparaitre ISO3166-1:numeric,
> ISO3166-1:alpha2...
> https://www.openstreetmap.org/relation/2202162
>
> Merci par avance
>
> François
>
> --
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Suppression du tag ISO3166-1 sur la relation France Métrpolitaine

[François Lacombe]

Bonsoir,

Tout est dans le titre, dans un changeset datant d'il y a 5 jours, la
relation "France métropolitaine" a perdu son tag ISO3166-1=FX.
https://www.openstreetmap.org/relation/1403916

Résultat mes requêtes Overpass sont par terre, parce que je m'en servais
pour constituer une area.

Il y a eu une décision provoquant ce changement à côté de laquelle je serai
passé ?
Sinon je suis pour un revert, parce que ca me semble très structurant.

Sur la relation France, on voit apparaitre ISO3166-1:numeric,
ISO3166-1:alpha2...
https://www.openstreetmap.org/relation/2202162

Merci par avance

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Fixing broken multipolygons, some notes

[Frederik Ramm]

Sandor,

   if I understand you correctly your basic message is "let's try and
improve osm2pgsql's polygon interpretation rules instead of fixing the
data", or at least "while we wait for the data fixing to be completed".

I think this is not a good idea because, as you remark yourself, those
working with the OSM source data directly will not profit from more
magic in osm2pgsql. We would have more situations where someone
processes OSM data with, say, QGIS and thinks "uh, I must have done
something wrong, because on the OSM map there's a forest here and on my
map there isn't".

Fixing the data in OSM is the better approach. In many cases, broken
polygons are a result of a broken import or careless editing and if
MapRoulette prompts someone to open their editor in that location, they
are likely to find quite a few other things worth of attention.

> The “Fixing broken polygons”, especially programmatic/mass fixing, could
> be more dangerous to all users.

I wholly agree that, with perhaps a very few narrowly defined
exceptions, nobody should make an attempt to fix broken polygons
automatically because many things go wrong (and the automatic fix would
not give us the advantage I mentioned above, that someone looking at the
data in the area might find other things amiss).

> Let us look at a map extract from the
> mentioned Scandinavian forests

It has been suggested to completely remove some CORINE-based landcover
import in Scandinavia on the basis that not only there are many broken
polygons, but also that it bears very little resemblance to the reality
on the ground. People have said it is a nicely painted map but not much
more. But I believe the local community said they preferred a nicely
painted and somewhat wrong map over having to trace the forests from
aerial imagery themselves ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Sortie de MapContrib 1.6

[François Lacombe]

Bonsoir Guillaume,

Merci pour les infos et le travail jusque là

Très sympa cette évocation d'une intégration Osmose, impatient de tester ca
;)

A+

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 17 mars 2017 à 20:07, Guillaume AMAT  a écrit :

> Salut !
>
> MapContrib est de sortie pour sa nouvelle version mensuelle. Pas de gros
> changements mais on aime bien livrer les nouveautés assez tôt et
> régulièrement.
>
> Dans les grandes lignes, MapContrib a maintenant 4 fonds de carte activés
> par défaut (OSM, OSM monochrome, Watercolor et Mapbox satellite) et un
> bouton « Afficher plus de fonds » juste en-dessous, le créateur de thème
> peut forcer la valeur d'un tag via les presets et quelques colonnes ont
> maintenant un bouton retour pour faciliter la navigation dans l'interface.
>
> Vous trouverez plus de détails dans l'article dédié sur le blog :
> https://blog.mapcontrib.xyz/fr/2017/03/mapcontrib-1-6
>
> Guillaume
>
> ___
> 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-gb-westmidlands] Import Progress

[Rob Nickerson]

Hi Brian,

Thanks for the great work here - it's been 9 years since the bus stop data
in Birmingham was this good so great to see such a step change improvement
in the data. Just a few of the orphaned stops to work through.

Also great to see such rich tree data going in. Sorry I never got round to
testing the conflate tool but I see you have your method instead :-)

The bus lanes will help too. They are being removed in Coventry (well, at
trial removal stage so far), but good to add them where they still exist.

Best regards,

*Rob*

On 18 March 2017 at 18:52, Brian Prangle  wrote:

> Hi All
>
> I'm off for a break and I'm leaving a couple of key imports partially
> complete so I thought it best to give you an update of where I'm at:
>
> Trees
>
> 47,000 imported so far (out of a total approx 76,000)- none north of the
> M6 which I've left for Andy R. Less than 0.1% (estimate) are positioned in
> roads or front gardens - a slight improvement of either the road or landuse
> alignment fixes these.  Before any import I've deleted any roadside trees
> added from aerial imagery. There were only 4 trees in the West Midlands
> tagged with species information - all monkey puzzle trees tagged by AndyR
> and all N of the M6. There are trees in the database that have been cut
> down - I think the field value is  "asset to be de-accrued"  and there  a
> few labelled as "pre-contract stumps". I'm generally just doing a blanket
> import and will clean these up later, unless it's an area I know well where
> I'm deleting them manually.
>
> Naptan bus-stops
>
> All pre-existing OSM  bus stops have been upgraded with new naming format,
> route_ref, and Towards tags, and OSM position left intact. All pre-existing
> naptan nodes in OSM  without the bus stop tag have had the bus stop tag
> added as well. Their position obviously will not have been verified by
> survey, but this method offfers completeness
>
> All pre-existing OSM bus stops that have been deleted in naptan have had
> the highway=bus_stop tag removed and a note added explaining what's
> happened. Feel free to delete any you come across.
>
> All new CUS stops have been imported (approx 230)- mainly because they
> don't render. A gradual review will be necessary as I've found in areas
> that  I know  well that many of these now have poles and should be MKD in
> the naptan data, and I've tagged them as bus stops where I've surveyed them.
>
> I'm gradually working through the approx 300 OSM "orphan bus stops" that
> have been surveyed but have no naptan tags. So you'll still see some
> duplicates in places. Where this is the case transfer any extra tags like
> shelter present and shelter ref no to the adjacent naptan node and delete
> the orphan. In most cases where I've done this the OSM position of the
> orphan node is better than naptan so move the naptan node to the position
> of the orphan
>
>  Some of the OSM pre-exisitng bus stops are nothing to do with naptan (e.g
> NEC and Airport car park shuttles) so I'm tagging these with naptan=no.
> About 20 of these so far
>
> Any bus stops where I find there is a discrepancy beween naptan and OSM
> I'm tagging with naptan_refresh=query (most of  these have been Ring and
> Ride stops, or poles flagged physically with NOT IN USE). About 40 of these
> so far.
>
> That leaves about 800 new bus stops which are yet to be imported. Some of
> these will match "orphan bus-stops". The remainder I'm hesitant to import
> as they're either poorly positioned or just don't exist. So it's probably
> going to be a long manual comparison slog. Or we live with this level of
> questionable data and import them
>
> Around the larger interchanges and bus stations  I've been adding a
> stop_area relation and adding the public_transport=platform tags to the bus
> stops. NB these are topographical areas and have no relation to naptan stop
> areas
>
> The last task remains to import the data on shelters, which I'll be
> getting from TfWM towards the end of April
>
> Bus Lanes
>
> TfWM are asking local authorities other than Birmingham (which I've
> already added- but we do need the times for adding conditional tags which
> can only be done with surveys)) for their bus lane data. So far I have
> shapefiles for Wolverhampton. Does anyone fancy adding these?
>
> Regards
>
> Brian
>
>
>
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [OSM-talk] Fixing broken multipolygons, some notes

[john whelan]

There has been some discussion on the HOT mailing list that makes things a
bit clearer.

OSM in general has a fair number of things that have been added in a less
than ideal way.  It can be difficult to correct some things as we have
guidelines or recommended practises as opposed to hard and fast rules but
maproulette has managed to identify a number of areas where there is some
agreement about what needs to be corrected.

JOSM validation also tries to identify problem areas so I suspect fixing
the underlying data is the better long term solution rather than ensuring
all the different rendering systems are more robust.  Robustness costs
machine cycles​ as well.

Cheerio John

On 18 Mar 2017 4:43 pm, "Sandor Seres"  wrote:

> I am new to this list and therefore apologize for eventual
> misinterpretations and wrong stile. The motivation for the mail is a
> worrying mail on the local list about the purer osm2pgsql based maps and
> about the “broken polygons” fixing strategies. The mentioned white spots in
> the Scandinavian forests are just an illustration. By simply dropping
> broken polygons, empty spots will be typical for any area types and for any
> corners of the Planet.
>
> As I understand, osm2pgsql is an application doing data preparation from
> the OSM source data up to a DB used by many mapmakers for rendering. We can
> see that almost all OSM based public mapping system use this database and
> consequently repeat the same anomalies. Therefore, maybe, making the
> osm2pgsql more robust could be a better strategy. There is still a large
> potential for such strengthening. Just waiting for “do-ocracy” reparations
> is really a long-term strategy. Anyway, users starting from the source OSM
> data will not be affected by any of these strategies.
>
> The “Fixing broken polygons”, especially programmatic/mass fixing, could
> be more dangerous to all users. Just look at the many possible
> self-crossing fixing options. Loosely defined notions open for different
> interpretations and different sets of error criteria. Consequently, for the
> same object type we may have (and we do) different error classes and
> reparation tools. Besides the typical polygon interpretations as area (ESRI
> polygon redefinition) or as a closed polygonal line, we simply can’t find
> in the documentation what “outer”, “inner”, “hole” … notions actually mean.
> The interpretation (individual perception) of these notions is left to us
> and there we have a source of misunderstandings. For instance, if we assume
> that “outer” border polygons define the interior candidate points (points
> inside and on the border) and “inner” border polygons define (in the same
> way) exterior points of area than self-crossings, touching polygons,
> polygon overlaps, crossings… are not errors at all.
>
> However, my point here is still something else. The “broken multipolygon”
> (whatever that means) issue is just “the tip of the iceberg”. There is
> still remaining huge number of anomalies caused by area object relations
> from different area classes. I intentionally use the anomaly notion, as a
> moderate form for error, because many people/mapmakers may liv with them.
> But a modern GIS system and a vector layers based digital cartography
> cannot tolerate them. Let me present some arguments and illustrations. Let
> us look at a map extract from the mentioned Scandinavian forests here
> http://osm.org/go/0Tt1PZIt- . The example could be taken from any corner
> of the Planet and, as mentioned, there is huge number of similar cases. At
> the first glance, everything looks correct and nice (and it is). However,
> we see immediately that something is still wrong. The forest type symbols
> are placed directly over the water. In another style, typical land related
> names are on the water like here http://osm.org/go/0Tt1PZIt-?layers=T .
> Looking at the source data we can see that the lake in the middle is placed
> over an empty space (intentionally, not a hole) where the border of the
> lake runs slightly in and outside the forests. At the same time, we can see
> many forest areas inside the mentioned empty space overwritten with the
> lake that has no holes. Consequently, there are many missing islands in the
> lake and many missing forest areas in the extract. Note that only on that
> little extract there are more than 40 of the described anomalies. What
> more, there are many lakes with borders running in/out of forest areas
> (corridor border overlaps), having considerable parts over a forest and
> holes in forests, partly overlapping several disjunctive forest areas and
> so on, and the contrary. Extending the case to the Planet and other area
> types combinations we may feel the extent of the issue. There were attempts
> to compensate these problems in renderings like rendering the holes,
> rendering smaller over larger objects and so on. These actions generally do
> not work. Simply, they do good some places and damaging 

[OSM-talk] Fixing broken multipolygons, some notes

[Sandor Seres]

I am new to this list and therefore apologize for eventual
misinterpretations and wrong stile. The motivation for the mail is a
worrying mail on the local list about the purer osm2pgsql based maps and
about the "broken polygons" fixing strategies. The mentioned white spots in
the Scandinavian forests are just an illustration. By simply dropping broken
polygons, empty spots will be typical for any area types and for any corners
of the Planet. 

As I understand, osm2pgsql is an application doing data preparation from the
OSM source data up to a DB used by many mapmakers for rendering. We can see
that almost all OSM based public mapping system use this database and
consequently repeat the same anomalies. Therefore, maybe, making the
osm2pgsql more robust could be a better strategy. There is still a large
potential for such strengthening. Just waiting for "do-ocracy" reparations
is really a long-term strategy. Anyway, users starting from the source OSM
data will not be affected by any of these strategies.

The "Fixing broken polygons", especially programmatic/mass fixing, could be
more dangerous to all users. Just look at the many possible self-crossing
fixing options. Loosely defined notions open for different interpretations
and different sets of error criteria. Consequently, for the same object type
we may have (and we do) different error classes and reparation tools.
Besides the typical polygon interpretations as area (ESRI polygon
redefinition) or as a closed polygonal line, we simply can't find in the
documentation what "outer", "inner", "hole" . notions actually mean. The
interpretation (individual perception) of these notions is left to us and
there we have a source of misunderstandings. For instance, if we assume that
"outer" border polygons define the interior candidate points (points inside
and on the border) and "inner" border polygons define (in the same way)
exterior points of area than self-crossings, touching polygons, polygon
overlaps, crossings. are not errors at all. 

However, my point here is still something else. The "broken multipolygon"
(whatever that means) issue is just "the tip of the iceberg". There is still
remaining huge number of anomalies caused by area object relations from
different area classes. I intentionally use the anomaly notion, as a
moderate form for error, because many people/mapmakers may liv with them.
But a modern GIS system and a vector layers based digital cartography cannot
tolerate them. Let me present some arguments and illustrations. Let us look
at a map extract from the mentioned Scandinavian forests here
http://osm.org/go/0Tt1PZIt- . The example could be taken from any corner of
the Planet and, as mentioned, there is huge number of similar cases. At the
first glance, everything looks correct and nice (and it is). However, we see
immediately that something is still wrong. The forest type symbols are
placed directly over the water. In another style, typical land related names
are on the water like here http://osm.org/go/0Tt1PZIt-?layers=T . Looking at
the source data we can see that the lake in the middle is placed over an
empty space (intentionally, not a hole) where the border of the lake runs
slightly in and outside the forests. At the same time, we can see many
forest areas inside the mentioned empty space overwritten with the lake that
has no holes. Consequently, there are many missing islands in the lake and
many missing forest areas in the extract. Note that only on that little
extract there are more than 40 of the described anomalies. What more, there
are many lakes with borders running in/out of forest areas (corridor border
overlaps), having considerable parts over a forest and holes in forests,
partly overlapping several disjunctive forest areas and so on, and the
contrary. Extending the case to the Planet and other area types combinations
we may feel the extent of the issue. There were attempts to compensate these
problems in renderings like rendering the holes, rendering smaller over
larger objects and so on. These actions generally do not work. Simply, they
do good some places and damaging at other places. So, the question is
whether and what can we do with the problem. Just waiting for do-ocracy
based reparations is, obviously, irrational. Fortunately, the source data
has a large potential to remove most of the mentioned anomalies. Let me
present some hints in bullets for the forests, lakes and river combinations.

Assume {F0} is a set of all forest outer border polygons (closed polygonal
lines) and {F1,L0,R0} is a set of all inner forest, outer lake and outer
river border polygons (the orientations and the relations are irrelevant).
Then, you can prove the existence of minimal disjunctive simple area
coverage of the forests. In other words, you can find a set of isolated
simple areas (one outer and zero or any number of inner polygons) where any
area point is on/inside of at least one element in {F0} and never on/ inside
of any element in 

[OSM-talk-fr] OpenStreetMap sur Ixquick

[osm . sanspourriel]

Sur le moteur de recherche Ixquick  les 
cartes par défaut sont maintenant des cartes OpenStreetMap (et non plus 
G...).


Jean-Yvon

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

Re: [OSRM-talk] getting into Oxford Street

[Philip Barnes]

On Thu, 2017-03-16 at 14:21 +, Alan Bell wrote:
> Hi all
> 
> there is a segment of Oxford Street in London from about the Park 
> Street/Portman Street crossing to Regent Street where the turn 
> restrictions prevent you from going straight on into it, or turning
> left 
> or right from any of the crossing roads.
> 
> http://map.project-osrm.org/?z=15=51.514218%2C-0.130098=51
> .515313%2C-0.140419=51.514525%2C-0.147876=en=0
> 
> so without any one way street issues, this is an area of perfectly
> good 
> road from which you can exit but never enter.
> 
> I am not entirely sure what the facts on the ground are (it isn't a
> very 
> sensible place to be driving) but is there something that can be done
> in 
> the profile or by editing the map to avoid that bit of road if it
> has 
> actually been pedestrianised or something?
> 
> Alan.
> 
Hi Alan
I looks perfectly correct to me, you can access certain sections to
leave side streets. The section you were initially going into is tagged
as motor_vehicle=no, bus=yes, psv=yes.

There is nothing wrong with OSRM in this area.

If you are unsure it would be better to ask on talk-gb where you will
find local mappers who can explain the reasoning for the tagging.

Or try #osm-gb on irc.

Phil (trigpoint)



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

Re: [OSRM-talk] getting into Oxford Street

[Alan Bell]

that is great thanks, I think it wasn't showing as pink because it isn't
fully isolated (it is a source, you can leave, but not get there) and it
was isolated by turn restrictions rather than barriers or one ways. I think
the facts on the ground are that it is only for buses and taxis, but I will
try and visit there at some point over the next few weeks and survey it
properly.
Off to London protesting against Brexit at the weekend, so maybe I will
have a quick peek then!

On Sat, Mar 18, 2017 at 6:46 PM, Daniel Patterson  wrote:

> Hi Alan,
>
>   Hmm, the best way to figure this out is going to be to use the OSRM
> debug map:
>
> http://map.project-osrm.org/debug/#15.79/51.5140/-0.1515
>
>   This shows roads that are routable (colored), and roads that are
> isolated from the rest of the network (highlighted in pink).
>
>   I can see that there are some missing roads as well - this means that
> OSRM has removed these from the routing network,
>   usually because of access restrictions (i.e. no cars allowed).
>
>   This node:
>
> http://www.openstreetmap.org/node/2198870645
>
>   indicates that you can't continue straight along Oxford Street there -
> you're only allowed to turn left.  I don't know if this is real or not.
>   There are also no turns allowed from Regent St onto Oxford St here -
> this is preventing access to the section of Oxford St just to the
>   west here.
>
>   The OSRM demo server updates with new data every couple of days.  If you
> make changes to OSM, you can check:
>
> http://router.project-osrm.org/status
>
>   to see what data the OSRM demo server is using, and whether any changes
> you've made have taken effect yet.
>
> daniel
>
> On Mar 16, 2017, at 7:21 AM, Alan Bell  wrote:
>
> Hi all
>
> there is a segment of Oxford Street in London from about the Park
> Street/Portman Street crossing to Regent Street where the turn restrictions
> prevent you from going straight on into it, or turning left or right from
> any of the crossing roads.
>
> http://map.project-osrm.org/?z=15=51.514218%2C-0.
> 130098=51.515313%2C-0.140419=51.514525%2C-0.147876=en=0
>
> so without any one way street issues, this is an area of perfectly good
> road from which you can exit but never enter.
>
> I am not entirely sure what the facts on the ground are (it isn't a very
> sensible place to be driving) but is there something that can be done in
> the profile or by editing the map to avoid that bit of road if it has
> actually been pedestrianised or something?
>
> Alan.
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[Talk-gb-westmidlands] Import Progress

[Brian Prangle]

Hi All

I'm off for a break and I'm leaving a couple of key imports partially
complete so I thought it best to give you an update of where I'm at:

Trees

47,000 imported so far (out of a total approx 76,000)- none north of the M6
which I've left for Andy R. Less than 0.1% (estimate) are positioned in
roads or front gardens - a slight improvement of either the road or landuse
alignment fixes these.  Before any import I've deleted any roadside trees
added from aerial imagery. There were only 4 trees in the West Midlands
tagged with species information - all monkey puzzle trees tagged by AndyR
and all N of the M6. There are trees in the database that have been cut
down - I think the field value is  "asset to be de-accrued"  and there  a
few labelled as "pre-contract stumps". I'm generally just doing a blanket
import and will clean these up later, unless it's an area I know well where
I'm deleting them manually.

Naptan bus-stops

All pre-existing OSM  bus stops have been upgraded with new naming format,
route_ref, and Towards tags, and OSM position left intact. All pre-existing
naptan nodes in OSM  without the bus stop tag have had the bus stop tag
added as well. Their position obviously will not have been verified by
survey, but this method offfers completeness

All pre-existing OSM bus stops that have been deleted in naptan have had
the highway=bus_stop tag removed and a note added explaining what's
happened. Feel free to delete any you come across.

All new CUS stops have been imported (approx 230)- mainly because they
don't render. A gradual review will be necessary as I've found in areas
that  I know  well that many of these now have poles and should be MKD in
the naptan data, and I've tagged them as bus stops where I've surveyed them.

I'm gradually working through the approx 300 OSM "orphan bus stops" that
have been surveyed but have no naptan tags. So you'll still see some
duplicates in places. Where this is the case transfer any extra tags like
shelter present and shelter ref no to the adjacent naptan node and delete
the orphan. In most cases where I've done this the OSM position of the
orphan node is better than naptan so move the naptan node to the position
of the orphan

 Some of the OSM pre-exisitng bus stops are nothing to do with naptan (e.g
NEC and Airport car park shuttles) so I'm tagging these with naptan=no.
About 20 of these so far

Any bus stops where I find there is a discrepancy beween naptan and OSM I'm
tagging with naptan_refresh=query (most of  these have been Ring and Ride
stops, or poles flagged physically with NOT IN USE). About 40 of these so
far.

That leaves about 800 new bus stops which are yet to be imported. Some of
these will match "orphan bus-stops". The remainder I'm hesitant to import
as they're either poorly positioned or just don't exist. So it's probably
going to be a long manual comparison slog. Or we live with this level of
questionable data and import them

Around the larger interchanges and bus stations  I've been adding a
stop_area relation and adding the public_transport=platform tags to the bus
stops. NB these are topographical areas and have no relation to naptan stop
areas

The last task remains to import the data on shelters, which I'll be getting
from TfWM towards the end of April

Bus Lanes

TfWM are asking local authorities other than Birmingham (which I've already
added- but we do need the times for adding conditional tags which can only
be done with surveys)) for their bus lane data. So far I have shapefiles
for Wolverhampton. Does anyone fancy adding these?

Regards

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

Re: [OSRM-talk] getting into Oxford Street

[Daniel Patterson]

Hi Alan,

  Hmm, the best way to figure this out is going to be to use the OSRM debug map:

http://map.project-osrm.org/debug/#15.79/51.5140/-0.1515 


  This shows roads that are routable (colored), and roads that are isolated 
from the rest of the network (highlighted in pink).

  I can see that there are some missing roads as well - this means that OSRM 
has removed these from the routing network,
  usually because of access restrictions (i.e. no cars allowed).

  This node:

http://www.openstreetmap.org/node/2198870645 


  indicates that you can't continue straight along Oxford Street there - you're 
only allowed to turn left.  I don't know if this is real or not.
  There are also no turns allowed from Regent St onto Oxford St here - this is 
preventing access to the section of Oxford St just to the
  west here.

  The OSRM demo server updates with new data every couple of days.  If you make 
changes to OSM, you can check:

http://router.project-osrm.org/status 


  to see what data the OSRM demo server is using, and whether any changes 
you've made have taken effect yet.

daniel

> On Mar 16, 2017, at 7:21 AM, Alan Bell  wrote:
> 
> Hi all
> 
> there is a segment of Oxford Street in London from about the Park 
> Street/Portman Street crossing to Regent Street where the turn restrictions 
> prevent you from going straight on into it, or turning left or right from any 
> of the crossing roads.
> 
> http://map.project-osrm.org/?z=15=51.514218%2C-0.130098=51.515313%2C-0.140419=51.514525%2C-0.147876=en=0
> 
> so without any one way street issues, this is an area of perfectly good road 
> from which you can exit but never enter.
> 
> I am not entirely sure what the facts on the ground are (it isn't a very 
> sensible place to be driving) but is there something that can be done in the 
> profile or by editing the map to avoid that bit of road if it has actually 
> been pedestrianised or something?
> 
> Alan.
> 
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk

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

Re: [Talk-cz] kompatibilita ODbL a CC

[Matěj Cepl]

On 2017-03-17, 10:12 GMT, Ladislav Nesnera wrote:
> Re: Matěj C | Neřešíme konkrétní datovou sadu, ale licenci(e), 
> kterou má Brno v rámci zveřejňování informací preferovat a ze 
> které by se "uhýbalo" jen v nezbytných případech.;?

No tak je asi pravda, že ty dvě licence jsou prostě 
nekompatibilní a zároveň je asi pravda, že OpenStreetMap bude 
jedním z největších uživatelů těch dat, takže je třeba najít 
nějaký kompromis.

Buď se nějak překoná ta potřeba šířit ty data pod CC (ono je to 
opravdu pro databázová data nevhodné, je to dělané na literární 
a výtvarná díla) anebo mi dvojí licence připadá jako jediné 
možné řešení. Nešlo by ta pravidla opravit s tím, že pro 
databázová (nebo GIS) data by se upřednostňovala ODbL?

Nějaké jiné varianty, které jsem přehlédl?

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
There are two ways of constructing a software design: One way is
to make it so simple that there are obviously no deficiencies,
and the other way is to make it so complicated that there are no
obvious deficiencies.
  -- C. A. R. Hoare


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

[Talk-it] Fontanili della Lombardia

[Luca Moiana]

Scusandomi per il disguido apro una nuova conversazione (spero), sull'argomento.

Incollo di seguito i contributi precedenti.


DEFINIZIONE

http://www.cartografia.regione.lombardia.it/metadata/fontanili/QdR_n.144_FonTe.pdf


"

Il fontanile è una presa d’acqua nella falda acquifera non affiorante creata 
dall’uomo per far risalire

in superficie, raccogliere, indirizzare e utilizzare a scopo irriguo le acque 
sotterranee. Si tratta quindi

di un’opera dell’uomo che come tale si differenzia dalle naturali risorgive, o 
sorgenti di pianura, anche

se da esse trae origine. In altri termine la risorgiva fa riferimento ad un 
affioramento spontaneo

mentre si parla di fontanile quando l’affioramento è il risultato dell’azione 
antropica.

La sovrapposizione fra i due termini è dovuta al fatto che spesso i fontanili 
sono stati scavati in aree

già interessate dalla presenza di risorgive, fenomeno naturale oggi visibile 
sono in alcune aree nella

zona est della Pianura Padana (Veneto e Friuli)."


DISCUSSIONE:


Il dataset è molto interessante (anche se le rilevazioni più recenti risalgono 
al 2011) e ha dei numeri diciamo importanti per il tipo di elemento considerato.


In totale sono 1193 fontanili di cui:

- 980 marcati come ATTIVO -> da importare sicuramente

- 48 con stato NON ACCESSIBLE -> direi da da importare

- 165 marcati come INATTIVO -> bisognerebbe capire caso per caso come sono 
messi (PCN2012, survey...). Se fossero stati ricoperti il problema non si pone 
e dal mio punto di vista non sarebbero da importare. Se fosse rimasto l'alveo 
della testa non so se avrebbe senso marcarli come historic.


Ci sono alcuni dati utili per i ragionamenti sul tagging:

- il numero di teste (campo N_TESTE) che in 138 casi è di almeno 2 -> relation 
fra nodi natural=spring ? natural=spring applicato ad un'area che comprende 
teste ed aste ? (non consentito dalle regole di tagging attuali, anche se ci 
sono in taginfo un migliaio di casi)

- ELE_PREGIO che in 11 casi è valorizzato con ARCHITETTONICO e STORICO/ARCH-> 
immagino presupponga la presenza di strutture fisiche quindi... o si trova un 
tagging schema che ne tenga conto, oppure si valuta caso per caso


Per il resto, a parte il nome, mi sembrano interessanti i campi

- CONSORZIO->operator

- DATI_IDRO che può essere ALIMENTAZIONE CONTINUA o ASCIUTTE PERIODICHE -> qui 
ci sta secondo me un intermittent=yes/no


spring:type=fontanile proposto da Alessandro non mi dispiace affatto.


Visto l'interesse storico/naturalistico/culturale dei fontanili IMHO

sarebbe interessante evidenziarli. Che ne dite di un spring:type=fontanile

e anche un semplice description=fontanile.


Proprio in questi giorni sono in contatto col POLIMI che sta avviando un

progetto di mappatura cultural heritage, i fontanili rientrerebbero a

pieno in questo campo e sarebbe interessante riuscire a distinguerli.


per me water well evoca un immagine così:

https://thumbs.dreamstime.com/z/antique-water-well-28622284.jpg

(scusate, quello specifico è completamente fassullo, ma l'idea si capisce).



Fontanile invece mi imagino una vasca dove gli animali possono bere?



i tag usati per features simili:

* natural=spring (punto dove acqua esce in superficie, generalmente inizio di 
un waterway)

* man_made=water_well (buco nella terra per prelevare acqua dall'aquifero)  
https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dwater_well, con e senza 
pompa (pump=*)

* amenity=fountain (fontana decorativa) 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

* amenity=drinking_water (qualsiasi punto per trovare acqua potabile, es. 
fontanella)


Wikipedia dice che un fontanile è una Risorgiva. 
https://it.wikipedia.org/wiki/Risorgiva


Tu ci puoi dare una definizione di un fontanile? Da dove viene l'acqua (corso 
d'acqua oppure aquifero) o non importa? E' per fare bere gli animali?


Penso che non abbiamo ancora un bel tag per descrivere questi: 
http://www.naturamediterraneo.com/Public/data7/hyppo/Fontanile-14.jpg_2009425234821_Fontanile-14.jpg

nel caso di acqua che viene in superficie, è un natural=spring ma non descrive 
ancora la struttura intorno (altro tag da aggiungere).


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

Re: [Talk-it] verifiche sui civici di torino

[Andrea Musuruane]

Ciao,

2017-03-18 18:27 GMT+01:00 Cascafico Giovanni :

> I dati dei civici rilasciati dalla regione Friuli Venezia Giulia riportano
> come nome attributo "BARRATO" per cui abbiamo messo la "/"
>
Secondo me l'uso dello slash ha senso solo se l'esponente può essere un
numero. Ad esempio, a Torino può essere un numero e quindi è necessario
qualche tipo di separatore tra il civico e l'esponente.


> Sul maiuscolo o meno non credo nominatim abbia problemi
>
OSM Inspector riporta come "misformatted house number" tutti gli housenumer
con lettere maiuscole. Keypad mapper 3 usa le lettere minuscole nella
raccolta dei dati. Pertanto userei le minuscole per l'esponente.

Ciao,

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

Re: [Talk-it] Creazione di una relazione per un sentiero

[carlo folini]

Ciao,
la pagina wiki delle super relation [9] non mi sembra molto chiara, visto
che, desumendo dalla definizione della super relation Great lakes portata
ad esempio, la creazione consiste solo nel creare una relazione con tag
type=group e specificarne il nome.

La pagina wiki con i tipi di relazione [8] non sembra riportare le super
relations.

Ho quindi creato la super relazione [4] che comprende:

   - relation:route [7] con il sentiero 302 [5]
   - relation:route [7] con il sentiero 402 [6]

JOSM in fase di caricamento si lamentra della relation non conosciuta,
quindi probabilmente ho sbagliato qualcosa.

Chiedo venia se ho messo dei tag name non corretti, ma mi servono per avere
qualche appiglio nel casino che stò cercando di dipanare (al termine li
sistemerò).

Sembra che la struttura, delle due relation:route, sia gradita a waymarked
trail [10], anche se mi sembra che della super relation non ci sia traccia..

Un walkthrough per creare relazioni per i sentieri non dovrebbe essere
messo nel wiki? Magari quello del CAI?

[4] http://www.openstreetmap.org/relation/7083569
[5] http://www.openstreetmap.org/relation/7082063
[6] http://www.openstreetmap.org/relation/7082960
[7] http://wiki.openstreetmap.org/wiki/Relation:route
[8] http://wiki.openstreetmap.org/wiki/Types_of_relation
[9] http://wiki.openstreetmap.org/wiki/Super-Relation
[10]
https://hiking.waymarkedtrails.org/#route?id=7082063=13!46.192!10.052


Il giorno 18 marzo 2017 09:01, Cascafico Giovanni  ha
scritto:

> Puoi fare due relazioni con i due CAI ref diversi e metterle insieme in
> una superrelazione "sentiero del sole" se questi ne fanno parte
> integralmente.
>
> Altrimenti, Puoi suddividere pezzi di way, quando questa è solo una parte
> nella relazione
>
> Nel dubbio guarda come sono stati fatti altri percorsi, tipo i vari Camino
> de Santiago ecc.
>
> Il 17/mar/2017 23:24, "carlo folini"  ha scritto:
>
>> Ciao,
>> stò cercando di creare la mia prima relazione [1] per descrivere il
>> "sentiero del Sole" in Valtellina.
>> Ho letto questo wiki [0].
>> Quando parla di ref dice di indicare il numero del sentiero. Il sentiero
>> in questione è in lombardia in provincia di Sondrio e si estende su due
>> aree (o zone) la 3 e la 4.
>> Da Sondrio a Teglio si chiama quindi 302 e da lì in avanti si chiama 402.
>> La ref deve essere specificata solo a livello di relazione. Come faccio a
>> mettere i due numeri? ref=302|402 oppure ref=302;402 ?
>>
>> Ho inserito il tag symbol [3] , symbol:it e osmc:symbol [2] in cui
>> bisogna specificare il numero del sentiero. Come mi comporto con i due
>> numeri?
>>
>> Il percorso utilizza dei pezzi di strade e sentieri, magari solo per
>> pochi tratti.
>> Come faccio ad aggiungere i pezzi di raccordo alla relazione?
>> Se provo ad aggiungere i singoli nodi (uso JOSM) al momento di caricarli
>> si lamenta in quanto questi non ereditano i tag (ad esempio highway) della
>> strada/sentiero di cui fanno parte. Quindi non avendo alcun tag falliscono
>> la validazione.
>> Devo suddividere la way per il tratto che mi interessa e poi aggiungerlo
>> alla relazione?
>>
>>
>> Grazie
>>
>> [0] http://wiki.openstreetmap.org/wiki/IT:Hiking
>> [1] http://www.openstreetmap.org/relation/7082063#map=13/46.1994/10.0126
>> [2] http://wiki.openstreetmap.org/wiki/IT:Key:osmc:symbol
>> [3] http://wiki.openstreetmap.org/wiki/CAI
>>
>> --
>> Carlo Folini
>> mailto:carlo.fol...@gmail.com
>> blog: http://www.diariocorsa.com
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


-- 
Carlo Folini
mailto:carlo.fol...@gmail.com
blog: http://www.diariocorsa.com
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] verifiche sui civici di torino

[Cascafico Giovanni]

I dati dei civici rilasciati dalla regione Friuli Venezia Giulia riportano
come nome attributo "BARRATO" per cui abbiamo messo la "/"

Sul maiuscolo o meno non credo nominatim abbia problemi

Il 18/mar/2017 17:46, "marco zampiva"  ha scritto:

> Buonasera a tutti,
>
> utilizzo questo thread per chiarirmi una perplessità sul formato dei
> numeri civici (mi scuso in anticipo se sto andando OT).
>
> Nell’import dei civici è stata utilizzata la forma NUMERO/LETTERA
> MAIUSCOLA (10/A), io sto mappando alcuni civici a Mestre e guardando chi lo
> aveva fatto prima di me ho usato la forma NUMEROlettera minuscola (10a),
>  guardando in giro vedo che esistono anche altre combinazioni, con lettere
> maiuscole e con uno spazio tra numero e lettera.
>
> Tra tutte queste esiste una forma consigliata dalla comunità italiana in
> modo da uniformare il più possibile la mappatura dei civici?
>
> Grazie per l’attenzione.
>
>
>
> Marco
>
>
>
> *From:* Martin Koppenhoefer [mailto:dieterdre...@gmail.com]
> *Sent:* Saturday, March 18, 2017 2:44 PM
> *To:* openstreetmap list - italiano
> *Subject:* Re: [Talk-it] verifiche sui civici di torino
>
>
>
>
>
> sent from a phone
>
>
> On 18 Mar 2017, at 09:53, Cascafico Giovanni  wrote:
>
> Tipo
>
> via>Via
>
>
>
>
>
> +1
>
>
>
>
>
> Pio X>Pio Decimo
>
>
>
>
>
> in questo caso metterei entrambe le versioni (alt_name)
>
>
>
>
>
> XXV>Venticinque Aprile
>
>
>
>
>
> dito (forse anche 25 Aprile, per es. nat_name)
>
>
>
>
>
> ciao,
>
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-gb-westmidlands] April Meeting

[Brian Prangle]

Don't forget there will be NO April OSM meeting as too many of us are away
and Easter makes it difficult to re-arrange. May will be our next meeting
- AndyR to arrange a peripatetic venue for early mapping then pub meetup

Regards

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

Re: [Talk-it] ottenere mappa senza esercizi pubblici per motivi didattici

[Francesco Pelullo]

Il 18 mar 2017 18:06, "matteo ruffoni"  ha scritto:

Ciao vorrei poter usare un po' di mappe di ricavate  da OSM nelle quali non
compaiano gli esercizi pubblici ma venga mantenuto il dettaglio della
renderizzazione standard

Ho provato con maposmatic e field papers ma per ora non sono riuscito a
risolvere
qualcuo può darmi un suggerimento



Potresti installare QGIS, gestisce anche i dati di OSM.
Poi filtri per visualizzare solo quello che ti serve, metti in scala e
stampi.

Sicuramente esistono altre soluzioni, più semplici, questa però è veramente
potente.

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

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Sérgio V .]

Ok, pode ser. Ótimo se der pra aproveitar os mesmo nós.

Estou fazendo mais umas coisas:

Colocando as urls dos relatórios de todos os 45.662 (tem descrições que ajudam 
a identificar no terreno, etc, muitos tem fotos). Só que tavam em outra fonte 
do IBGE .

(p. ex. ao invés do  
ftp://geoftp.ibge.gov.br/RBMC/relatorio/Descritivo_MSAQ.pdf ...  , estava no 
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1=99614, sendo  
http://www.bdg.ibge.gov.br/bdg/pdf/relatorio.asp?L1= * , onde * é o código da 
estação - o ref=* )

Assim que terminar a conflação nos DBF dos SHP e converter pra .osm de novo 
envio pra um dropbox.  Dá uns 30MB.

Obrigado


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Nelson A. de Oliveira 
Enviado: sábado, 18 de março de 2017 13:38
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Proposal of import: Brazilian Geodetic Network 
(man_made=survey_points)

Parece bom depois das correções.

O que eu faria (e falaria ao enviar para a lista imports) é
reaproveitar¹ os dados que já foram inseridos anteriormente (e depois
revertidos).
Tomando o cuidado apenas para ajustar o que precisa e não recriar as relações.

Assim se torna desnecessário criar novos objetos no mapa.

Sérgio, só pra ter mais garantia e também fornecer os dados para
análise (acho que vão querer ver na imports), tem como fazer os
ajustes e disponibilizar o arquivo .osm em algum lugar para verificar?

¹ é uma reversão da reversão: reverte, remove as relações, ajusta note
e outras informações, verifica 10 vezes

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

[Talk-it] ottenere mappa senza esercizi pubblici per motivi didattici

[matteo ruffoni]

Ciao vorrei poter usare un po' di mappe di ricavate  da OSM nelle quali non
compaiano gli esercizi pubblici ma venga mantenuto il dettaglio della
renderizzazione standard

Ho provato con maposmatic e field papers ma per ora non sono riuscito a
risolvere
qualcuo può darmi un suggerimento

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

Re: [Talk-it] verifiche sui civici di torino

[marco zampiva]

Buonasera a tutti,

utilizzo questo thread per chiarirmi una perplessità sul formato dei numeri 
civici (mi scuso in anticipo se sto andando OT).

Nell’import dei civici è stata utilizzata la forma NUMERO/LETTERA MAIUSCOLA 
(10/A), io sto mappando alcuni civici a Mestre e guardando chi lo aveva fatto 
prima di me ho usato la forma NUMEROlettera minuscola (10a),  guardando in giro 
vedo che esistono anche altre combinazioni, con lettere maiuscole e con uno 
spazio tra numero e lettera.

Tra tutte queste esiste una forma consigliata dalla comunità italiana in modo 
da uniformare il più possibile la mappatura dei civici?

Grazie per l’attenzione.

 

Marco 

 

From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Sent: Saturday, March 18, 2017 2:44 PM
To: openstreetmap list - italiano
Subject: Re: [Talk-it] verifiche sui civici di torino

 



sent from a phone


On 18 Mar 2017, at 09:53, Cascafico Giovanni  wrote:

Tipo 

via>Via

 

 

+1

 





Pio X>Pio Decimo

 

 

in questo caso metterei entrambe le versioni (alt_name)

 





XXV>Venticinque Aprile

 

 

dito (forse anche 25 Aprile, per es. nat_name)

 

 

ciao,

Martin 

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

Re: [Talk-br] Proposal of import: Brazilian Geodetic Network (man_made=survey_points)

[Nelson A. de Oliveira]

Parece bom depois das correções.

O que eu faria (e falaria ao enviar para a lista imports) é
reaproveitar¹ os dados que já foram inseridos anteriormente (e depois
revertidos).
Tomando o cuidado apenas para ajustar o que precisa e não recriar as relações.

Assim se torna desnecessário criar novos objetos no mapa.

Sérgio, só pra ter mais garantia e também fornecer os dados para
análise (acho que vão querer ver na imports), tem como fazer os
ajustes e disponibilizar o arquivo .osm em algum lugar para verificar?

¹ é uma reversão da reversão: reverte, remove as relações, ajusta note
e outras informações, verifica 10 vezes

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

Re: [OSM-talk-fr] liste technique "BANO" ?

[Frédéric Rodrigo]

Salut,

Pour BANO c'est ici :
https://github.com/osm-fr/bano/issues
Pour la BAN c'est ici :
https://github.com/etalab/ban-data/issues

Je pense que le nouveau format va de pair avec la nouvelle version d'Addok.
https://github.com/addok/addok

Si Addok 0.5 n'est plus capable de manger les nouveaux fichier je vais 
aussi avoir et le même problème à la prochaine mise à jour, et je pense 
que l'on ne va pas être les seuls.


Frédéric.



Le 18/03/2017 à 15:31, Brice MALLET a écrit :

Bonjour, je ne me souviens plus s'il existe une liste technique BANO.

En effet nous (www.entrouvert.com) suivons ce projet à titre 
professionnel et l'un de mes collègues a détecté une modification dans 
l'export json accessible depuis OSM.fr 
(http://bano.openstreetmap.fr/BAN_odbl/).


citycode est désormais une liste :

  {"city": "Paris",
   "citycode": ["75113", 75056],
   "name": "Allée Marc Chagall",
   ...

La question est donc : quelle liste ou autre canal suivre pour être 
informé de ces évolutions ?

Merci.





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

Re: [OSM-talk-fr] liste technique "BANO" ?

[Philippe Verdy]

On voit également des erreurs dans certains CSV, comme code_cadastre.csv
avec cette ligne:
  14,014,VILLIERS-L,SEC (,8B757,VECT
au lieu de
  14,014,VILLIERS-LE-SEC,14???,8B757,VECT
avec un champ (14???) manquant

D'autres champs CSV sont incorrectement interprétés comme des nombres en
format exponentiel (exemple: "4E036" qui devient 4,00E+36 une fois converti)

Là encore les guillemets régleraient ces défauts. Je pense que ces CSV (et
tant qu'à faire les autres fichiers aussi) devraient être tous vérifiés en
tentant de les charger pour trouver ces défauts venant de bogues de l'outil
"maison" d'export utilisé pour les produire.



Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le 18 mars 2017 à 16:44, Philippe Verdy  a écrit :

> Sinon les fichiers CSV de la BANO contiennent des parasites qui
> compliquent leur utilisation. Les champs sont séparés par des virgules ","
> mais on trouve aussi des point-virgules avec des caractères sous forme
> d'entité numériques (comme "" pour les apostrophes ASCII). En format
> CSV ces entités numériques (pour HTML ou XML) n'ont rien à faire là (pas
> plus non plus en format JSON).
>
> Si on charge ces CSV dans Excel (qui par défaut en version française
> recherche les point-virgules, certaines lignes seront découpées sur
> plusieurs cellules, tout le reste restant dans la 1re colonne, et si on
> essaye de convertir les séparateurs en cellules séparées en rpenant la
> virule, Excel signale que cela va écraser des cellules déja remplies
> contenant les morceaux découpés.
>
> Il serait bon que les CSV (comme JSON) utilisent systématiquement des
> "guillemets" pour délimiter tous les champs (s'il y a des guillemets dans
> les chaines, on doit les doubler) et n'utilise sinon aucune entité
> numérique ou nommée pour les caractères. Dès lors plus de problème si les
> séparateurs sont des virgules, des point-virgules ou autre chose (des
> tabulations)... y compris pour les champs contenant des codes comme par
> exemple les numéros de départements dont la plupart seront interprétés
> comme des nombres (avec leur zéro initial tronqué) mais pas tous
> (départements de la Corse), et les numéros de communes à 3 chiffres.
>
>
> Le 18 mars 2017 à 16:30, Philippe Verdy  a écrit :
>
>> Tu veux dire que c'est une erreur ?
>> Que doit signifier ce "citycode": un code INSEE, un code IRIS ? un code
>> postal géographique, un code postal spécial (type CEDEX) ?
>> Dans ce cas comment faire si des zones se superposent ou si la rue
>> signalée est coupée en plusieurs parties avec des codes différents et si la
>> BAN ne sait pas faire la distinction sur une adresse donnée ou si certaines
>> adresses postales dans la rue ont des codes différents ?
>>
>> De plus la page wiki
>>   https://wiki.openstreetmap.org/wiki/WikiProject_France/WikiP
>> roject_Base_Adresses_Nationale_Ouverte_(BANO)
>> mentionne l'URL "http://bano.openstreetmap.fr/data/; pour les données
>> par département (formats .shp.zip et .csv)
>> mais pas l'URL "http://bano.openstreetmap.fr/BAN_odbl/; (formats
>> .json.bz2 et .csv.bz2)
>> Lesquelles sont la BAN et la BANO, ou bien si les deux sont la BANO, y
>> a-t-il une différence hormi le format (je vois les deux dossiers
>> synchronisés à peu près en même temps pour chaque département) ?
>>
>>
>>
>>
>>
>> 
>>  Garanti
>> sans virus. www.avast.com
>> 
>> <#m_-8754549339081679551_m_9114398251918493076_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> Le 18 mars 2017 à 15:31, Brice MALLET  a écrit :
>>
>>> Bonjour, je ne me souviens plus s'il existe une liste technique BANO.
>>>
>>> En effet nous (www.entrouvert.com) suivons ce projet à titre
>>> professionnel et l'un de mes collègues a détecté une modification dans
>>> l'export json accessible depuis OSM.fr (http://bano.openstreetmap.fr/
>>> BAN_odbl/).
>>>
>>> citycode est désormais une liste :
>>>
>>>   {"city": "Paris",
>>>"citycode": ["75113", 75056],
>>>"name": "Allée Marc Chagall",
>>>...
>>>
>>> La question est donc : quelle liste ou autre canal suivre pour être
>>> informé de ces évolutions ?
>>> Merci.
>>>
>>>
>>> --
>>> Cordialement
>>>
>>> Brice Mallet
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] liste technique "BANO" ?

[Philippe Verdy]

Sinon les fichiers CSV de la BANO contiennent des parasites qui compliquent
leur utilisation. Les champs sont séparés par des virgules "," mais on
trouve aussi des point-virgules avec des caractères sous forme d'entité
numériques (comme "" pour les apostrophes ASCII). En format CSV ces
entités numériques (pour HTML ou XML) n'ont rien à faire là (pas plus non
plus en format JSON).

Si on charge ces CSV dans Excel (qui par défaut en version française
recherche les point-virgules, certaines lignes seront découpées sur
plusieurs cellules, tout le reste restant dans la 1re colonne, et si on
essaye de convertir les séparateurs en cellules séparées en rpenant la
virule, Excel signale que cela va écraser des cellules déja remplies
contenant les morceaux découpés.

Il serait bon que les CSV (comme JSON) utilisent systématiquement des
"guillemets" pour délimiter tous les champs (s'il y a des guillemets dans
les chaines, on doit les doubler) et n'utilise sinon aucune entité
numérique ou nommée pour les caractères. Dès lors plus de problème si les
séparateurs sont des virgules, des point-virgules ou autre chose (des
tabulations)... y compris pour les champs contenant des codes comme par
exemple les numéros de départements dont la plupart seront interprétés
comme des nombres (avec leur zéro initial tronqué) mais pas tous
(départements de la Corse), et les numéros de communes à 3 chiffres.


Le 18 mars 2017 à 16:30, Philippe Verdy  a écrit :

> Tu veux dire que c'est une erreur ?
> Que doit signifier ce "citycode": un code INSEE, un code IRIS ? un code
> postal géographique, un code postal spécial (type CEDEX) ?
> Dans ce cas comment faire si des zones se superposent ou si la rue
> signalée est coupée en plusieurs parties avec des codes différents et si la
> BAN ne sait pas faire la distinction sur une adresse donnée ou si certaines
> adresses postales dans la rue ont des codes différents ?
>
> De plus la page wiki
>   https://wiki.openstreetmap.org/wiki/WikiProject_France/
> WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)
> mentionne l'URL "http://bano.openstreetmap.fr/data/; pour les données par
> département (formats .shp.zip et .csv)
> mais pas l'URL "http://bano.openstreetmap.fr/BAN_odbl/; (formats
> .json.bz2 et .csv.bz2)
> Lesquelles sont la BAN et la BANO, ou bien si les deux sont la BANO, y
> a-t-il une différence hormi le format (je vois les deux dossiers
> synchronisés à peu près en même temps pour chaque département) ?
>
>
>
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_9114398251918493076_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Le 18 mars 2017 à 15:31, Brice MALLET  a écrit :
>
>> Bonjour, je ne me souviens plus s'il existe une liste technique BANO.
>>
>> En effet nous (www.entrouvert.com) suivons ce projet à titre
>> professionnel et l'un de mes collègues a détecté une modification dans
>> l'export json accessible depuis OSM.fr (http://bano.openstreetmap.fr/
>> BAN_odbl/).
>>
>> citycode est désormais une liste :
>>
>>   {"city": "Paris",
>>"citycode": ["75113", 75056],
>>"name": "Allée Marc Chagall",
>>...
>>
>> La question est donc : quelle liste ou autre canal suivre pour être
>> informé de ces évolutions ?
>> Merci.
>>
>>
>> --
>> Cordialement
>>
>> Brice Mallet
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] highway con name composto

[Cascafico Giovanni]

Sono sui civici di Torino e trovo spesso queste situazioni:

way:
name=Via Glizio Quinto Attilio Agricola
short_name=Via Attilio Agricola

Il recente import assegna...

civico:
addr:street=Via Attilio Agricola

e quindi OSMinspector segnala errore.

Un paio di indirizzi (di un passato editing) riportano il nome lungo
addr:street=Via Glizio Quinto Attilio Agricola

Mi chiedo se
name=Via Glizio Quinto Attilio Agricola
possa mettere in difficoltà la ricerca Nominatim, e quindi se sia il caso
di adottare la soluzione

way:
name=Via Attilio Agricola
alt_name=Via Glizio Quinto Attilio Agricola

civico:
addr:street=Via Attilio Agricola
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] liste technique "BANO" ?

[Philippe Verdy]

Tu veux dire que c'est une erreur ?
Que doit signifier ce "citycode": un code INSEE, un code IRIS ? un code
postal géographique, un code postal spécial (type CEDEX) ?
Dans ce cas comment faire si des zones se superposent ou si la rue signalée
est coupée en plusieurs parties avec des codes différents et si la BAN ne
sait pas faire la distinction sur une adresse donnée ou si certaines
adresses postales dans la rue ont des codes différents ?

De plus la page wiki

https://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)
mentionne l'URL "http://bano.openstreetmap.fr/data/; pour les données par
département (formats .shp.zip et .csv)
mais pas l'URL "http://bano.openstreetmap.fr/BAN_odbl/; (formats .json.bz2
et .csv.bz2)
Lesquelles sont la BAN et la BANO, ou bien si les deux sont la BANO, y
a-t-il une différence hormi le format (je vois les deux dossiers
synchronisés à peu près en même temps pour chaque département) ?





Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le 18 mars 2017 à 15:31, Brice MALLET  a écrit :

> Bonjour, je ne me souviens plus s'il existe une liste technique BANO.
>
> En effet nous (www.entrouvert.com) suivons ce projet à titre
> professionnel et l'un de mes collègues a détecté une modification dans
> l'export json accessible depuis OSM.fr (http://bano.openstreetmap.fr/
> BAN_odbl/).
>
> citycode est désormais une liste :
>
>   {"city": "Paris",
>"citycode": ["75113", 75056],
>"name": "Allée Marc Chagall",
>...
>
> La question est donc : quelle liste ou autre canal suivre pour être
> informé de ces évolutions ?
> Merci.
>
>
> --
> Cordialement
>
> Brice Mallet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] application web "layers" d'OSM France

[Philippe Verdy]

Cette appli référence encore le fond de carte MapQuest Open qui est
définitivement fermé sans clé d'accès.

Ne peut-on pas le remplacer par le fond de carte cyclable et le fond
transport qui n'y sont pas encore (mais figurent dans les fonds par défaut
de l'appli web OSM.org) ?

Y a-t-il d'autres fonds français qui seraient intéresssants (par exemple
celui de 3liz.com si on a un accord de leur part... histoire de leur faire
de la publicité au lieu encore de promouvoir Mapquest) ?


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] JOSM-Conflation plugin update feedback

[Tyndare]

Hi

I have updated the JOSM-Conflation plugin (v0.5.1) to add new options 
and better suit my needs, but I hope I didn’t break others, so I’m 
looking for feedback from potential users, don’t hesitate to open a 
ticket 
https://josm.openstreetmap.de/newticket?component=Plugin%20conflation=Tyndare


http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation

Cheers,

–
Tyndare

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

[OSM-talk-fr] liste technique "BANO" ?

[Brice MALLET]

Bonjour, je ne me souviens plus s'il existe une liste technique BANO.

En effet nous (www.entrouvert.com) suivons ce projet à titre 
professionnel et l'un de mes collègues a détecté une modification dans 
l'export json accessible depuis OSM.fr 
(http://bano.openstreetmap.fr/BAN_odbl/).


citycode est désormais une liste :

  {"city": "Paris",
   "citycode": ["75113", 75056],
   "name": "Allée Marc Chagall",
   ...

La question est donc : quelle liste ou autre canal suivre pour être 
informé de ces évolutions ?

Merci.


--
Cordialement

Brice Mallet

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

Re: [Talk-cz] kompatibilita ODbL a CC

[Marián Kyral]

Něco k tématu: https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

Marián

17. března 2017 11:12:29 SEČ, Ladislav Nesnera  napsal:
>Díky všem za informace.
>
>Re: Matěj C | Neřešíme konkrétní datovou sadu, ale licenci(e), kterou
>má
>Brno v rámci zveřejňování informací preferovat a ze které by se
>"uhýbalo" jen v nezbytných případech.;?
>
>
>On 16.3.2017 10:59, Tom Ka wrote:
>> Jen pro ostatni - hlavni problem nekompatibility licenci ODbL a
>CC-xxx
>> je jak zmineno
>>
>> https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>>
>> To, ze u CC (pokud neni osetreno jinak) je potreba pro kazdy
>> jednotlivy kus dat uvadet zdroj (credit) coz by pak v jedne DB ktera
>> to bere z X zdroju (resp. X autoru) bylo neresiltelne. Jde udelat
>> explicitni souhlas s tim, ze na wiki OSM je zmineno ze zdroj X
>poskytl
>> sva data pro OSM ale vsude jinde je pak jen obecne OSM prispevatele.
>>
>> Bye
>>
>>
>> Dne 15. března 2017 23:03 Matěj Cepl  napsal(a):
>>> On 2017-03-15, 16:45 GMT, Ladislav Nesnera wrote:
 a volně naváži na OpenAlt, kde v "piklírně" měl být zmíněn
 problém > (ne)kompatibility licencí ODbL
  a CC
  (viz. níže). Je tu
 někdo, kdo by věděl či alespoň tušil kde to drhne? (Nejde o
>akademickou
 debatu - hledáme v Brně co nejsrozumitelnější a zároveň nejširší
>model
 uvolňování otevřených dat, potažmo dalších zdrojů).
>>> Bylo by možné pořádně vysvětlit jaký konkrétní problém řešíte?
>>> Pod jakou licencí má Brno uvolnit data? Pokud tam musí být CC,
>>> nešla by dual-license? CC-něco/ODbL? Skutečně používání CC
>>> licencí na data je dost podezřelá záležitost, podle mého.
>>>
>>> Matěj
>>>
>>> --
>>> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
>>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>>
>>> We are told that [St. Anthony] once fell into dejection, finding
>>> uninterrupted contemplation above his strength; but was taught to
>>> apply himself at intervals to manual labour by a vision of an
>>> angel who appeared platting mats of palm-tree leaves, then rising
>>> to pray, and after some time sitting down again to work; and who
>>> at length said to him, "Do thus, and thou shalt be saved."
>>> -- Life of St. Anthony
>>>
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] verifiche sui civici di torino

[Martin Koppenhoefer]

sent from a phone

> On 18 Mar 2017, at 09:53, Cascafico Giovanni  wrote:
> 
> Tipo
> 
> via>Via
> 


+1


> Pio X>Pio Decimo
> 


in questo caso metterei entrambe le versioni (alt_name)


> XXV>Venticinque Aprile
> 


dito (forse anche 25 Aprile, per es. nat_name)


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

Re: [Talk-es] Compatibilidad entre CC-BY 4.0 y ODbL

[Santiago Crespo]

Hola,

Añadir que también han creado otra plantilla de email y carta de
autorización para las CC BY 2.0 y 3.0:

https://drive.google.com/file/d/0B3PN5zfbzThqX0NNdFBDejE2RFE/view

Saludos,
Santiago Crespo

On 03/17/2017 06:27 PM, Alejandro S. wrote:
> Buenas,
> 
> La OSMF a terminado el análisis de compatibilidad entre la licencia de
> OSM, la ODbL y la licencia Cretive Commons - Atribución 4.0 (CC-BY 4.0) [0]
> 
> Toca seguir pidiendo permiso explícito, y ahora para más cosas. Han
> preparado una carta para pedir el permiso [1], habrá que traducirla.
> 
> 
> [0]: https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
> [1]: https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view
> 
> Atentamente,
>   Alejandro Suárez
> 
> 
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
> 

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

Re: [talk-au] CAPAD 2016 Import -- Sample files.

[Andrew Harvey]

What's your plan where the protected area already exists in OSM? Do
you plan on manually comparing tags and geometry and manually merging?
Which will prevail in a conflict?

> * The nodes with a note tag have been added as JOSM complains if a
segment is longer than 15km (also the note needs to be worded better).

Can you just split the way instead of adding all these nodes.

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

Re: [Talk-it] verifiche sui civici di torino

[girarsi_liste]

Il 18/03/2017 11:53, Cascafico Giovanni ha scritto:
>> Consiglio l'attività a tutti, quando piove o con qualche linea di febbre
> che ci si può amazzare Torino in un paio di settimane  ;-)
> 
> Smazzare Torino [maledetto correttore, scusate]
> 

Ma il cimitero ha abbastanza spazio per tutti ?  :):):):)




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



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

Re: [Talk-it] verifiche sui civici di torino

[Cascafico Giovanni]

> Consiglio l'attività a tutti, quando piove o con qualche linea di febbre
che ci si può amazzare Torino in un paio di settimane  ;-)

Smazzare Torino [maledetto correttore, scusate]
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] verifiche sui civici di torino

[Cascafico Giovanni]

Che ne dite si fare prime le modifiche globali?
Tipo

via>Via
Pio X>Pio Decimo
XXV>Venticinque Aprile

Ho finalmente preso confidenza con lo stile JOSM strade colorate,
facilissimo! Consiglio l'attività a tutti, quando piove o con qualche linea
di febbre che ci si può amazzare Torino in un paio di settimane  ;-)

Il 17/mar/2017 10:02, "Alessandro Palmas" 
ha scritto:

> Buongiorno lista,
> Sbiribizio ha appena messo su un Tasking Manager (1) per permettere una
> verifica partecipata su civici e nomi vie a Torino.
> Un primo controllo è stato fatto, ma se qualcuno in questo momento stesse
> giocando con la lanugine nell'ombelico in attesa di task ... eccolo qui :-)
>
> Si tratterebbe di: conciliare i nomi delle vie con quelli dei civici,
> nominare le poche vie senza nome in base a quelle dei civici, cercare
> eventuali rari doppioni nei civici sfuggiti al controllo durante il
> conflate.
>
> Per vedere subito se c'è discrepanza tra il nome della via e dei civici
> che vi cadono intorno consiglio di utilizzare josm con lo lo stile di
> visualizzazione "Coloured Streets"
> Modifica -> Preferenze -> Impostazioni per la proiezione ... -> Stili di
> disegno della mappa -> inserire negli stili attivi "Coloured Streets"
> dopodichè lasciarlo come unico stile attivo.
>
> Alessandro Ale_Zena_IT
>
>
> 1) http://osmit-tm.wmflabs.org/project/24
>
> --
> Alessandro Palmas
> Project Manager OpenStreetMap per Wikimedia Italia
> Mobile 3289671753 - 3938251416
>
> Wikimedia Italia, Via Bergognone 34 - 20144 Milano
> è la corrispondente italiana ufficiale di Wikimedia Foundation Inc
>
>
> ___
> 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] verifiche sui civici di torino

[Cascafico Giovanni]

Lo abbiamo usato parecchio per le inevitabili correzioni di civici Friuli
Venezia Giulia. Ieri per il task Torino era piuttosto lento nel refresh
(con il solo layer delle Street mancanti), oltreché non era attivo il tasto
"apri in JOSM".

Ricordo che c'erano diverse ore di lag nell'aggiornamento delle correzioni.

Il 17/mar/2017 10:18, "Martin Koppenhoefer"  ha
scritto:

>
> 2017-03-17 10:01 GMT+01:00 Alessandro Palmas  it>:
>
>> Si tratterebbe di: conciliare i nomi delle vie con quelli dei civici,
>> nominare le poche vie senza nome in base a quelle dei civici, cercare
>> eventuali rari doppioni nei civici sfuggiti al controllo durante il
>> conflate.
>
>
>
> probabilmente conoscete tutti questo tool, ma per comodità riposto il
> link: http://tools.geofabrik.de/osmi/?view=addresses=7.
> 67502=45.06475=12=buildings,buildings_
> with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,
> street_not_found,place_not_found,misformatted_housenumber,nodes_with_
> addresses_defined,nodes_with_addresses_interpolated,
> interpolation,interpolation_errors,connection_lines,
> nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Creazione di una relazione per un sentiero

[Andrea Musuruane]

Ciao,

2017-03-17 23:22 GMT+01:00 carlo folini :

> Ciao,
> stò cercando di creare la mia prima relazione [1] per descrivere il
> "sentiero del Sole" in Valtellina.
> Ho letto questo wiki [0].
> Quando parla di ref dice di indicare il numero del sentiero. Il sentiero
> in questione è in lombardia in provincia di Sondrio e si estende su due
> aree (o zone) la 3 e la 4.
> Da Sondrio a Teglio si chiama quindi 302 e da lì in avanti si chiama 402.
> La ref deve essere specificata solo a livello di relazione. Come faccio a
> mettere i due numeri? ref=302|402 oppure ref=302;402 ?
>

Devi fare due relazioni, una per ogni ref.


> Ho inserito il tag symbol [3] , symbol:it e osmc:symbol [2] in cui
> bisogna specificare il numero del sentiero. Come mi comporto con i due
> numeri?
>

Devi fare due relazioni.


> Il percorso utilizza dei pezzi di strade e sentieri, magari solo per pochi
> tratti.
> Come faccio ad aggiungere i pezzi di raccordo alla relazione?
> Se provo ad aggiungere i singoli nodi (uso JOSM) al momento di caricarli
> si lamenta in quanto questi non ereditano i tag (ad esempio highway) della
> strada/sentiero di cui fanno parte. Quindi non avendo alcun tag falliscono
> la validazione.
> Devo suddividere la way per il tratto che mi interessa e poi aggiungerlo
> alla relazione?
>

Non devi aggiungere i nodi. Devi aggiungere le way che ti interessando. Se
il sentiero usa solo una parte della way, devi suddividerla ulteriormente e
inserire nella relazione solo il tratto interessato.

Ciao,

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

Re: [Talk-it] Creazione di una relazione per un sentiero

[Cascafico Giovanni]

Puoi fare due relazioni con i due CAI ref diversi e metterle insieme in una
superrelazione "sentiero del sole" se questi ne fanno parte integralmente.

Altrimenti, Puoi suddividere pezzi di way, quando questa è solo una parte
nella relazione

Nel dubbio guarda come sono stati fatti altri percorsi, tipo i vari Camino
de Santiago ecc.

Il 17/mar/2017 23:24, "carlo folini"  ha scritto:

> Ciao,
> stò cercando di creare la mia prima relazione [1] per descrivere il
> "sentiero del Sole" in Valtellina.
> Ho letto questo wiki [0].
> Quando parla di ref dice di indicare il numero del sentiero. Il sentiero
> in questione è in lombardia in provincia di Sondrio e si estende su due
> aree (o zone) la 3 e la 4.
> Da Sondrio a Teglio si chiama quindi 302 e da lì in avanti si chiama 402.
> La ref deve essere specificata solo a livello di relazione. Come faccio a
> mettere i due numeri? ref=302|402 oppure ref=302;402 ?
>
> Ho inserito il tag symbol [3] , symbol:it e osmc:symbol [2] in cui
> bisogna specificare il numero del sentiero. Come mi comporto con i due
> numeri?
>
> Il percorso utilizza dei pezzi di strade e sentieri, magari solo per pochi
> tratti.
> Come faccio ad aggiungere i pezzi di raccordo alla relazione?
> Se provo ad aggiungere i singoli nodi (uso JOSM) al momento di caricarli
> si lamenta in quanto questi non ereditano i tag (ad esempio highway) della
> strada/sentiero di cui fanno parte. Quindi non avendo alcun tag falliscono
> la validazione.
> Devo suddividere la way per il tratto che mi interessa e poi aggiungerlo
> alla relazione?
>
>
> Grazie
>
> [0] http://wiki.openstreetmap.org/wiki/IT:Hiking
> [1] http://www.openstreetmap.org/relation/7082063#map=13/46.1994/10.0126
> [2] http://wiki.openstreetmap.org/wiki/IT:Key:osmc:symbol
> [3] http://wiki.openstreetmap.org/wiki/CAI
>
> --
> Carlo Folini
> mailto:carlo.fol...@gmail.com
> blog: http://www.diariocorsa.com
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Creazione di una relazione per un sentiero

[carlo folini]

Ciao,
Al 99% è del CAI.
Qui [4] ne parlano dicendo che è stato creato su iniziativa del CAI Sondrio
e Tirano nel 2002 e qui [5] trovi un cartello.

Il numero direi quindi che é sicuro, anzi... I numeri

Ciao Carlo
[4]http://www.paesidivaltellina.it/sentierodelsole/index.htm
[5]
https://commons.m.wikimedia.org/wiki/File:Dalico_Cartello_
CAI_Sentiero_Del_Sole.jpg


Il 17 mar 2017 11:44 PM, "Simone"  ha scritto:

Il 17 marzo 2017 23:22:37 CET, carlo folini  ha
scritto:
>Ciao,
>stò cercando di creare la mia prima relazione [1] per descrivere il
>"sentiero del Sole" in Valtellina.
>Ho letto questo wiki [0].
>Quando parla di ref dice di indicare il numero del sentiero. Il
>sentiero in
>questione è in lombardia in provincia di Sondrio e si estende su due
>aree
>(o zone) la 3 e la 4.
>Da Sondrio a Teglio si chiama quindi 302 e da lì in avanti si chiama
>402.
>La ref deve essere specificata solo a livello di relazione. Come faccio
>a
>mettere i due numeri? ref=302|402 oppure ref=302;402 ?
>
>Ho inserito il tag symbol [3] , symbol:it e osmc:symbol [2] in cui
>bisogna
>specificare il numero del sentiero. Come mi comporto con i due numeri?
>
>Il percorso utilizza dei pezzi di strade e sentieri, magari solo per
>pochi
>tratti.
>Come faccio ad aggiungere i pezzi di raccordo alla relazione?
>Se provo ad aggiungere i singoli nodi (uso JOSM) al momento di
>caricarli si
>lamenta in quanto questi non ereditano i tag (ad esempio highway) della
>strada/sentiero di cui fanno parte. Quindi non avendo alcun tag
>falliscono
>la validazione.
>Devo suddividere la way per il tratto che mi interessa e poi
>aggiungerlo
>alla relazione?
>
>
>Grazie
>
>[0] http://wiki.openstreetmap.org/wiki/IT:Hiking
>[1]
>http://www.openstreetmap.org/relation/7082063#map=13/46.1994/10.0126
>[2] http://wiki.openstreetmap.org/wiki/IT:Key:osmc:symbol
>[3] http://wiki.openstreetmap.org/wiki/CAI

Ma questo sentiero è del CAI oppure si trarrà di una proposta turistica?

Perche il ref nel secondo caso non è collegato al CAI.


-- Simone Girardelli--

Inviato con K-9 Mail
Scusate la brevità dello scritto.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] openstreetmap.cz v0.16

[Marián Kyral]

Dne 17.3.2017 v 23:24 Mikoláš Štrajt napsal(a):

Dobrá práce.

Mimochodem - kdo generuje RUIAN parcely? Poloha.net?

Mám tu jednu chybku - zdá se, že se hranice parcel vykreslují přes 
jejich popisky - viz např http://imgur.com/a/dW2qV, kde je to po 
přiblížení vidět u parcely 3008.




Taky Petr Vejsada. Viz: https://github.com/osmcz/poloha.net_mapnik
Konkrétně tady: 
https://github.com/osmcz/poloha.net_mapnik/blob/master/parcely/inc/layer-buildings.xml.inc


(jo, jo, nějak se tam mísí parcely s budovami. Asi to má důvod ;-) )

Marián


--
Severák

-- Původní e-mail --
Od: Marián Kyral 
Komu: talk-cz@openstreetmap.org
Datum: 17. 3. 2017 11:04:54
Předmět: [Talk-cz] openstreetmap.cz v0.16


Ahoj,
na openstreetmap.cz byla nasazena nová verze.

Hlavní změny:
* Nový přepínač vrstev
* Nové vrstvy (ruain, lpis, wikimedia…)
* Vrstva rozcestníků - nové ikony pro mapu a cyklo rozcestník
* Přidány náhledy rozcestníků - rychlejší načítání a menší potřeba dat

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



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


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