Re: [talk-au] Checking on bug-fixes before committing changes.

[Andrew Harvey]

On 9 July 2016 at 12:55, Simon Slater  wrote:
>> > 3/   A couple of these too, 'Approximate highway primary discart from
>> > 35.5339969622m ' I have a GPS track for at least 1 of these at the moment.
>>
>> Can you point to where this is?
>
> http://osmose.openstreetmap.fr/en/error/7056550205  , eastern end of
> http://www.openstreetmap.org/way/178369304 and Yanga Way.  Our GPS has it out
> by 5m not 35m.  There is a kink in the road there.

If you click through on the ? for that issue in osmose it provides a
much better explanation of why it's reporting this. It's saying the
way might need more detail.

Comparing with both the LPI Imagery and Mapbox Satellite background
imagery it looks pretty good.

>>
>>
>> > 6/  What does this bug mean: 'Bad topology way level 2'?
>>
>> Can you point to where you see it?
>
> http://osmose.openstreetmap.fr/en/error/7056543335 , where
> http://www.openstreetmap.org/way/173383040 crosses Cadell St.

Again, click the ? and see
http://wiki.openstreetmap.org/wiki/Osmose/issues#1090 It's saying that
at that point the road jumps from highway=secondary to
highway=residential.

Keep in mind that osmose is just reporting possible errors, not
necessarily that what's mapped is wrong.

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

Re: [talk-au] Checking on bug-fixes before committing changes.

[Simon Slater]

On Sat, 9 Jul 2016 12:06:40 PM Andrew Harvey wrote:
> > 2/  Also a couple of 'Intersection of unrelated highway and waterway
> > objects'.  How to correct these?
> 
> What editor are you using?

JOSM
> Can you point to where this is?
Lost it - I'll find it later.
> If a waterway and highway intersect it's good to specify what's exactly
> happening, is the highway a bridge over the waterway, is the waterway
> a culvert under the highway, is it a ford?
> 
> > 3/   A couple of these too, 'Approximate highway primary discart from
> > 35.5339969622m ' I have a GPS track for at least 1 of these at the moment.
> 
> Can you point to where this is?

http://osmose.openstreetmap.fr/en/error/7056550205  , eastern end of 
http://www.openstreetmap.org/way/178369304 and Yanga Way.  Our GPS has it out 
by 5m not 35m.  There is a kink in the road there.
> 
> 
> > 6/  What does this bug mean: 'Bad topology way level 2'?
> 
> Can you point to where you see it?

http://osmose.openstreetmap.fr/en/error/7056543335 , where 
http://www.openstreetmap.org/way/173383040 crosses Cadell St.

-- 
Regards
Simon Slater

Registered Linux User #463789
http://linuxcounter.net 


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

Re: [talk-au] Checking on bug-fixes before committing changes.

[Andrew Harvey]

On 9 July 2016 at 11:20, Simon Slater  wrote:
> 1/  There are a few 'Bad value for sport=cricket,_australian_football' in 
> the
> area.  The use of the pitch is correct, is the syntax of the tag value wrong?

the convention is to use ; to separate multiple tag values. See the
examples at http://wiki.openstreetmap.org/wiki/Key:sport so it should
probably be "sport=cricket;australian_football", no leading _ and
replace the comma with a semicolon.

> 2/  Also a couple of 'Intersection of unrelated highway and waterway
> objects'.  How to correct these?

What editor are you using? Can you point to where this is? If a
waterway and highway intersect it's good to specify what's exactly
happening, is the highway a bridge over the waterway, is the waterway
a culvert under the highway, is it a ford?

> 3/   A couple of these too, 'Approximate highway primary discart from
> 35.5339969622m ' I have a GPS track for at least 1 of these at the moment.

Can you point to where this is?

> 4/  'Unconnected waterway or wrong way flow'.  Does flow follow the 
> direction a
> way is created?  This one looks like it is connected downstream
> http://www.openstreetmap.org/way/385773228

It is connected to the downstream but this way is pointing in the
opposite direction to the way connected to the west end.

You're correct that flow follows the direction of the way. see
http://wiki.openstreetmap.org/wiki/Key:waterway#Usage

You can just reverse the direction of the way without recreating it,
which is the fix here so that it's pointing in the downstream
direction.

> 5/  This one, http://www.openstreetmap.org/way/173375239 is a lead-up to 
> an
> old historic lift bridge and is flagged 'Highway above ground and no bridge'.
> What tag is needed for this?  Or should the bridge part be extended?  There
> are a series of these old bridges in this area, so I'll check the others too.
> What tags for historic bridges?

Correct this way is the leadup to the bridge, so correctly doesn't
have the bridge=yes tag. This warning message is because there is
layer=1. The layer tag http://wiki.openstreetmap.org/wiki/Key:layer is
used if you have a few bridges on top of each other to indicate the
order, in this case this section of the way doesn't intersect anything
so you can just remove the layer tag.

> 6/  What does this bug mean: 'Bad topology way level 2'?

Can you point to where you see it?

> 7/  Last one: http://www.openstreetmap.org/note/262225 is in the right 
> spot
> for the 90 to 100 kph change, but it is in the middle of the way.  No doubt
> there are more like this in the area.  Do I split the way at this point and
> tag each section with the different speeds?  If so, what about each time the
> councils move the signs into different spots?  Then when fixed, any comment in
> the note, or just 'Resolve'?

If the speed limit changes from one speed limit to another, correct
you need to split the way at that point and tag each section with the
different speeds. If council moves the signs then you have to move
this or resplit / rejoin sections.

You can add a comment if you like with the changeset where you fixed
it, but it's not mandatory. Then just resolve.

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

Re: [Talk-us] Common names of highways do not match road signs.

[OSM Volunteer stevea]

There are many parts here:  road signs in the real world, names which might not 
match those, data in OSM, and presentation by "stacks" 
(hardware/software/network) of those data.  The first two can be captured with 
proper tagging in the third.  If the fourth does not meet your needs, it MAY be 
that the underlying data are wrong, or need improvement.  However, it may also 
be that you need to reconfigure your viewing method/tool, or use another one 
altogether which more properly presents you with the data as you wish to see 
them.  Yes, it is important to you that you see the data you wish to see.  MORE 
important is that the data are "there" as they should be.  Let's capture what 
is important with good tagging.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-au] Checking on bug-fixes before committing changes.

[Simon Slater]

On Sat, 9 Jul 2016 09:52:26 AM Simon Slater wrote:
> On Thu, 7 Jul 2016 07:37:53 PM Andrew Harvey wrote:
> > On 7 Jul 2016 7:21 PM, "Simon Slater"  wrote:
> > > G'day all,

> >  Since this is the first time I've done this, I've a couple of questions.

A couple more things I'd like to check the most appropriate way to proceed 
before I make any changes:
1/  There are a few 'Bad value for sport=cricket,_australian_football' in 
the 
area.  The use of the pitch is correct, is the syntax of the tag value wrong?

2/  Also a couple of 'Intersection of unrelated highway and waterway 
objects'.  How to correct these?

3/   A couple of these too, 'Approximate highway primary discart from 
35.5339969622m ' I have a GPS track for at least 1 of these at the moment.

4/  'Unconnected waterway or wrong way flow'.  Does flow follow the 
direction a 
way is created?  This one looks like it is connected downstream 
http://www.openstreetmap.org/way/385773228

5/  This one, http://www.openstreetmap.org/way/173375239 is a lead-up to an 
old historic lift bridge and is flagged 'Highway above ground and no bridge'.  
What tag is needed for this?  Or should the bridge part be extended?  There 
are a series of these old bridges in this area, so I'll check the others too.  
What tags for historic bridges?

6/  What does this bug mean: 'Bad topology way level 2'?

7/  Last one: http://www.openstreetmap.org/note/262225 is in the right spot 
for the 90 to 100 kph change, but it is in the middle of the way.  No doubt 
there are more like this in the area.  Do I split the way at this point and 
tag each section with the different speeds?  If so, what about each time the 
councils move the signs into different spots?  Then when fixed, any comment in 
the note, or just 'Resolve'?

Any particular Wiki pages useful for these?
-- 
Regards
Simon Slater

Registered Linux User #463789
http://linuxcounter.net 


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

Re: [Talk-us] Common names of highways do not match road signs.

[Minh Nguyen]

Paul Johnson  writes:

> 
> On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan
 wrote:It is confusing
to use open street maps in my area(Central Ohio) for
> driving directions since the "common names" of high ways do not match
> road signs. The common names are used by open map chest for road names.
> For example when turning on to State Route 315 with OpenMapChest loaded
> on my GPS I am directed to turn on to Olentangy Freeway. However the
> tiger name on open street maps is State route 315. Would it make more
> sense to configure driving maps to use tiger names for driving
> directions,  change commons names to include the state route number or
> interstate number, or add state route number/ interstate number as a
> different tag?
> 
> 
> ref=* isn't name=*, don't tag for the renderer.  I'd go with the official
name for name=*.  If you're inclined to do something like, name=State Route
315, you really want ref=OH 315.

You mean `ref=SR 315` and "don't tag for the router". ;-)

The established tagging conventions are designed so that any software that
needs to say something more sophisticated based on the route designation
would parse `network=US:OH` and `ref=315` from the associated route relation
and expand it into "State Route 315". You can find out more about tagging
Ohio route relations on the wiki. [1] The TIGER name Kevin refers to is a
vestige of an import; it isn't customary to tag this way when mapping by hand.

Ohio's DOT makes a point of avoiding names for any Interstate or state route
on signage, in favor of listing control cities. This is different than, say,
Kentucky, which tends to place the highway name next to the route marker on
overhead guide signage.

But Ohio highways still often have official names which are still known
locally, even if they aren't signposted. One example in the Cincinnati area
is the freeway portion of SR 562. The official name is "Norwood Lateral
Expressway", and Cincinnatians universally refer to it as the "Norwood
Lateral", to the point that pretty much no one knows what "SR 562" refers
to. It's clear that `official_name=Norwood Lateral Expressway` and
`loc_name=Norwood Lateral` would be appropriate. `unsigned_name=Norwood
Lateral` is another option.

(Incidentally, a nearby highway was exempted from ODOT's policy after being
renamed for Ronald Reagan. So the signs do include the road name. [2])

If you take the position that `name` should reflect signage, perhaps because
finding signage is more verifiable than asking someone at the nearby gas
station, then `name=Norwood Lateral` would clearly be inappropriate. (A part
of the world that doesn't signpost this way must look rather bare on the
map.) On the other hand, if your reasoning is that `name` should be whatever
name is most useful to someone attempting to use OSM for navigation, then
"Norwood Lateral" isn't entirely useless for that purpose. (You'll never
hear "562" on the traffic report.)

[1] http://wiki.openstreetmap.org/wiki/Ohio/Route_relations
[2] https://en.wikipedia.org/wiki/Ronald_Reagan_Cross_County_Highway

-- 
m...@nguyen.cincinnati.oh.us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-ja] 京都国宝・浪漫マッピングパーティ 第１回 7/16（土）北野天満宮

[yasunari]

京都の山下です。
みなさんこんにちわ。

京都世界遺産マッピングパーティから看板だけすげかえて（笑
新シリーズ京都国宝・浪漫マッピングパーティ！
第1回は、7/16（土）に全国天満宮の総本宮である北野天満宮。
https://openstreetmap.doorkeeper.jp/events/45753

皆様の参加をお待ちしています！！
--
山下康成＠京都府向日市

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

Re: [talk-au] Checking on bug-fixes before committing changes.

[Simon Slater]

On Thu, 7 Jul 2016 07:37:53 PM Andrew Harvey wrote:
> On 7 Jul 2016 7:21 PM, "Simon Slater"  wrote:
> > G'day all,
> > 
> > While waiting in the Balranald Bakery yesterday I thought I'd
> 
> install
> 
> > OSMBugs and OSMTracker and see what needed doing in the area.  Since this
> 
> is
> 
> > the first time I've done this, I've a couple of questions.
> > 
> > 1/  POI without name: https://www.openstreetmap.org/node/1950504127
> 
> has a
> 
> > brand=Caltex tag.  To fix this one, which is better: change brand of
> 
> Caltex to
> 
> > operator or add operator=Caltex, leaving the brand tag?  Or is the
> 
> operator
> 
> > the proprietor and use the tag name= instead?  Locals just call it 'the
> > servo'.  The other Caltex is 'the roadhouse'
> > https://www.openstreetmap.org/node/206203789
> 
> I wouldn't remove the brand=Caltex because that is the branding of the
> service station right? If it's operated by Caltex you can add that tag too.
> It's common to see three tags brand, operator, and name all equal to Caltex.
> 
> Though for name you might also see things like "Caltex [Suburb]"
> 
> > 2/  Fixme tagged item https://www.openstreetmap.org/way/118043858 is
> 
> in the
> 
> > right place by GPS and the other tags are correct.  Do I just delete the
> 
> fixme
> 
> > tag?  This would also apply for a couple of others.
> 
> Yes,if you've validated the thing the fixme tag was added for you can just
> delete the tag.
> 
> > 3/  With the correction needed for:
> > https://www.openstreetmap.org/way/118043885 to extend the divided road,
> 
> is it
> 
> > better to delete the single section, then add the divided section as 2
> 
> ways
> 
> > down to Bank St, or move the single section to one side and add a parallel
> > way?
> 
> I prefer to move the single section and add another way parallel, because
> it retains the history of the way, but both approaches are valid.

Thanks Andrew, I'll get onto that today.
-- 
Regards
Simon Slater

Registered Linux User #463789
http://linuxcounter.net 


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

Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Andrew Harvey]

On 8 July 2016 at 23:47, Simon Poole  wrote:
> Both the Horizontal Layer and the Collective Database guidelines address
> a specific de-duplication issue (in respect to the above use case): if
> you take your proprietary dataset and  remove all POIs from the OSM
> dataset that exist in your data, the OSM dataset remains, naturally,
> ODbL licensed and your proprietary dataset remains proprietary (with
> some information leak via the OSM data). If you do the de-duplication
> the other way around you would be potentially be damaging the
> proprietary status of your data so you wouldn't try that to start with.
>
> You could now distribute the two datasets in a combined fashion and
> argue that each of them is an individual database and as a result the
> combined dataset is a Collective Database, both guidelines rule that out
> (again that does not imply that a judge applying the ODbL to such a case
> would come to the same conclusion).
>
> In summary both guidelines in this use scenario boil down to prohibiting
> de-duplication (of any kind).

On 9 July 2016 at 00:10, Ilya Zverev  wrote:
> Thanks for raising the issue. We at maps.me tried to follow the license: 
> basically we are combining the OSM data without certain nodes (see the list 
> of ids at http://direct.mapswithme.com/direct/latest/skipped_nodes.lst ) and 
> a proprietary data set for hotels. Since we do not use any OSM information, 
> like names or coordinates, for these hotels, I assumed the result could be 
> considered a collective database.
>
> Now, the matching process does indeed compare coordinates of hotels in both 
> datasets, and filters out nodes in the OSM data. The list of nodes is 
> published, so anyone can reproduce the open part of the data from a planet 
> dump. Again, the proprietary data is in no way affected by the OSM data (it 
> is added in its entirety, not a single object is omitted or altered using OSM 
> data). So the last item in the guidelines ("all hotels not found in the 
> OpenStreetMap data layers") does not apply.
>
> If the LWG decides we are violating the license (and explains how, maybe 
> producing another guidelines), we will remove all OSM hotels from our data. 
> But for now I don't see how it's different from removing just some of the 
> hotels.

Thanks for the explanation from both of you, so in this specific case
it appears from what you've both said is that maps.me has taken a
"proprietary dataset and removed all POIs from the OSM dataset that
exist in your data, the OSM dataset remains, naturally, ODbL licensed
and your proprietary dataset remains proprietary (with some
information leak via the OSM data)."

I don't follow if this is permitted or not, either it is because "each
of them is an individual database and as a result the combined dataset
is a Collective Database" but then you say " both guidelines in this
use scenario boil down to prohibiting de-duplication (of any kind)."
Sorry I don't follow which one it is, that the de-duplication that
maps.me is doing is permitted under the license or isn't.

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

[Talk-es] Tagear correctamente un paso de cebra

[A A]

Hablando en un foro sobre una de las app que existen de Navegacion GPS uno de 
los usuarios ha comentado que un paso de cebra debe tagearse 
así:highway=crossing + crossing=uncontrolled + crossing_ref=zebra

En OSM hay un tag predefinido llamado "paso de cebra" con los siguientes 
tags:highway: crossing crossing: zebray otro tag predefinido llamado "paso de 
peatones" que tiene unicamente el tag:  highway: crossing

¿Como deben tagearse los pasos de cebra? ¿Hay alguna manera incorrecta o 
correcta?


 

  
Libre de virus. www.avast.com   


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

Re: [Talk-dk] Jægersgårdgade i Århus

[Niels Elgaard Larsen]

Michael Andersen:
> Fredag den 8. juli 2016 21:08:28 skrev Niels Elgaard Larsen:
>> Asger Frank:
>>> Apropos:
>>>
>>> Hvis der ikke allerede underforstået er sådan en gentleman-m/k-aftale,
>>> kunne man sige, at den der sætter en midlertidig spærring/ændring op
>>> også forsøger holde øje med, om den er bliver fjernet igen.
>>
>> Man kan også sætte en opening_date på vejarbejder. Så kan det fanges af
>> flere værktøjer der holder øje med overskredne opening_data .
> 
> Hvilke værktøjer gør dette?


Osmose:

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

construction

The tag building is perhaps more necessary. The tag opening_date=*,
check_date=*, open_date=*, construction:date=*, temporary:date_on=*,
date_on=* are not present and the object is in construction for more
than two years or dates is exceeded.


Jeg checkede lige og den fandt fx Panuminstituttet:

way 301747863 rawedit josm edit
landuse = construction
opening_date = 2015


og

way 34574 rawedit josm edit
check_date = 2015-08-01
construction = residential
highway = construction
name = Redmolen

Som jeg cyklede forbi forleden. Den var i alt fald ikke færdig sidste
august.

Og Esbjerg Vandværk:

way 374778346 rawedit josm edit
building = industrial
check_date = 2015-10-10
construction = yes
construction:man_made = water_works
name = Esbjerg Ny Vandværk
operator = Din Forsyning
website =
http://dinforsyning.dk/da-DK/Nyheder-2.aspx?PID=64=News_Item:211


Samt en cykelsti i Middelfart:

way 325260949 rawedit josm edit
construction = cycleway
highway = construction
opening_date = 2015-07
website =
http://www.middelfart.dk/Borger/Trafik/Her%20arbejder%20vi/Stitunnel%20under%20banen%20mellem%20Rs%20Poulsens%20Vej%20og%20Banev%C3%A6nget%20Brovejen






>>> Ellers kan spærringen forblive fejlagtigt vist i måndedsvis efter ophør.
>>> Sådan var det med Haraldsgade i Kbh., selvom jeg som last-editor af
>>> spærringen var medskyldig, men jeg regnede med “nogen” i millionbyen
>>> holdt øje med det.
>>> I stedet var det “ingen” der gjorde det.
>>>
>>>
>>> Mvh.
>>> Asger Frank
>>>
>>> --Den 8. jul. 2016 kl. 15.07 skrev Michael Larsen
>>> :
>>>
>>> Vejen er lukket resten af året - se også note 612368.  Dette er også kun
>>> begyndelsen på vejarbejdet, det kan forventes at hele vejen lukkes.
>>>
>>> /MichaelVL
>>>
>>> On fredag den 8. juli 2016 00.34.07 CEST Niels Elgaard Larsen wrote:
 http://www.openstreetmap.org/changeset/40433210

 "Road closed due to roadwork"

 Men vejen er vel ikke bare væk?
 Det virker lidt drastisk.

 Kunne man ikke bare sætte et construction tag?

 Og er der heller ikke nogen fortove tilbage.

 Der må være nogle århusianere, der ved hvad der foregår.
>>>
>>> ___
>>> Talk-dk mailing list
>>> Talk-dk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-dk
>>>
>>>
>>> ___
>>> Talk-dk mailing list
>>> Talk-dk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-dk
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
> 

-- 
Niels Elgaard Larsen

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

[Talk-GB] Universal Credits Map

[Jonathan]

The Dept of Work and Pension is using OSM for its map of Universal Credit areas:

http://dwp-stats.maps.arcgis.com/apps/Viewer/index.html?appid=1713828f61dc4c01a98eb9df1dcc5ab9

Nice to see Gov finally seeing the light.

Jonathan
--
http://bigfatfrog67.me

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

[Talk-us] Code Sprint at State of the Map US

[Mikel Maron]

Look forward to seeing many of you at SotM US!
Monday will have Code Sprints. I'm planning to focus on analysis, but would 
also love to delve into some core infrastructure topics.Who's planning on 
going? Have any more ideas of what you'd like to work on?
http://wiki.openstreetmap.org/wiki/State_Of_The_Map_U.S._2016/Hands-On_Day#Code_sprints

We don't get many chances to come together and work together in person. Would 
love to see this kick off more collaborative development in the community, into 
the future.
-Mikel  * Mikel Maron * +14152835207 @mikel s:mikelmaron___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tom Pfeifer]

Vermutlich bin ich ja politisch völlig inkorrekt, aber ich finde es
eigentlich ganz gut, dass eine Skulptur im Park keine rollstuhlgerechte
Toilette aufweist.

https://www.openstreetmap.org/node/258485628
tourism=artwork
artwork_type=sculpture
wheelchair=no
toilets:wheelchair=no

Warum sie mit Rollstuhl nicht zugänglich ist, kann ich angesichts eines
vorbeiführenden Fuss/Radweges nicht ganz nachvollziehen.

Das ist nur ein Beispiel, aber ich finde es befremdlich, an was für
unplausiblen Objekten immer mehr solche Tags aus der Wheelmap auftauchen.

Bushaltestellen und Supermarktparkplätze pflegen insgesamt wenig Toiletten
zu haben, dann natürlich auch keine für wheelchair.

Auch hat toilets:wheelchair fast 4000x den Wert 'unknown' (10%) [1],
kann man das nicht weglassen? Steht auch so im Wiki [3].

Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier gibt es mehr
'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.

Liest ein Sozialheld hier mit? Hochachtung für das Projekt als solches,
mir geht es um die technischen Details, die Vereinheitlichung des Taggings,
und die sinnvolle Steuerung des Mappings.

Sollten wir aufräumen wollen, dann gibt es noch recht häufig
'wheelchair:toilets=*' (472x) [4], vorwiegend im Ruhrgebiet offenbar aufgrund
eines alten Imports aus ruhr2010-barrierefrei.de und dessen Abfärbungen,
undokumentiert.

[1] https://taginfo.openstreetmap.org/keys/toilets%3Awheelchair#values
[2] https://taginfo.openstreetmap.org/keys/wheelchair_toilet#values
[3] https://wiki.openstreetmap.org/wiki/Key:toilets:wheelchair
[4] https://taginfo.openstreetmap.org/keys/wheelchair%3Atoilets

tom

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

Re: [Talk-us] Common names of highways do not match road signs.

[Paul Johnson]

On Fri, Jul 8, 2016 at 9:22 AM, Andy Townsend  wrote:

> I've tended to use "name:signed=no" and/or "ref:signed=no" if there's a
> name or ref that is agreed to be "correct" but not useful for navigation.


This is where things get *exceedingly* complicated in my region.   Signage
can be *highly* inconsistent for decades, and sometimes posted incorrectly
to begin with (for example, in eastern Broken Arrow, the route Creek
Turnpike is signed as Liberty Parkway on the actual turnpike (which is
correct, the route is named and not numbered, and it's late 1980s expansion
runs on a road whose name doesn't match the name of the route).  What's
incorrect, though, is that the ramps are signed as "TURNPIKE NORTH" or
"TURNPIKE SOUTH", which makes no sense considering that the route runs
east/west.  And the state legislature declares an emergency at least once
per session (and in at least one case since I moved here, actually called
an emergency session) to rename dozens of roads, which, since an emergency
is declared, OklaDOT has to post it *right now*, quality or consistency be
damned...and so it's often only posted where the name changes and none of
the intermediate signs until the intermediate signs wear out.  And with the
ridiculously long names that have been pumped out lately, where the highway
has been renamed, OklaDOT (already under absurd budget pressure), usually
just goes "screw it" and posts a simple route number trail blazer, removing
the old name signs when they wear out at the intermediate locations.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-legal-talk] Response regarding use of PSMA Administrative Boundaries (Australia)

[Diane Peters]

Do you mind expanding on what you mean when you say CC hasn't addressed the
viral nature of BY 4.0 relative to databases? Trying to understand.

Diane M. Peters
General Counsel, Creative Commons
Portland, Oregon
http://creativecommons.org/staff#dianepeters
13:00-21:00 UTC


On Fri, Jul 8, 2016 at 9:41 AM, Simon Poole  wrote:

>
> >
> > There are no substantial differences between the CC BY 3.0 and the CC BY
> > 4.0 licences. A summary of the differences can be found here:
> >
> https://creativecommons.org/share-your-work/licensing-considerations/version4/
> .
> > CC BY 4.0 (like CC BY 3.0) does not prevent OpenStreetMap from applying
> > your own licence to your products but requires end users to comply with
> > the CC BY licence (in relation to the original data).
> >
> Just a further remark, this comparaison does not address the potential
> viral character of CC by 4.0 when database rights are involved (which
> unluckily CC seems to be completly quiet on), which again would cause
> issues when including such data in OSM.
>
> Simon
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-dk] Jægersgårdgade i Århus

[Asger Frank]

Apropos: 

Hvis der ikke allerede underforstået er sådan en gentleman-m/k-aftale,
kunne man sige, at den der sætter en midlertidig spærring/ændring op 
også forsøger holde øje med, om den er bliver fjernet igen.

Ellers kan spærringen forblive fejlagtigt vist i måndedsvis efter ophør.
Sådan var det med Haraldsgade i Kbh., selvom jeg som last-editor af spærringen 
var medskyldig, 
men jeg regnede med “nogen” i millionbyen holdt øje med det. 
I stedet var det “ingen” der gjorde det.


Mvh. 
Asger Frank 

--Den 8. jul. 2016 kl. 15.07 skrev Michael Larsen 
:

Vejen er lukket resten af året - se også note 612368.  Dette er også kun 
begyndelsen på vejarbejdet, det kan forventes at hele vejen lukkes.

/MichaelVL

On fredag den 8. juli 2016 00.34.07 CEST Niels Elgaard Larsen wrote:
> http://www.openstreetmap.org/changeset/40433210
> 
> "Road closed due to roadwork"
> 
> Men vejen er vel ikke bare væk?
> Det virker lidt drastisk.
> 
> Kunne man ikke bare sætte et construction tag?
> 
> Og er der heller ikke nogen fortove tilbage.
> 
> Der må være nogle århusianere, der ved hvad der foregår.



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


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

Wochennotiz Nr. 311 28.06.2016–04.07.2016

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 311 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap 
Welt ist da:

http://blog.openstreetmap.de/blog/2016/07/wochennotiz-nr-311/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Wochennotiz Nr. 311 28.06.2016–04.07.2016

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 311 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap 
Welt ist da:

http://blog.openstreetmap.de/blog/2016/07/wochennotiz-nr-311/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Rafael Avila Coya]

Hola:

Además, creo que la mayoría de los renderizadores ignorarían los objetos 
amenity=waste_basket;vending_machine


Saludos,

Rafael.

On 08/07/16 15:12, Santiago Crespo wrote:

José Luis, tienes razón en que un nodo puede tener varios tags, pero
como una "key" (amenity) no se puede repetir, creo que quedaría algo así:

amenity=waste_basket;vending_machine
vending=excrement_bags
operator=Ayuntamiento de Madrid
payment:none=yes

Y si son papeleras únicamente para excrementos, añadir:
waste=dog_excrement

Aunque hay que intentar evitar el uso del punto y coma, pues es más
complicado al mapear y al usar luego esos datos[1]. Coincido con el wiki
en que es mejor elegir uno de los 2 valores o dividir en dos nodos.

Saludos,
Santiago Crespo

[1]
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use


On 07/08/2016 02:14 PM, Jose Luis Perez Diez wrote:

segun http://wiki.openstreetmap.org/wiki/Tags un nodo puede tener varios
tags y en este casos serian 5



amenity=vending_machine

amenity=waste_basket

vending=excrement_bags

payment:none=yes

operator=Ayuntamiento de Madrid



En el caso que fuesen dos operadores diferentes se podria usar
"operator:[vending_machine|waste_basket] ="

lo de hacerlos independientes no tiene sentido estamos hablando de una
unica ubicacion







___
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



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

Re: [OSM-legal-talk] Response regarding use of PSMA Administrative Boundaries (Australia)

[Simon Poole]

>
> There are no substantial differences between the CC BY 3.0 and the CC BY
> 4.0 licences. A summary of the differences can be found here:
> https://creativecommons.org/share-your-work/licensing-considerations/version4/.
>  
> CC BY 4.0 (like CC BY 3.0) does not prevent OpenStreetMap from applying
> your own licence to your products but requires end users to comply with
> the CC BY licence (in relation to the original data).
>
Just a further remark, this comparaison does not address the potential
viral character of CC by 4.0 when database rights are involved (which
unluckily CC seems to be completly quiet on), which again would cause
issues when including such data in OSM.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[Talk-it] OsmAnd e autovelox (speed cameras)

[Stefano Droghetti]

I cosiddetti "Autovelox" in OpenStreetMap, come sapete, si possono 
aggiungere in due modi:

1) L'apparecchio è un enforcement sulla way, è un punto della way.
2) L'apparecchio è di fianco alla way, e si prendono tre punti e si 
mettono in una relazione di enforcement: from (da dove l'autovelox 
comincia a fare foto), device (l'autovelox) e to (fin dove il velox fa 
le foto)


Finora OsmAnd, mi ha sempre segnalato correttamente i velox, sia se in 
OSM sono mappati in un modo o nell'altro.
Poi oggi all'improvviso, mentre testavo la mappa creata col mio script, 
ho visto con terrore che mi segnala solo quelli aggiunti col metodo 1 
(peraltro deprecato).
In preda al panico, ho cominciato a elaborare teorie su come fosse 
possibile che la mia mappa avesse quel difetto, quando ho provato a 
rimettere la sua mappa vecchia di default: l'ho scaricata, è di 15 
giorni fa più o meno, Emilia Romagna, provo e... sorpresa: fa lo stesso 
difetto. Sembra quasi che OsmAnd sia tornato alle vecchie versioni, 
quando vedeva solo i velox aggiunti col metodo 1.

Le FAQ effettivamente continuano a dire questo:
http://osmand.net/help-online#speed_cameras
ma in realtà la cosa era stata risolta da molto tempo e funzionava tutto 
bene: non mi capacito di come si possa essere tornati indietro.
O è un improvviso inspiegabile difetto del mio telefono? Ho visto la 
versione di OsmAnd Plus, è la 2.3.5 del 28/4/2016, regolarmente pagata e 
scaricata da Google Play. Ho provato a cancellare la cartella e 
reinstallare, ma niente, stesso problema, niente più autovelox aggiunti 
col metodo 2.

Mah!

--
Stefano Droghetti
www.stefanodroghetti.it
stefano.droghe...@gmail.com


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

[Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[Sérgio V .]

Claro Márcio, fiquem à vontade, é para usar mesmo.

Tá na wiki, tá pra uso.

Obrigado,

abraço


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

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-lv] maps.me-spotting

[Rihards]

ar maps.me dažreiz cilvēki sazīmē dīvainas lietas - 
http://mmwatch.osmz.ru/?country=Latvia var ik pa laikam ieskatīties, vai 
nav kas labojams.

--
 Rihards

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

Re: [Talk-us] Common names of highways do not match road signs.

[Andy Townsend]

On 08/07/2016 15:45, Jeffrey Ollie wrote:

... According to the Iowa DOT, it's official name is
"Interstate Highway 235" but ...


As Paul has already said, that sounds like a "ref" to me, not a "name".  
If something doesn't have a name, you don't need to create one for OSM...


Cheers,

Andy


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

Re: [Talk-us] Common names of highways do not match road signs.

[Jeffrey Ollie]

On Fri, Jul 8, 2016 at 9:22 AM, Andy Townsend  wrote:
>
> In the UK we've also had a problem with some (generally armchair) mappers
> thinking that "all roads must have a name" and "any name is better than no
> name" so they've been adding "names" that might have been in a news report
> ages ago along the lines of "Greater Chigley and Trumpton Bypass Scheme"
> which aren't signed and aren't useful.  I tend to move those to
> "description".

That kind of happens in the US - the main problems are highways and
freeways that have been given an official name (for some level of
"officialness") but aren't useful. The one that comes to mind is I-235
in Des Moines. According to the Iowa DOT, it's official name is
"Interstate Highway 235" but the city of Des Moines named it the "John
MacVicar Freeway" in the 1960's (or at least they did the parts that
are within the city limits)[1].  But, no one ever refers to it as
anything but I-235 and I'd bet that most people don't even know that
it's called anything but I-235. There's probably a tiny sign somewhere
that lets you know what it's called but the rest of the signage never
refers to it.

I'm sure that there are similar stories all over. I'm not sure if the
"*:signed=no" tags help with this but some scheme for tagging a name
that is official on some level but isn't useful for navigation
(because it isn't signed etc) would be helpful.

[1] http://www.iowadot.gov/autotrails/bridges.aspx?MacVicar%20Freeway

-- 
Jeff Ollie

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

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Agradeço Arlindo, mas somente por questão ética pedi autorização ao Sergio.

[]s
Marcio



From: Arlindo Pereira 
Sent: Friday, July 8, 2016 11:26 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Rio Olympics – Tutorial para Importação de Edificações

Marcio, 

creio que você possa divulgar sem problemas independentemente de autorização, 
uma vez que a licença do wiki do OSM é Creative Commons (CC-BY-SA). Mais 
detalhes em https://wiki.openstreetmap.org/wiki/Wiki_content_license.


[]s 
Arlindo Pereira

2016-07-08 9:17 GMT-03:00 :

  Bom dia Sergio.

  Parabéns pelo Tutorial.

  Você nos autoriza a reproduzir esse tutorial em nosso site Cocar, com os 
devidos créditos?

  []s
  Marcio

  From: Sérgio V. 
  Sent: Friday, July 8, 2016 8:57 AM
  To: talk-br@openstreetmap.org 
  Subject: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

  Bom dia pessoal.



  Tutorial para a importação de prédios no Rio de Janeiro está em:



  
https://wiki.openstreetmap.org/wiki/Rio_Olympics_%E2%80%93_Tutorial_para_Importa%C3%A7%C3%A3o_de_Edifica%C3%A7%C3%B5es






  Mais informações, contatar a comunidade:



  https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping#Contact






  Saudações,



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

  Sérgio / user:smaprs


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


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






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

Re: [Talk-it] Recinzioni in ferro

[girarsi_liste]

Il 08/07/2016 15:00, demon.box ha scritto:
> ciao, scusate, secondo voi queste recinzioni in ferro come si taggano oltre
> che ovviamente barrier=fence:
> 
>  

Per me questo railing

> 
> 
>  
> 
Anche questo railing



> 
>  
> 

idem

>  


Quest'ultimo  più pesante, direi metal.

Però possono andare bene anche metal tutti, perchè sono in ferro
battuto, diciamo che è opinabile. :)





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



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

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[Arlindo Pereira]

Marcio,

creio que você possa divulgar sem problemas independentemente de
autorização, uma vez que a licença do wiki do OSM é Creative Commons
(CC-BY-SA). Mais detalhes em
https://wiki.openstreetmap.org/wiki/Wiki_content_license.


[]s
Arlindo Pereira

2016-07-08 9:17 GMT-03:00 :

> Bom dia Sergio.
>
> Parabéns pelo Tutorial.
>
> Você nos autoriza a reproduzir esse tutorial em nosso site Cocar, com os
> devidos créditos?
>
> []s
> Marcio
>
> *From:* Sérgio V. 
> *Sent:* Friday, July 8, 2016 8:57 AM
> *To:* talk-br@openstreetmap.org
> *Subject:* [Talk-br] Rio Olympics – Tutorial para Importação de
> Edificações
>
>
> Bom dia pessoal.
>
>
>
> Tutorial para a importação de prédios no Rio de Janeiro está em:
>
>
>
>
> https://wiki.openstreetmap.org/wiki/Rio_Olympics_%E2%80%93_Tutorial_para_Importa%C3%A7%C3%A3o_de_Edifica%C3%A7%C3%B5es
>
>
>
> Mais informações, contatar a comunidade:
>
>
>
> https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping#Contact
>
>
>
>
>
> Saudações,
>
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio / user:smaprs
>
> --
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-us] Common names of highways do not match road signs.

[Andy Townsend]

I've tended to use "name:signed=no" and/or "ref:signed=no" if there's a 
name or ref that is agreed to be "correct" but not useful for 
navigation.  It's not used much:


http://taginfo.openstreetmap.org/keys/name%3Asigned

but it does mean that you can exclude "non-useful names" from maps made 
with OSM data, either in a slippy map:


https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1762

or on a Garmin.

In the UK we've also had a problem with some (generally armchair) 
mappers thinking that "all roads must have a name" and "any name is 
better than no name" so they've been adding "names" that might have been 
in a news report ages ago along the lines of "Greater Chigley and 
Trumpton Bypass Scheme" which aren't signed and aren't useful.  I tend 
to move those to "description".


Cheers,

Andy

On 08/07/2016 15:07, Jeffrey Ollie wrote:

It's been a long time since I've messed much with turning OSM data
into Garmin maps, but even back then the main problem was mapping the
OSM data model to the Garmin data model, what kind of data to retain,
what data to leave out, what data needed to be massaged before being
included etc. It's more of an art than a science. If you're having
problems, they best thing to do isn't to change the OSM data (unless
it's obviously wrong) but to discuss with the OpenMapChest people what
sort of changes could be made to their translation process to improve
your results. This is the first I've heard of OpenMapChest (but it
looks cool, I still have a Garmin GPS that I get out now and then) so
I don't know what the best way to contact them is (there's nothing on
their web site that provides specific contact information).

On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan  wrote:

It is confusing to use open street maps in my area(Central Ohio) for
driving directions since the "common names" of high ways do not match
road signs. The common names are used by open map chest for road names.
For example when turning on to State Route 315 with OpenMapChest loaded
on my GPS I am directed to turn on to Olentangy Freeway. However the
tiger name on open street maps is State route 315. Would it make more
sense to configure driving maps to use tiger names for driving
directions,  change commons names to include the state route number or
interstate number, or add state route number/ interstate number as a
different tag?

--
   Kevin Morgan
   morgankev...@fastmail.fm

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






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

Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Ilya Zverev]

Thanks for raising the issue. We at maps.me tried to follow the license: 
basically we are combining the OSM data without certain nodes (see the list of 
ids at http://direct.mapswithme.com/direct/latest/skipped_nodes.lst ) and a 
proprietary data set for hotels. Since we do not use any OSM information, like 
names or coordinates, for these hotels, I assumed the result could be 
considered a collective database.

Now, the matching process does indeed compare coordinates of hotels in both 
datasets, and filters out nodes in the OSM data. The list of nodes is 
published, so anyone can reproduce the open part of the data from a planet 
dump. Again, the proprietary data is in no way affected by the OSM data (it is 
added in its entirety, not a single object is omitted or altered using OSM 
data). So the last item in the guidelines ("all hotels not found in the 
OpenStreetMap data layers") does not apply.

If the LWG decides we are violating the license (and explains how, maybe 
producing another guidelines), we will remove all OSM hotels from our data. But 
for now I don't see how it's different from removing just some of the hotels.

IZ

Andrew Harvey wrote:
> According to [1] if someone combines non-horizontal layers together,
> the results must be shared under the ODBL.
> 
>> From my investigation it appears that the MAPS.ME app [2] is combining
> OSM hotels with non-OSM hotels.
> 
> https://tianjara.net/hosted/maps.me-1.png is a screenshot from the
> app. Hotel A appears in the app,
> but as far as I can tell was never in OSM but rather one of the hotels
> they've added to their app from Booking.com. Hotel B is from OSM.
> 
> This is the area https://www.openstreetmap.org/#map=18/-33.87758/151.20447
> 
> There are other examples of this too like this hotel
> https://www.openstreetmap.org/way/196622136 which in the app shows up
> next to their supplemented data like this
> https://tianjara.net/hosted/maps.me-2.png
> 
> Am I correct that in order to be complaint with the license MAPS.ME
> either need to make this data available under the ODBL or remove all
> OSM hotels from their app?
> 
> [1] 
> http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline#Examples_of_where_you_DO_need_to_share_your_non-OpenStreetMap_data
> [2] version 6.2.2-Google Data version: 160621


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

Re: [Talk-us] Common names of highways do not match road signs.

[Jeffrey Ollie]

It's been a long time since I've messed much with turning OSM data
into Garmin maps, but even back then the main problem was mapping the
OSM data model to the Garmin data model, what kind of data to retain,
what data to leave out, what data needed to be massaged before being
included etc. It's more of an art than a science. If you're having
problems, they best thing to do isn't to change the OSM data (unless
it's obviously wrong) but to discuss with the OpenMapChest people what
sort of changes could be made to their translation process to improve
your results. This is the first I've heard of OpenMapChest (but it
looks cool, I still have a Garmin GPS that I get out now and then) so
I don't know what the best way to contact them is (there's nothing on
their web site that provides specific contact information).

On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan  wrote:
> It is confusing to use open street maps in my area(Central Ohio) for
> driving directions since the "common names" of high ways do not match
> road signs. The common names are used by open map chest for road names.
> For example when turning on to State Route 315 with OpenMapChest loaded
> on my GPS I am directed to turn on to Olentangy Freeway. However the
> tiger name on open street maps is State route 315. Would it make more
> sense to configure driving maps to use tiger names for driving
> directions,  change commons names to include the state route number or
> interstate number, or add state route number/ interstate number as a
> different tag?
>
> --
>   Kevin Morgan
>   morgankev...@fastmail.fm
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us



-- 
Jeff Ollie

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

Re: [Talk-cz] edity z maps.me

[Jan Martinec]

To je to nejmenší - name:zh by db schroupala a ještě by se oblízla. Problém
je v povaze dat: "tady v hostelu bydlím" se zdá být častý zdroj duplicit.
Navíc to vypadá, že @Zverik si bere veškerou kritiku velmi osobně, a tím
vylévá dítě i s vaničkou - viz followup tady:
http://www.openstreetmap.org/user/BushmanK/diary/38946
byť uznávám, že jít proti maps.me s tezí "je to zlo,zlo,zlo" taky nepomáhá.

Nicméně se nejspíš rýsuje aspoň kontrola duplicit poblíž; jak rychle se to
objeví u  uživatelů, to je jiná věc (a jestli to bude kontrolovat i
bus_stop vs bus_station, jako ten dnešní na Florenci).

HPM
Dne 8. 7. 2016 3:20 odp. napsal uživatel "Miroslav Suchy" :

> Dne 8.7.2016 v 14:35 Jan Martinec napsal(a):
> > Číňanům v Praze je to fuk a mydlej to tam hlava nehlava.
>
> Jj. Hlavně píšou poznámky v čínštině, což je velká legrace :)
>
> Mirek
>
> ___
> 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

Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Simon Poole]

Am 08.07.2016 um 14:52 schrieb Andrew Harvey:
> According to [1] if someone combines non-horizontal layers together,
> the results must be shared under the ODBL.
No.

First a general remark:

A data consumer that is not complying with the ODbL always has two
options to comply with the licence:

- stop doing whatever is infringing the licence terms
- make the non-OSM data available as required by the licence.


>
> From my investigation it appears that the MAPS.ME app [2] is combining
> OSM hotels with non-OSM hotels.
>
> https://tianjara.net/hosted/maps.me-1.png is a screenshot from the
> app. Hotel A appears in the app,
> but as far as I can tell was never in OSM but rather one of the hotels
> they've added to their app from Booking.com. Hotel B is from OSM.
>
> This is the area https://www.openstreetmap.org/#map=18/-33.87758/151.20447
>
> There are other examples of this too like this hotel
> https://www.openstreetmap.org/way/196622136 which in the app shows up
> next to their supplemented data like this
> https://tianjara.net/hosted/maps.me-2.png
>
> Am I correct that in order to be complaint with the license MAPS.ME
> either need to make this data available under the ODBL or remove all
> OSM hotels from their app?

Not being compatible with any of the guidelines is not the same as not
complying with the licence (as I just exhaustively explained wrt the
Collective Database guideline).

On to the case at hand:

It is obviously completely OK from an ODbL pov to create a collective
database from two sets of POIs, one from OSM, one from a 3rd party if
they have no further dependencies and interaction.

Both the Horizontal Layer and the Collective Database guidelines address
a specific de-duplication issue (in respect to the above use case): if
you take your proprietary dataset and  remove all POIs from the OSM
dataset that exist in your data, the OSM dataset remains, naturally,
ODbL licensed and your proprietary dataset remains proprietary (with
some information leak via the OSM data). If you do the de-duplication
the other way around you would be potentially be damaging the
proprietary status of your data so you wouldn't try that to start with.

You could now distribute the two datasets in a combined fashion and
argue that each of them is an individual database and as a result the
combined dataset is a Collective Database, both guidelines rule that out
(again that does not imply that a judge applying the ODbL to such a case
would come to the same conclusion).

In summary both guidelines in this use scenario boil down to prohibiting
de-duplication (of any kind).

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Peter]

But what if this is just a layer above the OSM data technically?

Regards
Peter

On 08.07.2016 15:15, Janko Mihelić wrote:
> Maps.me made an announcement in the last update that they are using
> Booking.com data to show hotels and allow reserving hotel rooms from
> within the app. I doubt Booking.com released their data with a
> permissive license.
>
> Janko Mihelić
>
> pet, 8. srp 2016. u 14:54 Andrew Harvey  > napisao je:
>
> According to [1] if someone combines non-horizontal layers together,
> the results must be shared under the ODBL.
>
> From my investigation it appears that the MAPS.ME 
> app [2] is combining
> OSM hotels with non-OSM hotels.
>
> https://tianjara.net/hosted/maps.me-1.png is a screenshot from the
> app. Hotel A appears in the app,
> but as far as I can tell was never in OSM but rather one of the hotels
> they've added to their app from Booking.com. Hotel B is from OSM.
>
> This is the area
> https://www.openstreetmap.org/#map=18/-33.87758/151.20447
>
> There are other examples of this too like this hotel
> https://www.openstreetmap.org/way/196622136 which in the app shows up
> next to their supplemented data like this
> https://tianjara.net/hosted/maps.me-2.png
>
> Am I correct that in order to be complaint with the license
> MAPS.ME 
> either need to make this data available under the ODBL or remove all
> OSM hotels from their app?
>
> [1]
> 
> http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline#Examples_of_where_you_DO_need_to_share_your_non-OpenStreetMap_data
> [2] version 6.2.2-Google Data version: 160621
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk

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

Re: [Talk-cz] edity z maps.me

[Miroslav Suchy]

Dne 8.7.2016 v 14:35 Jan Martinec napsal(a):
> Číňanům v Praze je to fuk a mydlej to tam hlava nehlava.

Jj. Hlavně píšou poznámky v čínštině, což je velká legrace :)

Mirek

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

Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Janko Mihelić]

Maps.me made an announcement in the last update that they are using
Booking.com data to show hotels and allow reserving hotel rooms from within
the app. I doubt Booking.com released their data with a permissive license.

Janko Mihelić

pet, 8. srp 2016. u 14:54 Andrew Harvey  napisao
je:

> According to [1] if someone combines non-horizontal layers together,
> the results must be shared under the ODBL.
>
> From my investigation it appears that the MAPS.ME app [2] is combining
> OSM hotels with non-OSM hotels.
>
> https://tianjara.net/hosted/maps.me-1.png is a screenshot from the
> app. Hotel A appears in the app,
> but as far as I can tell was never in OSM but rather one of the hotels
> they've added to their app from Booking.com. Hotel B is from OSM.
>
> This is the area https://www.openstreetmap.org/#map=18/-33.87758/151.20447
>
> There are other examples of this too like this hotel
> https://www.openstreetmap.org/way/196622136 which in the app shows up
> next to their supplemented data like this
> https://tianjara.net/hosted/maps.me-2.png
>
> Am I correct that in order to be complaint with the license MAPS.ME
> either need to make this data available under the ODBL or remove all
> OSM hotels from their app?
>
> [1]
> http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline#Examples_of_where_you_DO_need_to_share_your_non-OpenStreetMap_data
> [2] version 6.2.2-Google Data version: 160621
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-co] Fwd: [HOT] Fwd: FW: Fwd: [acknowl-ej] Call for collaborative political ecology cartography (EJATLAS) (English/Espanol)

[carlos felipe castillo]

Para trabajar en ese campo, hay mucho. Ahí esta el trabajo de la mina
Colosa, adelantado por Fredy, la desaparición por minería del primer río en
Colombia, el río Sambingo en Bolívar Cauca, ademas muchas entidades del
orden ambiental y corporaciones necesitan datos para adelantar acciones por
el desastre de la minería en Colombia.

El vie., 8 jul. 2016 a las 6:55, hyan...@gmail.com ()
escribió:

> Hola maperos!
>
> Les comparto esta convocatoria a la cual quizás podamos participar debido
> a la pertinencia con problemas ambientales en el país o la región, se que
> hay antecedentes de mapeo de industria extractiva donde converge con
> choques de las comunidades.
>
> Saludos,
>
> Humberto Yances
> -- Mensaje reenviado --
> De: "Robert Banick" 
> Fecha: jul. 8, 2016 2:34 AM
> Asunto: [HOT] Fwd: FW: Fwd: [acknowl-ej] Call for collaborative political
> ecology cartography (EJATLAS) (English/Espanol)
> Para: "hot" 
> Cc:
>
> *Hi all, this may be of interest to some on this list*
>
>
>
>> *From:* Janis Alcorn
>> *Sent:* Tuesday, July 05, 2016 8:21 AM
>> *To:* Staff 
>> *Subject:* FW: Fwd: [acknowl-ej] Call for collaborative political
>> ecology cartography (EJATLAS) (English/Espanol)
>>
>>
>>
>> Please see call below and share with your collaborators ... in Spanish
>> and English
>>
>> " aims is to support action-research on environmental justice and
>> campaigns or ongoing work in the field, and create public and educational
>> materials dedicated to documenting and unveiling processes of destructive
>> extractivism and dispossession."
>>
>>
>>
>>
>>  Forwarded Message 
>>
>> *Subject: *
>>
>> [acknowl-ej] Call for collaborative political ecology cartography
>> (EJATLAS)
>>
>> *Date: *
>>
>> Tue, 5 Jul 2016 13:11:34 +0200
>>
>> *From: *
>>
>> Mariana Walter 
>> 
>>
>> *Reply-To: *
>>
>> Mariana Walter 
>> 
>>
>> *To: *
>>
>>
>>
>>
>>
>> Dear all,
>>
>> Please help us disseminate this call for EJATLAS collaborations with EJ
>> organizations and movements. We aim to reach civil society organizations
>> and movements from all over the world. The call is in English and Spanish.
>> (find them both under these lines).
>>
>>
>>
>> Calls and application forms here:
>> https://drive.google.com/folderview?id=0BzkqnLesuUb6MHBIVmJsRzRGbDg=sharing
>>
>>
>>
>>
>>
>> Best,
>>
>> ACKnowl-EJ Barcelona coordination team
>>
>>
>>
>>
>>
>> *Pilot call for collaborative political ecology cartography*
>>
>>
>>
>> *Small sub-contracts scheme to use mapping tools for Environmental
>> Justice related campaigns*
>>
>>
>>
>> *Presentation deadline*: August 31th, 2016 (Sunday)
>>
>> *Resolution*: September 12, 2016.
>>
>>
>>
>> This call is intended to foster collaborations between activists (NGOs,
>> think tanks, social movements, or community grassroots organisations, etc.)
>> and the Global Atlas of Environmental Justice project (ejatlas.org). The
>> aims is to support action-research on environmental justice and campaigns
>> or ongoing work in the field, and create public and educational materials
>> dedicated to documenting and unveiling processes of destructive
>> extractivism and dispossession.
>>
>>
>>
>> *About the EJATLAS and ACKnowl-EJ project:*
>>
>> The EJAtlas  is an online database and interactive
>> map that documents socio-environmental conflicts, defined as mobilizations
>> by local communities against particular economic activities whereby
>> environmental impacts are a key element of their grievances. It is based on
>> the work of hundreds of collaborators, from the academy, concerned
>> citizens, informal committees, NGOs and other activist groups, who have
>> been documenting environmental and social injustice and supporting
>> communities on the ground for years. It’s been mainly developed under
>> EJOLT , a research project coordinated at ICTA -
>> UAB, and will now continue under the ACKnowl-EJ international project.
>>
>>
>>
>> The ACKnowl-EJ
>> 
>> project (Academic-Activist Co-Produced Knowledge for Environmental Justice)
>> builds on and broadens the Atlas of Environmental Justice. This project
>> emphasizes the transformative potential of citizen movements,
>> ‘participatory’ approaches to environmental politics, and new institutional
>> practices born from diverse knowledge systems, showing how alternatives are
>> often born from resistance. ACKnowl-EJ is a 3 year project funded by the
>> International Social Science Council, coordinated by the Institute of
>> Sciences and Technologies  of the Autonomous
>> University of Barcelona (Dr. Leah Temper) and Kalpavriksh action group
>>  from India (Ashish 

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Santiago Crespo]

José Luis, tienes razón en que un nodo puede tener varios tags, pero
como una "key" (amenity) no se puede repetir, creo que quedaría algo así:

amenity=waste_basket;vending_machine
vending=excrement_bags
operator=Ayuntamiento de Madrid
payment:none=yes

Y si son papeleras únicamente para excrementos, añadir:
waste=dog_excrement

Aunque hay que intentar evitar el uso del punto y coma, pues es más
complicado al mapear y al usar luego esos datos[1]. Coincido con el wiki
en que es mejor elegir uno de los 2 valores o dividir en dos nodos.

Saludos,
Santiago Crespo

[1]
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use


On 07/08/2016 02:14 PM, Jose Luis Perez Diez wrote:
> segun http://wiki.openstreetmap.org/wiki/Tags un nodo puede tener varios
> tags y en este casos serian 5
> 
>  
> 
> amenity=vending_machine
> 
> amenity=waste_basket
> 
> vending=excrement_bags
> 
> payment:none=yes
> 
> operator=Ayuntamiento de Madrid
> 
>  
> 
> En el caso que fuesen dos operadores diferentes se podria usar
> "operator:[vending_machine|waste_basket] = "
> 
> lo de hacerlos independientes no tiene sentido estamos hablando de una
> unica ubicacion
> 
>  
> 
>  
> 
> 
> 
> ___
> 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-dk] Jægersgårdgade i Århus

[Michael Larsen]

Vejen er lukket resten af året - se også note 612368.  Dette er også kun 
begyndelsen på vejarbejdet, det kan forventes at hele vejen lukkes.

/MichaelVL

On fredag den 8. juli 2016 00.34.07 CEST Niels Elgaard Larsen wrote:
> http://www.openstreetmap.org/changeset/40433210
> 
> "Road closed due to roadwork"
> 
> Men vejen er vel ikke bare væk?
> Det virker lidt drastisk.
> 
> Kunne man ikke bare sætte et construction tag?
> 
> Og er der heller ikke nogen fortove tilbage.
> 
> Der må være nogle århusianere, der ved hvad der foregår.



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

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Rafael Avila Coya]

Hola:

Un nodo puede tener todas las etiquetas que desees, incluso 0. Pero no 
puedes tener 2 o más "keys" repetidas. Por lo tanto, no es posible dos 
amenity con valores diferentes.


En JOSM, por ejemplo, si abres un fichero que contiene un objeto con 
keys repetidos, como éste [1], se queda sólo con uno.


Saludos,

Rafael.

[1] https://www.dropbox.com/s/ggxz4gg98iu9m63/error.osm?dl=0

On 08/07/16 14:14, Jose Luis Perez Diez wrote:

El Divendres 08 Juliol 2016, a les 12:38:25, Rafael Avila Coya va escriure:

 > Lo de separarlos es porque son dos cosas diferentes. Cuál de los dos

 > amenity=* pondrías? Es lo mismo que cuando tienes un restaurante que es

 > pensión a la vez, por ejemplo. Yo creo que es más correcto.

segun http://wiki.openstreetmap.org/wiki/Tags un nodo puede tener varios
tags y en este casos serian 5

amenity=vending_machine

amenity=waste_basket

vending=excrement_bags

payment:none=yes

operator=Ayuntamiento de Madrid

En el caso que fuesen dos operadores diferentes se podria usar
"operator:[vending_machine|waste_basket] = "

lo de hacerlos independientes no tiene sentido estamos hablando de una
unica ubicacion



___
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

[Talk-it] Recinzioni in ferro

[demon.box]

ciao, scusate, secondo voi queste recinzioni in ferro come si taggano oltre
che ovviamente barrier=fence:

fence_type=bars

oppure

fence_type=metal  ?

 


 


 

 

sul wiki:

http://wiki.openstreetmap.org/wiki/Key:fence_type

barsA fence made of (usually metal) bars. 
metal   A fence mainly made of metal. This is a broad definition. Maybe in
conflict with 'railing' 

voi come vi regolate?
grazie.

--enrico









--
View this message in context: 
http://gis.19327.n5.nabble.com/Recinzioni-in-ferro-tp5877651.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Andrew Harvey]

According to [1] if someone combines non-horizontal layers together,
the results must be shared under the ODBL.

From my investigation it appears that the MAPS.ME app [2] is combining
OSM hotels with non-OSM hotels.

https://tianjara.net/hosted/maps.me-1.png is a screenshot from the
app. Hotel A appears in the app,
but as far as I can tell was never in OSM but rather one of the hotels
they've added to their app from Booking.com. Hotel B is from OSM.

This is the area https://www.openstreetmap.org/#map=18/-33.87758/151.20447

There are other examples of this too like this hotel
https://www.openstreetmap.org/way/196622136 which in the app shows up
next to their supplemented data like this
https://tianjara.net/hosted/maps.me-2.png

Am I correct that in order to be complaint with the license MAPS.ME
either need to make this data available under the ODBL or remove all
OSM hotels from their app?

[1] 
http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline#Examples_of_where_you_DO_need_to_share_your_non-OpenStreetMap_data
[2] version 6.2.2-Google Data version: 160621

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

Re: [Talk-cz] edity z maps.me (was: Poznámky uživatelů)

[Jan Martinec]

Ahoj,

situace s maps.me se IMHO trochu lepší - z changesetů vytvořených přes
maps.me je problematická jen menší část - ale zdá se, že konkrétně Číňanům
v Praze je to fuk a mydlej to tam hlava nehlava. Nejčastější je právě
duplicitní POI: http://www.openstreetmap.org/changeset/40340725

Nicméně - nejsme jediní, kdo si toho všiml, narazil jsem na velikou diskusi
tady https://www.openstreetmap.org/user/BushmanK/diary/38909 ; skoro to
vypadá, že ty diskuse k changesetům a zprávy z OSM uživatelům maps.me
padají někam do černé díry ("But a maps.me user is not aware of the fact
that I can send him a message through his account page, nor is maps.me
sending out alerts to users that a message for them was posted on their
account page."). Objevil se tam nicméně i vývojář maps.me (Zverik), takže
existuje šance, že se tohle někam pohne.

Nejsem si úplně jist, kolik z těch maps.mých changesetů jsou špatné edity -
zkusím se podívat na změny v Praze za poslední tři měsíce, vídám tam
spoustu nových uživatelů.

Piškvor
Dne 30. 6. 2016 3:20 odp. napsal uživatel "Karel Volný" :

zdar,

...
> Nesouhlasím.
> Všimli jste si kolik v poslední době přibylo POI? Hodně. A kolik
> takových objektů má vyplněnou website= a opening_hours=?
> Mimochodem ten editor v maps.me na otvírací hodiny je naprosto geniální.
> Za mě osobně má maps.me velkou pochvalu.
> Ono je mnohem jednoduší odstranit ty nevhodné poznámky než přijít na to,
> že v daném místě je restaurace/hotel/obchod.

přijít na to, že je v daném místě POI, se dá celkem jednoduše (strojově) v
databázích POI - kdysi se tu debatovalo o nějaké spolupráci, nevím, jak to
všechno skončilo ...

vyřešit poznámku ručně je možná mírně jednodušší nyní, jestliže nějaká
automatizace na POI neexistuje (fakt neexistuje?), ale dlouhodobě, má-li to
mít rostoucí tendenci, to moc neškáluje

a k tomu *navíc* přijít na to, že uživatel kromě poznámky nějakým způsobem
zprasil data, je ještě úplně jinej level ...

> Prostě pokud se zvedl počet editací, tak se zvedl i počet nevhodných
> editací. Resp. vyloženě špatné úpravy pomocí maps.me jsem ještě neviděl.
> Zatím se to IMHO projevuje jenom na poznámkách.

prosímtě, podívej se ještě jednou do mé první odpovědi v tomto vlákně

konkrétně třeba toto:
http://www.openstreetmap.org/changeset/40288150
má created_by   MAPS.ME android 6.1.9-Google

to nejsou "vyloženě špatné úpravy", když je vytvořen duplicitní bod k již
existujícímu?

a následně smazání adresního bodu bez náhrady? - pravda, to už proběhlo v
iD,
ale dotyčný by se bez maps.me *pravděpodobně* nedostal ani k iD

> A 150 poznámek za měsíc není nijak výrazné číslo abychom to museli
> omezovat. Je to jenom více než to bývalo.

skoro se mi nechce věřit, že tohle napsal člověk s letitými zkušenostmi z
různých bugtrackerů :-)

každopádně nebavíme se snad o úplném odstřižení uživatelů od možnosti
přispívat nebo něco upravit sami, pouze o tom, aby to dělali nějak
smysluplně

například k výše uvedenému - má maps.me nějakou funkci na to, aby uživatele
upozornil, že v těsné blízkosti bodu, který přidal, se již bod stejného typu
nachází a zeptal se ho, jestli radši nechce upravit ten místo vytvoření
duplicity?

pokud ne, RFE na přidání

pokud ano, stojí za to položit si otázku, proč to uživatele neodradilo a
stejně tu mapu zprasil, jak by ho šlo účinněji přimět, aby si to rozmyslel
lépe

> Jenom jsem chtěl upozornit na tento nástroj upozornit. Protože zcela
> jistě o něm mnozí neví. Sám jsem o něm před rokem nevěděl.

jasně, ale tož uvedl jsi nějaké problémy s ním spojené, tož by neškodilo,
kdyby "se" nějak pořešily, aspoň nakolik to z naší (=> předat vývojářům)
strany jde

K.

___
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

Re: [OSM-legal-talk] Response regarding use of PSMA Administrative Boundaries (Australia)

[Simon Poole]

Unluckily this simply confirms that the data cannot be included in OSM.
As I pointed out before, this is simply an indirect subsidy of the
producers of proprietary data and closed systems.

Simon


Am 08.07.2016 um 03:15 schrieb cleary:
> The issue of using the Australian PSMA Administrative Boundaries in OSM
> was discussed in both talk-au and legal-talk lists.  Subsequently I
> submitted a request to the Spatial Unit, Department of Prime Minister
> and Cabinet, seeking permission and stating the issues as clearly as I
> could.  Today I received the following response with my initial request
> shown below.
>
> It explicitly states we are not responsible for the actions of
> downstream users  but I think we need the legal-talk group to clarify if
> the response helps us.  For this reason, this response is being
> submitted to both lists.
>
>
>
> - Original message -
> From: Spatial 
> To: "o...@97k.com" 
> Cc: Spatial 
> Subject: RE: Permission for OpenStreetMap to use PSMA Administrative
> Boundaries [SEC=UNCLASSIFIED]
> Date: Fri, 8 Jul 2016 00:19:27 +
>
> UNCLASSIFIED
> Dear Michael
>
> Thank you for your email seeking clarification about the licensing
> conditions regarding the PSMA Administrative Boundaries dataset.
>
> Given the large volume of public datasets available via data.gov.au
> (over 8,200 datasets), we are unable to provide statements with explicit
> permission for use to individual users.
>
> However, we can provide some clarification regarding your concerns. 
>
> There are no substantial differences between the CC BY 3.0 and the CC BY
> 4.0 licences. A summary of the differences can be found here:
> https://creativecommons.org/share-your-work/licensing-considerations/version4/.
>  
> CC BY 4.0 (like CC BY 3.0) does not prevent OpenStreetMap from applying
> your own licence to your products but requires end users to comply with
> the CC BY licence (in relation to the original data).
>
> The preferred attribution for adapted material using the PSMA
> Administrative Boundaries dataset is:
>
> Incorporates or developed using Administrative Boundaries (c)PSMA
> Australia Limited licensed by the Commonwealth of Australia under
> Creative Commons Attribution 4.0 International licence (CC BY 4.0).
>
> We can also confirm that OpenStreetMap is not responsible for the
> actions of your downstream users. Given the nature of the CC BY licence,
> your downstream users directly licence the Administrative Boundaries
> data from the Commonwealth. Provided that OpenStreetMap comply with the
> licence, then any breach by third parties leads to automatic termination
> of that third party's rights to use the material and does not impact
> OpenStreetMap's licence.
>
> I trust this information has been of assistance.
>
> Kind regards,
>
> Spatial Policy team
>
>
> -Original Message-
> From: cleary [mailto:o...@97k.com]
> Sent: Thursday, 30 June 2016 6:08 PM
> To: Spatial
> Subject: Permission for OpenStreetMap to use PSMA Administrative
> Boundaries
>
>
>
> I am a volunteer contributor to OpenStreetMap (OSM)
> (www.openstreetmap.org) which provides a map, based on open data, for
> use by anyone who wishes to access it. I understand that OpenStreetMap
> is the largest open data map project in the world. Various bodies,
> including some Government organisations, are increasingly using OSM and
> I was pleased to note that some pages on the data.gov.au website are
> using OSM.
>
> Approximately five years ago, OSM was given explicit permission to
> incorporate data from Australian Government public information datasets
> which had been published under CC-BY-2.5 and CC-BY-3.0 licences. The
> explicit permission allowed OSM to incorporate and publish these CC-BY
> licensed geographic coordinate datasets under a free and open license,
> including the Open Database License, provided that attribution was made
> in the Contributors page of the OpenStreetMap Wiki
> (http://wiki.openstreetmap.org/wiki/Contributors) including each dataset
> being identified with specified informaton. (See
> http://wiki.openstreetmap.org/wiki/Attribution/data.gov.au_explicit_permission)
>
> I write now to request extension of permission to include the PSMA
> Administrative Boundaries.
>
> It is perceived that issues which may require clarification in regard to
> the PSMA Administrative Boundaries are:
>
> 1. The PSMA Administrative Boundaries are provided under a CC-BY-4.0
> licence, not the earlier licences previously specified.
> 2. The explicit permission that OSM received was for data released
> directly by the Australian Government, and it is unclear if that would
> apply to data that which has been licensed from third parties for
> distribution, which seems to be the case with the PSMA boundaries.
> 3. There is a requirement that the data may be used only in ways that
> are consistent with the Australian Privacy Principles. OSM does not
> collect or use 

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Jose Luis Perez Diez]

El Divendres 08 Juliol 2016, a les 12:38:25, Rafael Avila Coya va escriure:
> Lo de separarlos es porque son dos cosas diferentes. Cuál de los dos 
> amenity=* pondrías? Es lo mismo que cuando tienes un restaurante que es 
> pensión a la vez, por ejemplo. Yo creo que es más correcto.

segun http://wiki.openstreetmap.org/wiki/Tags un nodo puede tener varios tags y 
en este casos serian 5

amenity=vending_machine
amenity=waste_basket
vending=excrement_bags
payment:none=yes 
operator=Ayuntamiento de Madrid 

En el caso que fuesen dos operadores diferentes se podria usar 
"operator:[vending_machine|waste_basket] = "
lo de hacerlos independientes no tiene sentido estamos hablando de una unica 
ubicacion 


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

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Bom dia Sergio.

Parabéns pelo Tutorial.

Você nos autoriza a reproduzir esse tutorial em nosso site Cocar, com os 
devidos créditos?

[]s
Marcio

From: Sérgio V. 
Sent: Friday, July 8, 2016 8:57 AM
To: talk-br@openstreetmap.org 
Subject: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

Bom dia pessoal.



Tutorial para a importação de prédios no Rio de Janeiro está em:



https://wiki.openstreetmap.org/wiki/Rio_Olympics_%E2%80%93_Tutorial_para_Importa%C3%A7%C3%A3o_de_Edifica%C3%A7%C3%B5es






Mais informações, contatar a comunidade:



https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping#Contact






Saudações,



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

Sérgio / user:smaprs




___
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

[OSM-co] Fwd: [HOT] Fwd: FW: Fwd: [acknowl-ej] Call for collaborative political ecology cartography (EJATLAS) (English/Espanol)

[hyan...@gmail.com]

Hola maperos!

Les comparto esta convocatoria a la cual quizás podamos participar debido a
la pertinencia con problemas ambientales en el país o la región, se que hay
antecedentes de mapeo de industria extractiva donde converge con choques de
las comunidades.

Saludos,

Humberto Yances
-- Mensaje reenviado --
De: "Robert Banick" 
Fecha: jul. 8, 2016 2:34 AM
Asunto: [HOT] Fwd: FW: Fwd: [acknowl-ej] Call for collaborative political
ecology cartography (EJATLAS) (English/Espanol)
Para: "hot" 
Cc:

*Hi all, this may be of interest to some on this list*



> *From:* Janis Alcorn
> *Sent:* Tuesday, July 05, 2016 8:21 AM
> *To:* Staff 
> *Subject:* FW: Fwd: [acknowl-ej] Call for collaborative political ecology
> cartography (EJATLAS) (English/Espanol)
>
>
>
> Please see call below and share with your collaborators ... in Spanish and
> English
>
> " aims is to support action-research on environmental justice and
> campaigns or ongoing work in the field, and create public and educational
> materials dedicated to documenting and unveiling processes of destructive
> extractivism and dispossession."
>
>
>
>
>  Forwarded Message 
>
> *Subject: *
>
> [acknowl-ej] Call for collaborative political ecology cartography (EJATLAS)
>
> *Date: *
>
> Tue, 5 Jul 2016 13:11:34 +0200
>
> *From: *
>
> Mariana Walter  
>
> *Reply-To: *
>
> Mariana Walter  
>
> *To: *
>
>
>
>
>
> Dear all,
>
> Please help us disseminate this call for EJATLAS collaborations with EJ
> organizations and movements. We aim to reach civil society organizations
> and movements from all over the world. The call is in English and Spanish.
> (find them both under these lines).
>
>
>
> Calls and application forms here:
> https://drive.google.com/folderview?id=0BzkqnLesuUb6MHBIVmJsRzRGbDg=sharing
>
>
>
>
>
> Best,
>
> ACKnowl-EJ Barcelona coordination team
>
>
>
>
>
> *Pilot call for collaborative political ecology cartography*
>
>
>
> *Small sub-contracts scheme to use mapping tools for Environmental Justice
> related campaigns*
>
>
>
> *Presentation deadline*: August 31th, 2016 (Sunday)
>
> *Resolution*: September 12, 2016.
>
>
>
> This call is intended to foster collaborations between activists (NGOs,
> think tanks, social movements, or community grassroots organisations, etc.)
> and the Global Atlas of Environmental Justice project (ejatlas.org). The
> aims is to support action-research on environmental justice and campaigns
> or ongoing work in the field, and create public and educational materials
> dedicated to documenting and unveiling processes of destructive
> extractivism and dispossession.
>
>
>
> *About the EJATLAS and ACKnowl-EJ project:*
>
> The EJAtlas  is an online database and interactive
> map that documents socio-environmental conflicts, defined as mobilizations
> by local communities against particular economic activities whereby
> environmental impacts are a key element of their grievances. It is based on
> the work of hundreds of collaborators, from the academy, concerned
> citizens, informal committees, NGOs and other activist groups, who have
> been documenting environmental and social injustice and supporting
> communities on the ground for years. It’s been mainly developed under
> EJOLT , a research project coordinated at ICTA -
> UAB, and will now continue under the ACKnowl-EJ international project.
>
>
>
> The ACKnowl-EJ
> 
> project (Academic-Activist Co-Produced Knowledge for Environmental Justice)
> builds on and broadens the Atlas of Environmental Justice. This project
> emphasizes the transformative potential of citizen movements,
> ‘participatory’ approaches to environmental politics, and new institutional
> practices born from diverse knowledge systems, showing how alternatives are
> often born from resistance. ACKnowl-EJ is a 3 year project funded by the
> International Social Science Council, coordinated by the Institute of
> Sciences and Technologies  of the Autonomous
> University of Barcelona (Dr. Leah Temper) and Kalpavriksh action group
>  from India (Ashish Kothari).
>
>
>
> This call aims to expand the EJATLAs and foster the development of
> powerful featured maps (see for instance the featured map on Mining
> Conflicts in Latin America ,
> to support the international day against Chevron Texaco
> or to denounce the expansion
> of fracking ).  It aims to
> engage in further experimentation on collaborative research and
> co-production of knowledge for social change.
>
>
>
> *Objective of the call:*
>
> 

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Santiago Crespo]

Creo que la opción de 2 nodos es más correcta, porque son 2 instalaciones.

Por otro lado, tampoco me parece mal lo que propone Alejandro, pues creo
que un usuario que quiera encontrar bolsas posiblemente buscará
vending=excrement_bags (sin amenity=vending_machine) y otro que quiera
las papeleras buscará amenity=waste_basket. Donde digo usuario quiero
decir usuarios, aplicaciones, renders, etc.

En Madrid, creo que hay 2 tipos de dispensadores: los integrados en las
papeleras que admiten todo tipo de basura pequeña[1] y los que están en
papeleras que son únicamente para excrementos[2] (waste=dog_excrement)

Saludos,
Santiago Crespo

[1] http://nisa-arce.net/blog/wp-content/uploads/2013/03/madrid10.jpg
[2] https://i.imgur.com/AhnvBtz.png


On 07/08/2016 12:30 PM, Alejandro Moreno Calvo wrote:
> Yo lo de separar en 2 nodos no lo veo porque físicamente son el mismo
> aparato. ¿Qué ventajas veis a tenerlo en 2 nodos?¿No va a implicar más
> mantenimiento?
> 
> El 8 de julio de 2016, 12:25, Rafael Avila Coya  > escribió:
> 
> Hola:
> 
> Creo que mejor, coincidiendo en muchos puntos con Santiago:
> 
> * amenity=vending_machine
> * vending=excrement_bags
> * payment:none=yes ó fee=no (yo me inclinaría por payment:none=yes)
> * operator=Ayuntamiento de Madrid
> 
> Yo separaría en dos nodos. En un segundo nodo (a centímetros del
> anterior):
> 
> * amenity=waste_basket
> * waste=dog_excrement
> * operator=Ayuntamiento de Madrid
> 
> Saludos,
> 
> Rafael.
> 
> 
> On 08/07/16 12:16, Santiago Crespo wrote:
> 
> Hola,
> 
> Yo cambiaba fee=no por payment:none=yes, como pone en la wiki [1],
> aunque entiendo que da un poco igual.
> 
> También mira la discusión sobre si conviene separar en 2 nodos la
> papelera y el dispensador, creo que tiene sentido hacerlo [2]
> 
> Y en Madrid podríamos añadir operator=Ayuntamiento de Madrid
> 
> Saludos,
> Santiago Crespo
> 
> [1] https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags
> [2]
> https://wiki.openstreetmap.org/wiki/Talk:Tag:vending%3Dexcrement_bags
> 
> On 07/08/2016 11:20 AM, Alejandro Moreno Calvo wrote:
> 
> Buenos días.
> 
> Estoy pensando en empezar a mapear aquellas papeleras que tienen
> dispensador de bolsas para excrementos de perros.
> 
> Las etiquetas que había pensado usar son:
> 
> amenity=waste_basket
> vending=excrement_bags
> fee=no
> 
> ¿Lo veis bien o cambiaríais algo?
> 
> P.D. Para Madrid está solicitado la ubicación de las mismas
> que está en
> estudio [
> 
> http://datos.madrid.es/portal/site/egob/menuitem.3efdb29b813ad8241e830cc2a8a409a0/?vgnextoid=a005df93c5014510VgnVCM201f4a900aRCRD=102612b9ace9f310VgnVCM10171f5a0aRCRD=default=a005df93c5014510VgnVCM201f4a900aRCRD
> ]
> 
> 
> ___
> 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
> 
> 
> ___
> 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
> 

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

Re: [Talk-it] import civici Emilia Romagna

[Maurizio Napolitano]

Forse questo torna utile
https://github.com/knowname/morituri
---
morituri -- the COMMercial2OSM converter

comm2osm creates an OSM (OpenStreetMap) PBF/XML/etc. file from
commercial shapefiles to be able to use OSM tools on the data.

The architecture is plugin based. Currently there is a plugin (navteq)
for converting routable Navteq data from the "NAVSTREETS Street Data
Reference Manual v5.4" format into OSM format.

WARNING: DO NOT UPLOAD CONVERTED DATA TO OSM. Even if you were legally
allowed to do so, imports into OSM are problematic due to the
following reasons:

the converted data is not clean for imports
duplicates (deduplication is hard)
hinders community development
data might be bad - reviews missing
shallow data
---

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

Re: [Talk-it] import civici Emilia Romagna

[Cascafico Giovanni]

> - aggiungere il C.A.P. riferendosi a questa mappa:
> http://www.rudybandiera.com/wp-content/uploads/2009/03/cap-ferrara.jpg (N.B.
> qualcuno ha idea di come si possa fare velocemente una cosa del genere?
> Altrimenti c'è da impazzire.)

Tempo fa veniva suggerito in ML di usare la tabella degli indirizzi
della Pubblica Amministrazione [1], essendo questi capillarmente
distribuiti sul territorio nazionale e soprattutto in IODL 2.0

[1] http://www.lineaamica.gov.it/rubricapa/opendata/rubricapa_csv.zip

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

Re: [Talk-it] import civici Emilia Romagna

[Cascafico Giovanni]

> - La normalizzazione mi sembra agisca su preposizioni e abbreviazioni del
> nome via, purtroppo non conosco lo standard ISTAT, è sufficiente? Chissà
> perché ero convinto che andassero normalizzate anche le definizioni es. Via
> G. Garibaldi => Via Giuseppe Garibaldi, Via Garibaldi => Via Giuseppe
> Garibaldi. Sbagliavo anche qui immagino :)

Non sbagliavi: ISTAT cita proprio i Garibaldi Giuseppe ed Anita, per
dire che in qs caso deve esserci scritto "Giuseppe Garibaldi"

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

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Alejandro Moreno Calvo]

Yo lo de separar en 2 nodos no lo veo porque físicamente son el mismo
aparato. ¿Qué ventajas veis a tenerlo en 2 nodos?¿No va a implicar más
mantenimiento?

El 8 de julio de 2016, 12:25, Rafael Avila Coya 
escribió:

> Hola:
>
> Creo que mejor, coincidiendo en muchos puntos con Santiago:
>
> * amenity=vending_machine
> * vending=excrement_bags
> * payment:none=yes ó fee=no (yo me inclinaría por payment:none=yes)
> * operator=Ayuntamiento de Madrid
>
> Yo separaría en dos nodos. En un segundo nodo (a centímetros del anterior):
>
> * amenity=waste_basket
> * waste=dog_excrement
> * operator=Ayuntamiento de Madrid
>
> Saludos,
>
> Rafael.
>
>
> On 08/07/16 12:16, Santiago Crespo wrote:
>
>> Hola,
>>
>> Yo cambiaba fee=no por payment:none=yes, como pone en la wiki [1],
>> aunque entiendo que da un poco igual.
>>
>> También mira la discusión sobre si conviene separar en 2 nodos la
>> papelera y el dispensador, creo que tiene sentido hacerlo [2]
>>
>> Y en Madrid podríamos añadir operator=Ayuntamiento de Madrid
>>
>> Saludos,
>> Santiago Crespo
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags
>> [2] https://wiki.openstreetmap.org/wiki/Talk:Tag:vending%3Dexcrement_bags
>>
>> On 07/08/2016 11:20 AM, Alejandro Moreno Calvo wrote:
>>
>>> Buenos días.
>>>
>>> Estoy pensando en empezar a mapear aquellas papeleras que tienen
>>> dispensador de bolsas para excrementos de perros.
>>>
>>> Las etiquetas que había pensado usar son:
>>>
>>> amenity=waste_basket
>>> vending=excrement_bags
>>> fee=no
>>>
>>> ¿Lo veis bien o cambiaríais algo?
>>>
>>> P.D. Para Madrid está solicitado la ubicación de las mismas que está en
>>> estudio [
>>>
>>> http://datos.madrid.es/portal/site/egob/menuitem.3efdb29b813ad8241e830cc2a8a409a0/?vgnextoid=a005df93c5014510VgnVCM201f4a900aRCRD=102612b9ace9f310VgnVCM10171f5a0aRCRD=default=a005df93c5014510VgnVCM201f4a900aRCRD
>>> ]
>>>
>>>
>>> ___
>>> 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
>>
>>
> ___
> 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-es] Mapear papeleras con dispensador de bolsas para perros

[Rafael Avila Coya]

Hola:

Creo que mejor, coincidiendo en muchos puntos con Santiago:

* amenity=vending_machine
* vending=excrement_bags
* payment:none=yes ó fee=no (yo me inclinaría por payment:none=yes)
* operator=Ayuntamiento de Madrid

Yo separaría en dos nodos. En un segundo nodo (a centímetros del anterior):

* amenity=waste_basket
* waste=dog_excrement
* operator=Ayuntamiento de Madrid

Saludos,

Rafael.

On 08/07/16 12:16, Santiago Crespo wrote:

Hola,

Yo cambiaba fee=no por payment:none=yes, como pone en la wiki [1],
aunque entiendo que da un poco igual.

También mira la discusión sobre si conviene separar en 2 nodos la
papelera y el dispensador, creo que tiene sentido hacerlo [2]

Y en Madrid podríamos añadir operator=Ayuntamiento de Madrid

Saludos,
Santiago Crespo

[1] https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags
[2] https://wiki.openstreetmap.org/wiki/Talk:Tag:vending%3Dexcrement_bags

On 07/08/2016 11:20 AM, Alejandro Moreno Calvo wrote:

Buenos días.

Estoy pensando en empezar a mapear aquellas papeleras que tienen
dispensador de bolsas para excrementos de perros.

Las etiquetas que había pensado usar son:

amenity=waste_basket
vending=excrement_bags
fee=no

¿Lo veis bien o cambiaríais algo?

P.D. Para Madrid está solicitado la ubicación de las mismas que está en
estudio [
http://datos.madrid.es/portal/site/egob/menuitem.3efdb29b813ad8241e830cc2a8a409a0/?vgnextoid=a005df93c5014510VgnVCM201f4a900aRCRD=102612b9ace9f310VgnVCM10171f5a0aRCRD=default=a005df93c5014510VgnVCM201f4a900aRCRD
]


___
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



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

Re: [Talk-es] Mapear papeleras con dispensador de bolsas para perros

[Santiago Crespo]

Hola,

Yo cambiaba fee=no por payment:none=yes, como pone en la wiki [1],
aunque entiendo que da un poco igual.

También mira la discusión sobre si conviene separar en 2 nodos la
papelera y el dispensador, creo que tiene sentido hacerlo [2]

Y en Madrid podríamos añadir operator=Ayuntamiento de Madrid

Saludos,
Santiago Crespo

[1] https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags
[2] https://wiki.openstreetmap.org/wiki/Talk:Tag:vending%3Dexcrement_bags

On 07/08/2016 11:20 AM, Alejandro Moreno Calvo wrote:
> Buenos días.
> 
> Estoy pensando en empezar a mapear aquellas papeleras que tienen
> dispensador de bolsas para excrementos de perros.
> 
> Las etiquetas que había pensado usar son:
> 
> amenity=waste_basket
> vending=excrement_bags
> fee=no
> 
> ¿Lo veis bien o cambiaríais algo?
> 
> P.D. Para Madrid está solicitado la ubicación de las mismas que está en
> estudio [
> http://datos.madrid.es/portal/site/egob/menuitem.3efdb29b813ad8241e830cc2a8a409a0/?vgnextoid=a005df93c5014510VgnVCM201f4a900aRCRD=102612b9ace9f310VgnVCM10171f5a0aRCRD=default=a005df93c5014510VgnVCM201f4a900aRCRD
> ]
> 
> 
> ___
> 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-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 08 lug 2016, alle ore 12:02, Andrea Musuruane  
> ha scritto:
> 
> 2016-07-08 11:44 GMT+02:00 Lorenzo  >:
> 
> Ciao,
> a quanto pare la cosa sembra più semplice di quello che avevo immaginato 
> usando gli script di Andrea, un paio di domande:
> 
> - nello script (non sono un programmatore quindi metto subito le mani avanti 
> :) non vedo la conversione di encode verso UTF-8 che pensavo fosse 
> necessaria, lo fa in “automatico”.
> 
> 
> Direi di sì. Prova ad approfondire come funziona ogr2osm:
> http://wiki.openstreetmap.org/wiki/Ogr2osm 
> 
> 
> https://github.com/pnorman/ogr2osm 

Grazie delle indicazioni, ci guardo.


> 
>  
> - La normalizzazione mi sembra agisca su preposizioni e abbreviazioni del 
> nome via, purtroppo non conosco lo standard ISTAT, è sufficiente? Chissà 
> perché ero convinto che andassero normalizzate anche le definizioni es. Via 
> G. Garibaldi => Via Giuseppe Garibaldi, Via Garibaldi => Via Giuseppe 
> Garibaldi. Sbagliavo anche qui immagino :)
> 
> Come fai a convertire in automatico le abbreviazioni? Non puoi sapere se “Via 
> Garibaldi" si riferisce a Giuseppe o ad Anita a priori.

Effettivamente è vero.

> 
> 
> Questi lavori li devi fare a posteriori, ad esempio usando questi tool:
> http://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella#QA
>  
> 
> 
> E' per questo che l'import è solo una prima parte del processo. Quella di 
> Quality Assurance deve obbligatoriamente seguire e sistemare tutte le cose 
> che in automatico non si possono fare.
> 
> Sarebbe bene fare come hanno fatto in Friuli, ovvero importare (e sistemare) 
> un comune per volta.

Su questo non ho un’idea precisa, immagino che chi come te lo ha fatto abbia 
già valutato pro e contro.
Grazie.
l.


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

Re: [Talk-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 08 lug 2016, alle ore 12:00, Alessandro Palmas 
>  ha scritto:
> 
> Il 08/07/2016 11:44, Lorenzo ha scritto:
>> 
>>> Il giorno 08 lug 2016, alle ore 11:34, Lorenzo >> > ha scritto:
>> 
>> Ciao,
>> a quanto pare la cosa sembra più semplice di quello che avevo immaginato 
>> usando gli script di Andrea, un paio di domande:
>> 
>> - nello script (non sono un programmatore quindi metto subito le mani avanti 
>> :) non vedo la conversione di encode verso UTF-8 che pensavo fosse 
>> necessaria, lo fa in “automatico”.
> 
> 
> Io apro con QGIS e salvo in csv codifica UTF8 (o system)

Mi sembra ottimo.


> 
> Dopo Via Fratelli Corvi ho trovato anche Via Don Luigi Sterzi (a Castelvetro 
> Piacentino), nonchè "Strada Pane e Vino(Delib.C” (scritto nel record proprio 
> così)

È quello che immaginavo.



> 
> 
> 
>> 
>> - La normalizzazione mi sembra agisca su preposizioni e abbreviazioni del 
>> nome via, purtroppo non conosco lo standard ISTAT, è sufficiente? Chissà 
>> perché ero convinto che andassero normalizzate anche le definizioni es. Via 
>> G. Garibaldi => Via Giuseppe Garibaldi, Via Garibaldi => Via Giuseppe 
>> Garibaldi. Sbagliavo anche qui immagino :)
> 
> Ecco, qui le cose si complicano perchè da una parte ci sono le ordinanze 
> comunali (se sulla delibera hanno scritto Via G. Garibaldi), dall'altra il 
> nuovo regolamento nazionale. In mezzo c’è il mappatore che mappa quello 
> scritto sulla targa (a Genova ho trovato più di una strada con 3 cartelli 
> diversi apposti a incroci diversi in decenni diversi con 3 scritte 
> leggermente diverse).

Mi sembra che per le importazioni precedenti si sia scelto di mappare quello 
che appare, quindi ciò che ha deliberato il comune.

> 
> 
> 
>> 
>> Certo che si imparano un sacco di cose!
>> Ciao.
>> l.
> 
> Esatto, sto scoprendo strumenti e metodologie a me nuove. Anche questo è il 
> bello della comunità collaborativa :-)
> 
> Alessandro Ale_Zena_IT
> 
> 
> P.S.: Lorenzo, se questo w.e. vieni a Roma per MappiaM faremo un po’ di 
> mappatura con correzione RTK

Mi piacerebbe, ma le trasferte sono contingentate…
Grazie delle risposte.
l.

> 
> ___
> 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] import civici Emilia Romagna

[Andrea Musuruane]

2016-07-08 11:44 GMT+02:00 Lorenzo :

>
> Ciao,
> a quanto pare la cosa sembra più semplice di quello che avevo immaginato
> usando gli script di Andrea, un paio di domande:
>
> - nello script (non sono un programmatore quindi metto subito le mani
> avanti :) non vedo la conversione di encode verso UTF-8 che pensavo fosse
> necessaria, lo fa in “automatico”.
>


Direi di sì. Prova ad approfondire come funziona ogr2osm:
http://wiki.openstreetmap.org/wiki/Ogr2osm

https://github.com/pnorman/ogr2osm



> - La normalizzazione mi sembra agisca su preposizioni e abbreviazioni del
> nome via, purtroppo non conosco lo standard ISTAT, è sufficiente? Chissà
> perché ero convinto che andassero normalizzate anche le definizioni es. Via
> G. Garibaldi => Via Giuseppe Garibaldi, Via Garibaldi => Via Giuseppe
> Garibaldi. Sbagliavo anche qui immagino :)
>

Come fai a convertire in automatico le abbreviazioni? Non puoi sapere se
"Via Garibaldi" si riferisce a Giuseppe o ad Anita a priori.

Questi lavori li devi fare a posteriori, ad esempio usando questi tool:
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella#QA

E' per questo che l'import è solo una prima parte del processo. Quella di
Quality Assurance deve obbligatoriamente seguire e sistemare tutte le cose
che in automatico non si possono fare.

Sarebbe bene fare come hanno fatto in Friuli, ovvero importare (e
sistemare) un comune per volta.

Ciao,

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

Re: [Talk-it] import civici Emilia Romagna

[Alessandro Palmas]

Il 08/07/2016 11:44, Lorenzo ha scritto:


Il giorno 08 lug 2016, alle ore 11:34, Lorenzo 
> ha scritto:


Ciao,
a quanto pare la cosa sembra più semplice di quello che avevo 
immaginato usando gli script di Andrea, un paio di domande:


- nello script (non sono un programmatore quindi metto subito le mani 
avanti :) non vedo la conversione di encode verso UTF-8 che pensavo 
fosse necessaria, lo fa in “automatico”.



Io apro con QGIS e salvo in csv codifica UTF8 (o system)

Dopo Via Fratelli Corvi ho trovato anche Via Don Luigi Sterzi (a 
Castelvetro Piacentino), nonchè "Strada Pane e Vino(Delib.C" (scritto 
nel record proprio così)






- La normalizzazione mi sembra agisca su preposizioni e abbreviazioni 
del nome via, purtroppo non conosco lo standard ISTAT, è sufficiente? 
Chissà perché ero convinto che andassero normalizzate anche le 
definizioni es. Via G. Garibaldi => Via Giuseppe Garibaldi, Via 
Garibaldi => Via Giuseppe Garibaldi. Sbagliavo anche qui immagino :)


Ecco, qui le cose si complicano perchè da una parte ci sono le ordinanze 
comunali (se sulla delibera hanno scritto Via G. Garibaldi), dall'altra 
il nuovo regolamento nazionale. In mezzo c'è il mappatore che mappa 
quello scritto sulla targa (a Genova ho trovato più di una strada con 3 
cartelli diversi apposti a incroci diversi in decenni diversi con 3 
scritte leggermente diverse).






Certo che si imparano un sacco di cose!
Ciao.
l.


Esatto, sto scoprendo strumenti e metodologie a me nuove. Anche questo è 
il bello della comunità collaborativa :-)


Alessandro Ale_Zena_IT


P.S.: Lorenzo, se questo w.e. vieni a Roma per MappiaM faremo un pò di 
mappatura con correzione RTK


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

Re: [Talk-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 08 lug 2016, alle ore 11:34, Lorenzo  ha 
> scritto:
> 
>> Il giorno 08 lug 2016, alle ore 11:29, Alessandro Palmas 
>>  ha scritto:
>> 
>> Il 08/07/2016 10:31, Stefano Droghetti ha scritto:
>>> 
>>> Potreste linkare questa?
>>> http://wiki.openstreetmap.org/wiki/Ferrara,_Italy/Numeri_civici
>>> Sono, molto più aggiornati di quelli dell'Emilia Romagna, del Comune di 
>>> Ferrara. Solo Comune, non Provincia.
>>> 
>> Siamo sicuri che non siano gli stessi? La regione li ha pubblicati a fine 
>> aprile. In caso di dubbio possiamo chiedere direttamente a loro.
>> Leggo dalla pagina wiki che nell'esempio si parla di civico 7a, non si era 
>> stabilito che l'esponente andasse in maiuscolo? Tra l'altro guardando a 
>> campione a Ferrara in Via Zemola trovo esponenti sia in maiuscolo che in 
>> minuscolo.
>> 
>> 
>> 
>>> Andrea Musuruane ha fatto lo script che crea lo shapefile con la 
>>> normalizzazione dei nomi e tutto l'occorrente:
>>> https://github.com/musuruan/osm_imports/tree/master/ferrara
>>> 
>> 
>> Urca, da una parte e dall'altra arrivano strumenti utili. Sarebbe il caso di 
>> creare una pagina italiana di 
>> http://wiki.openstreetmap.org/wiki/Import/Software aggiungendo link a 
>> dizionari e altro
> 
> Ora guardo le script per vedere se riesco a capirci qualcosa :)

Ciao,
a quanto pare la cosa sembra più semplice di quello che avevo immaginato usando 
gli script di Andrea, un paio di domande:

- nello script (non sono un programmatore quindi metto subito le mani avanti :) 
non vedo la conversione di encode verso UTF-8 che pensavo fosse necessaria, lo 
fa in “automatico”.

- La normalizzazione mi sembra agisca su preposizioni e abbreviazioni del nome 
via, purtroppo non conosco lo standard ISTAT, è sufficiente? Chissà perché ero 
convinto che andassero normalizzate anche le definizioni es. Via G. Garibaldi 
=> Via Giuseppe Garibaldi, Via Garibaldi => Via Giuseppe Garibaldi. Sbagliavo 
anche qui immagino :)

Certo che si imparano un sacco di cose!
Ciao.
l.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] import civici Emilia Romagna

[Andrea Musuruane]

2016-07-08 11:30 GMT+02:00 Lorenzo :

>
> Il giorno 08 lug 2016, alle ore 11:23, Andrea Musuruane <
> musur...@gmail.com> ha scritto:
>
> 2016-07-08 10:56 GMT+02:00 Lorenzo :
>
>>
>> Ciao,
>> ho iniziato a mettere su una procedura sul repo GitHub
>> https://github.com/osmItalia/civici/ volevo inserire un riferimento al
>> repo nella pagina wiki
>> http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016
>>  ma
>> non credo di essere abilitato dato che, a parte l’inserimento del mio nome
>> nella tabella in fondo, il sistema non mi permette di salvare le modifiche.
>> Qualcuno può farlo?
>> Grazie.
>>
>
> Ciao Lorenzo,
> non ho capito perché hai fatto uno script per convertire i DBF in CSV.
>
>
> Ciao Andrea,
> è il modo migliore che mi è venuto in mente per tenere ordinato il
> processo, vista anche la dimensione dei DBF (784 MB per Bologna).
> Lo script non è ancora completo devo correggere la conversione di encoding
> da
>
> https://en.wikipedia.org/wiki/Code_page_850
>
> a UTF-8 e non riesco a trovare il codice esatto della prima da dare in
> pasto a csvkit.
>
> come avresti fatto?
>

Io farei direttamente uno script in ogr2osm per trasformare i dati di
partenza in dati importabili su OSM, esattamente come ho fatto per Ferrara
(e per altri, non tutti ancora usati):
https://github.com/musuruan/osm_imports

Inoltre, se può servire come template, vi segnalo la pagina wiki che avevo
fatto per l'import dei civici di Biella:
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella

Ciao,

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

Re: [Talk-it] import civici Emilia Romagna

[Stefano Droghetti]

Il 08/07/2016 11:29, Alessandro Palmas ha scritto:
Siamo sicuri che non siano gli stessi? La regione li ha pubblicati a 
fine aprile. In caso di dubbio possiamo chiedere direttamente a loro.
Leggo dalla pagina wiki che nell'esempio si parla di civico 7a, non si 
era stabilito che l'esponente andasse in maiuscolo? 


Sono domande a cui non so rispondere con certezza. Però, dicevo, basta 
confrontare il file OSM già normalizzato ai dati della Regione che state 
importando.
Dicevo, il file è qui: 
https://drive.google.com/open?id=0B_9DH8lxMw2bRmVfQmt5cFV6RVk


Tra l'altro guardando a campione a Ferrara in Via Zemola trovo 
esponenti sia in maiuscolo che in minuscolo.

Quelli sono messi da singoli utenti, non derivano da alcun import.


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

Re: [Talk-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 08 lug 2016, alle ore 11:29, Alessandro Palmas 
>  ha scritto:
> 
> Il 08/07/2016 10:31, Stefano Droghetti ha scritto:
>> 
>> Potreste linkare questa?
>> http://wiki.openstreetmap.org/wiki/Ferrara,_Italy/Numeri_civici
>> Sono, molto più aggiornati di quelli dell'Emilia Romagna, del Comune di 
>> Ferrara. Solo Comune, non Provincia.
>> 
> Siamo sicuri che non siano gli stessi? La regione li ha pubblicati a fine 
> aprile. In caso di dubbio possiamo chiedere direttamente a loro.
> Leggo dalla pagina wiki che nell'esempio si parla di civico 7a, non si era 
> stabilito che l'esponente andasse in maiuscolo? Tra l'altro guardando a 
> campione a Ferrara in Via Zemola trovo esponenti sia in maiuscolo che in 
> minuscolo.
> 
> 
> 
>> Andrea Musuruane ha fatto lo script che crea lo shapefile con la 
>> normalizzazione dei nomi e tutto l'occorrente:
>> https://github.com/musuruan/osm_imports/tree/master/ferrara
>> 
> 
> Urca, da una parte e dall'altra arrivano strumenti utili. Sarebbe il caso di 
> creare una pagina italiana di 
> http://wiki.openstreetmap.org/wiki/Import/Software aggiungendo link a 
> dizionari e altro

Ora guardo le script per vedere se riesco a capirci qualcosa :)


> 
> 
> Il 08/07/2016 10:56, Lorenzo ha scritto:
>> 
>>> ... due shape di cui uno con un numero di civici pari a 270637 (V_NCIV_GPT) 
>>> e l'altro con meno civici 243068 (V_NCV_PROIEZ_GPT)
> 
> Dovremmo usare (V_NCIV_GPT) che rappresenta il civico o il suo punto 
> d'accesso in caso di giardino/androne/ecc.. mentre PROIEZ è la proiezione del 
> civico sull'asse stradale (vedi immagine allegata).
> Info e metadati sono disponibili a
> http://geoportale.regione.emilia-romagna.it/it/catalogo/dati-cartografici/cartografia-di-base/database-topografico-regionale/gestione-viabilita-indirizzi/toponimi-e-numeri-civici

Quello che mi preoccupa è la rilevante differenze numerica tra i civici 
presenti nei due shape.



> 
> 
> 
>> 
>> Ciao,
>> ho iniziato a mettere su una procedura sul repo GitHub 
>> https://github.com/osmItalia/civici/ volevo inserire un riferimento al repo 
>> nella pagina wiki 
>> http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016
>>  ma non credo di essere abilitato dato che, a parte l’inserimento del mio 
>> nome nella tabella in fondo, il sistema non mi permette di salvare le 
>> modifiche.
>> Qualcuno può farlo?
> 
> Se sei riuscito ad inserire il tuo nome hai diritti per editare qualsiasi 
> parte, quella è solo una tabella che ho inserito nella pagina.

No, più tardi riprovo.
Ciao.
l.

> 
> 
> Alessandro Ale_Zena_IT
> 
> ___
> 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] import civici Emilia Romagna

[Stefano Droghetti]

Io nel frattempo ho applicato gli script fatti da Andrea Musuruane alo 
shapefile di Ferrara, ed ecco il file .osm con i civici di Ferrara, già 
normalizzati:

https://drive.google.com/open?id=0B_9DH8lxMw2bRmVfQmt5cFV6RVk

Ecco cosa bisogna aggiungere prima di fare l'upload su OSM:

- aggiungere source=Comune di Ferrara a tutti i record
- aggiungere il C.A.P. riferendosi a questa mappa: 
http://www.rudybandiera.com/wp-content/uploads/2009/03/cap-ferrara.jpg 
(N.B. qualcuno ha idea di come si possa fare velocemente una cosa del 
genere? Altrimenti c'è da impazzire.)
- aggiungere il tag fixme a tutti i record, così la gente può 
controllarli pian piano uno per uno. Aggiungo comunque che quest'anno 
nei ritagli di tempo ne ho controllati tantissimi e andavano tutti bene.


Una volta fatto ciò, penso che questo dataset sia più aggiornato di 
quello della regione Emilia-Romagna, quindi sia meglio, per il Comune di 
Ferrara, utilizzare questo invece di quello che state importando.


Inoltre: per Bologna, i numeri civici ci sono già. E da tempo. Questo 
dataset è più aggiornato o lasciamo quello che c'è già (che mi pare 
dettagliatissimo e aggiornatissimo)?


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

Re: [Talk-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 08 lug 2016, alle ore 11:23, Andrea Musuruane  
> ha scritto:
> 
> 2016-07-08 10:56 GMT+02:00 Lorenzo  >:
> 
> Ciao,
> ho iniziato a mettere su una procedura sul repo GitHub 
> https://github.com/osmItalia/civici/  
> volevo inserire un riferimento al repo nella pagina wiki 
> http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016
>  
> 
>  ma non credo di essere abilitato dato che, a parte l’inserimento del mio 
> nome nella tabella in fondo, il sistema non mi permette di salvare le 
> modifiche.
> Qualcuno può farlo?
> Grazie.
> 
> Ciao Lorenzo,
> non ho capito perché hai fatto uno script per convertire i DBF in CSV. 

Ciao Andrea,
è il modo migliore che mi è venuto in mente per tenere ordinato il processo, 
vista anche la dimensione dei DBF (784 MB per Bologna).
Lo script non è ancora completo devo correggere la conversione di encoding da 

https://en.wikipedia.org/wiki/Code_page_850 


a UTF-8 e non riesco a trovare il codice esatto della prima da dare in pasto a 
csvkit.

come avresti fatto?
Ciao.
l.




> 
> Ciao,
> 
> Andrea
>  
> ___
> 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] import civici Emilia Romagna

[Alessandro Palmas]

Il 08/07/2016 10:31, Stefano Droghetti ha scritto:


Potreste linkare questa?
http://wiki.openstreetmap.org/wiki/Ferrara,_Italy/Numeri_civici
Sono, molto più aggiornati di quelli dell'Emilia Romagna, del Comune 
di Ferrara. Solo Comune, non Provincia.


Siamo sicuri che non siano gli stessi? La regione li ha pubblicati a 
fine aprile. In caso di dubbio possiamo chiedere direttamente a loro.
Leggo dalla pagina wiki che nell'esempio si parla di civico 7a, non si 
era stabilito che l'esponente andasse in maiuscolo? Tra l'altro 
guardando a campione a Ferrara in Via Zemola trovo esponenti sia in 
maiuscolo che in minuscolo.




Andrea Musuruane ha fatto lo script che crea lo shapefile con la 
normalizzazione dei nomi e tutto l'occorrente:

https://github.com/musuruan/osm_imports/tree/master/ferrara



Urca, da una parte e dall'altra arrivano strumenti utili. Sarebbe il 
caso di creare una pagina italiana di 
http://wiki.openstreetmap.org/wiki/Import/Software aggiungendo link a 
dizionari e altro



Il 08/07/2016 10:56, Lorenzo ha scritto:


... due shape di cui uno con un numero di civici pari a 270637 
(V_NCIV_GPT) e l'altro con meno civici 243068 (V_NCV_PROIEZ_GPT)


Dovremmo usare (V_NCIV_GPT) che rappresenta il civico o il suo punto 
d'accesso in caso di giardino/androne/ecc.. mentre PROIEZ è la 
proiezione del civico sull'asse stradale (vedi immagine allegata).

Info e metadati sono disponibili a
http://geoportale.regione.emilia-romagna.it/it/catalogo/dati-cartografici/cartografia-di-base/database-topografico-regionale/gestione-viabilita-indirizzi/toponimi-e-numeri-civici





Ciao,
ho iniziato a mettere su una procedura sul repo GitHub 
https://github.com/osmItalia/civici/ volevo inserire un riferimento al 
repo nella pagina wiki 
http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016 ma 
non credo di essere abilitato dato che, a parte l’inserimento del mio 
nome nella tabella in fondo, il sistema non mi permette di salvare le 
modifiche.

Qualcuno può farlo?


Se sei riuscito ad inserire il tuo nome hai diritti per editare 
qualsiasi parte, quella è solo una tabella che ho inserito nella pagina.



Alessandro Ale_Zena_IT

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

Re: [Talk-it] import civici Emilia Romagna

[Andrea Musuruane]

2016-07-08 10:56 GMT+02:00 Lorenzo :

>
> Ciao,
> ho iniziato a mettere su una procedura sul repo GitHub
> https://github.com/osmItalia/civici/ volevo inserire un riferimento al
> repo nella pagina wiki
> http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016
>  ma
> non credo di essere abilitato dato che, a parte l’inserimento del mio nome
> nella tabella in fondo, il sistema non mi permette di salvare le modifiche.
> Qualcuno può farlo?
> Grazie.
>

Ciao Lorenzo,
non ho capito perché hai fatto uno script per convertire i DBF in CSV.

Ciao,

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

Re: [Talk-it] import civici Emilia Romagna

[Lorenzo]

> Il giorno 07 lug 2016, alle ore 20:57, Lorenzo Perone 
>  ha scritto:
> 
> Ciao Stefano,
> vorremmo procedere all'import dei civici rilasciati dalla regione in OSM.
> Ho scaricato il pacchetto con gli shape file della provincia di Bologna ed ho 
> trovato due shape di cui uno con un numero di civici pari a 270637 
> (V_NCIV_GPT) e l'altro con meno civici 243068 (V_NCV_PROIEZ_GPT) ci sono poi 
> un paio di dbf che sembrano contenere una correlazione tra diversi UUID.
> Ti chiedevo se esistono dei metadati specifici sul contenuto degli shape file 
> per poter capire bene quali utilizzare.
> Grazie.
> l.
> 
> Lorenzo Perone
> twitter: @lorenzo_perone 
> photoblog: http://immagini.me
>  
Ciao,
ho iniziato a mettere su una procedura sul repo GitHub 
https://github.com/osmItalia/civici/  
volevo inserire un riferimento al repo nella pagina wiki 
http://wiki.openstreetmap.org/w/index.php?title=IT:Emilia_Romagna_import_numeri_civici_2016
 

 ma non credo di essere abilitato dato che, a parte l’inserimento del mio nome 
nella tabella in fondo, il sistema non mi permette di salvare le modifiche.
Qualcuno può farlo?
Grazie.
l.

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

Re: [Talk-it] import civici Emilia Romagna

[Stefano Droghetti]

Il 07/07/2016 20:34, Lorenzo Perone ha scritto:



Ciao Lorenzo,
per ora stavo cercando di capire dove aprire la pagina wiki per
documentare e coordinare l'import. Ho appena creato la pagina

http://wiki.openstreetmap.org/wiki/IT:Emilia_Romagna_import_numeri_civici_2016
, sarà da linkare sulla pagina principale della wiki regionale. E'
giusto
una bozza.



Potreste linkare questa?
http://wiki.openstreetmap.org/wiki/Ferrara,_Italy/Numeri_civici
Sono, molto più aggiornati di quelli dell'Emilia Romagna, del Comune di 
Ferrara. Solo Comune, non Provincia.


Andrea Musuruane ha fatto lo script che crea lo shapefile con la 
normalizzazione dei nomi e tutto l'occorrente:

https://github.com/musuruan/osm_imports/tree/master/ferrara

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

Re: [Talk-us] Common names of highways do not match road signs.

[Paul Johnson]

On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan 
wrote:

> It is confusing to use open street maps in my area(Central Ohio) for
> driving directions since the "common names" of high ways do not match
> road signs. The common names are used by open map chest for road names.
> For example when turning on to State Route 315 with OpenMapChest loaded
> on my GPS I am directed to turn on to Olentangy Freeway. However the
> tiger name on open street maps is State route 315. Would it make more
> sense to configure driving maps to use tiger names for driving
> directions,  change commons names to include the state route number or
> interstate number, or add state route number/ interstate number as a
> different tag?
>

ref=* isn't name=*, don't tag for the renderer.  I'd go with the official
name for name=*.  If you're inclined to do something like, name=State Route
315, you really want ref=OH 315.   Not all highways with refs will have
names, not all highways with names have refs.  In particularly remote
areas, it's not uncommon for a road to not have a name or a ref.
Conversely, there's highways that might have eight or nine refs and
multiple names.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Common names of highways do not match road signs.

[Kevin Morgan]

It is confusing to use open street maps in my area(Central Ohio) for
driving directions since the "common names" of high ways do not match
road signs. The common names are used by open map chest for road names. 
For example when turning on to State Route 315 with OpenMapChest loaded
on my GPS I am directed to turn on to Olentangy Freeway. However the
tiger name on open street maps is State route 315. Would it make more
sense to configure driving maps to use tiger names for driving
directions,  change commons names to include the state route number or
interstate number, or add state route number/ interstate number as a
different tag?  

-- 
  Kevin Morgan
  morgankev...@fastmail.fm

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