date:20140429



Am 29.04.2014 18:56, schrieb Luis Villa:
.
 
 Without commenting on/endorsing Alex's position, suffice to say that the
 vast majority of lawyers I've talked with about the license, including
 many with long experience in open software licenses, find the license
 difficult to interpret. This is not entirely ODBL's fault - for example,
 underlying concepts, like substantial, are essentially undefined in
 the caselaw, making it difficult to interpret what those clauses mean.
 (Compare with some equivalent clauses about derivative works in
 copyright licenses, which can rely on 100 years of caselaw as
 background.) But it is a reality that slows, or in some cases stops,
 adoption of/contribution to OSM.


Luis, first: thanks for the feedback.

I think it is quite clear that the ODbL isn't and likely never will be,
backed up by anything near as much case law as we have in conventional
copyright. But there was not really a choice, both on the one hand in
trying to level the playing ground between different handling of IPR wrt
databases and and on the other hand retaining the basic concept of share
alike. The subject matter is complicated and it is difficult to see how
it could have been done much simpler.

To make it clear: there would likely be no, at least no thriving, OSM
project now without SA being retained. Not for legal reasons, but simply
because the community would have exploded in SA vs. non-SA fights and
burnt out. It was bad enough as is, and one way of looking at the ODbL
is simply as the compromise that was necessary to keep OSM alive.
Compromises tend to leave everybody being a bit unhappy, so moaning is
to be expected.

Further versions of the ODbL with improvements are possible and maybe
one day a licence change if there is a clear preference in the community
for that.

 
 
 I am responding in small parts in the wiki[1], and in larger part in an
 upcoming email. I would not take lack of response on a single mailing
 list as a useful indicator of whether or not there are real issues or
 concerns, especially since most lawyers who would be aware of problems
 would be extremely reluctant to comment publicly on something that might
 impact their clients.

Most of the audience here are simply contributors that are somewhat
interested in legal and licence matters. I suspect some simply forgot to
un-subscribe after the licence change :-).  As a consequence I don't
think we are primarily looking for professional feedback on the
guidelines here, naturally it is very welcome and helpful when provided.

Airing the guidelines here is in any case just the foreplay before they
get ripped apart by a bigger audience.

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



Just a reminder, this thread started of with a discussion of
attribution, or rather lack of such. I don't think there is very much
doubt about what the licence requires even given all the complexity of
the ODbL, for a produced work it is:

However, if you Publicly Use a Produced Work, You must include a notice
associated with the Produced Work reasonably calculated to make any
Person that uses, views, accesses, interacts with, or is otherwise
exposed to the Produced Work aware that Content was obtained from the
Database,

Our suggested attribution text is already very minimal. It is not clear
to me what reasonable objections exist against simply attributing OSM as
we require.

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] Guideline review: Substantial

2014-04-29 Diskussionsfäden Paul Norman

 From: Luis Villa [mailto:lvi...@wikimedia.org] 
 Sent: Tuesday, April 29, 2014 3:10 PM
 To: Licensing and other legal discussions.
 Subject: Re: [OSM-legal-talk] Guideline review: Substantial

 Reminder that Simon has pointed out here quite recently that ODBL claims 
 to be a binding contract that can apply when no license is necessary.

So, there's two cases here. One is in Europe. You might have trouble 
enforcing a contract which restricts you from acts permitted in the 
directive. I'm not sure of this interpretation, but won't further 
consider it because the point is moot, since 6.0 explicitly says that 
the ODbL doesn't restrict the rights you have under the exceptions to 
the database right. 

The other more complicated one is outside Europe, where you'd be looking 
at the ODbL as a copyright license or contract. In that case, we still 
want the guideline to be in harmony with the database directive for a 
few reasons 

1. The ODbL defines the terms with the same text as the database 
directive and directly references the EC directive. 

2. Different definitions of substantial would result in different 
allowable actions depending on where you are. To some extent this is 
going to happen anyways, but if we can avoid additional cases that's 
good. 

3. Europe is probably the only place where the courts have considered 
the definitions of substantial and insubstantial used in the ODbL. 

4. I find it's generally easiest to look at the ODbL as a license 
database right, rather than a license of copyright or a contract 

 This strongly suggests that a European court would evaluate 
 substantial in the quantitative sense with regards to the entire 2B 
 records in OSM, not with regards to the database the information was put 
 into. It would be interesting to see what courts around Europe are 
 finding as substantial in this sense; I see one reference to a French 
 court that found that taking 15% was not quantitatively substantial, and 
 the GRADE paper linked to from the wiki suggests it would have to be 50%.
 But I suspect this would vary a lot based on the facts of the case, 
 and that a skilled lawyer could raise or lower the number. And of course 
 in the case of a database as large as OSM a court might try to change 
 their mind. 

OSM has ~250M features. The difference from 2B is for technical reasons 
to do with the data model. Seeing the percentages that are being used 
for substantial, I think anything that is quantatively substantial will 
be qualitatively substantial. 

I also suspect that OSM has two key differences from anything else 
considered. One is the size and worldwide scope - Great Britain is ~2% 
of the planet-wide data, but anyone trying to work with all of Great 
Britain is hardly likely to not consider it substantial. 

Another is applicability to database of geographic information. I'd 
defer to someone who's more familiar with them, but I believe the 
Ordinance Survey treats *much* smaller extracts of their data as 
substantial. 

 For qualitative, the key passage of BHB is:
  [S]ubstantial part, evaluated qualitatively, of the contents of a 
  database refers to the scale of the investment in the obtaining, 
  verification or presentation of the contents of the subject of the act 
  of extraction and/or re-utilisation, regardless of whether that subject 
  represents a quantitatively substantial part of the general contents of 
  the protected database. A quantitatively negligible part of the contents 
  of a database may in fact represent, in terms of obtaining, verification 
  or presentation, significant human, technical or financial investment. 
 (Para 71) 

 In other words, a small chunk of a large database can be qualitatively 
 substantial if the cost of obtaining, verification, or presentation of 
 that small chunk was substantial. The court goes on to say that it 
 doesn't matter if the small chunk is, by itself, valuable - what matter 
 is the work done to put it into the database. What qualifies as a 
 substantive investment is left as an exercise for the lower courts. 
 (One German case I've found seemed to presume that 39,000 Euro was a 
 substantive investment, but that was not the primary point being argued 
 in that case so I wouldn't rely on the number being that low.) 

Putting BHB into an OSM context, what seems to matter is mapping effort. 
That makes sense - 100 detailed POIs are worth more than 100 points with 
only building=yes. Of course mapping effort is harder to measure...

 Some pretty decent summaries of BHB and other relevant caselaw, FYI:
Thanks for the links - they're on my to-read list.

 Few other comments:
 * It might be helpful to link to 
 http://wiki.openstreetmap.org/wiki/Map_features 
   when talking about Features, assuming those are the same concept,
   which I admit I'm still not 100% sure about?

It's a data model issue. OSM's data model is designed for crowd-sourced 
editing, and polygons are composed of multiple elements.

Re: [OSM-talk] Invisible character LRM in some website values

2014-04-29 Diskussionsfäden Bryce Nesbitt

Keepright and/or Maproulette are fine tools for crowfixing such things.
Keepright is probably already picking them up, at it loads website tags and
matches them to the other tags in the same OSM primitive.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Invisible character LRM in some website values

2014-04-29 Diskussionsfäden Glenn Plas


On 29-04-14 04:33, John Packer wrote:

Today I found out a /funny/ thing.
It seems some values for the keys 'website' and 'contact:website' have 
a LRM character at it's end.

That's not something good because it corrupts the URL. (example)

On taginfo: http://taginfo.openstreetmap.org/search?q=website%3D%E2%80%8E
Example of an overpass to find this: http://overpass-turbo.eu/s/3bW

I manually fixed these things on Brazil, could someone fix this on the 
rest of the world?


I tried fixing some in Josm, and I can confirm the LRM char is in the 
URL, but to make josm realise that there was a change I had to had a 
note tag, josm doesn't account for those special chars to determine 
changes and allow an upload.


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

Re: [OSM-talk] Invisible character LRM in some website values

2014-04-29 Diskussionsfäden Glenn Plas



I tried fixing some in Josm, and I can confirm the LRM char is in the 
URL, but to make josm realise that there was a change I had to had a 
note tag, josm doesn't account for those special chars to determine 
changes and allow an upload.


I opened a ticket with JOSM in this regard as it's not seeing the 
differences.  see  https://josm.openstreetmap.de/ticket/9960


Glenn

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

[OSM-talk] Fwd: Invisible character LRM in some website values

2014-04-29 Diskussionsfäden John Packer

Bryce,

As far as I know, Keepright will simply flag this as an invalid/dead
website, which might mislead people into removing perfectly fine websites
that were corrupted by this character.

Glenn,
In my case, JOSM noticed the difference and uploaded the changes. I am
using JOSM 7000 on Linux. (though it seems there was a node that wasn't
corrected; but I am not sure whether I failed to correct it or JOSM didn't
perceive it).


Em 29/04/2014 07:11, Glenn Plas gl...@byte-consult.be escreveu:


  I tried fixing some in Josm, and I can confirm the LRM char is in the
 URL, but to make josm realise that there was a change I had to had a note
 tag, josm doesn't account for those special chars to determine changes and
 allow an upload.


 I opened a ticket with JOSM in this regard as it's not seeing the
 differences.  see  https://josm.openstreetmap.de/ticket/9960

 Glenn

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

[OSM-talk] Menufy.com added hundrets of stores with payment:bitcoin=yes, which don't accept Bitcoin

2014-04-29 Diskussionsfäden Andreas Goss

I just stumbled over 
http://www.reddit.com/r/Bitcoin/comments/24b22n/bitmap_app_cointerestorg_openstreetmapcom/


So far it looks like menufy.com or someone else has been adding hundrets 
of restaurants with payment:bitcoin=yes to OpenStreetMap, even though 
most of those restaurants do NOT accept Bitcoin at their physical location.


This is the user account: http://www.openstreetmap.org/user/Blobo123

It sometimes refer to this
http://www.coindesk.com/menufy-now-supports-bitcoin-payments-400-us-restaurants/ 
which even states: The proprietors might not even be aware that they 
are accepting bitcoin payments.


It would be great if someone with more experiance could look into this, 
especially as a revert is probably needed at least for the 
Bitcoin-payment tag.


Andi
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [OSM-talk] Menufy.com added hundrets of stores with payment:bitcoin=yes, which don't accept Bitcoin

2014-04-29 Diskussionsfäden Alexandre Magno Brito de Medeiros

I would be less concerned about the bitcoin aspect of it, but given that
the user is adding further information which is quite useful, it should
be clear if he actually has permission to do so (and a valid source tag
would be a good idea too).

Simon

Am 30.04.2014 00:17, schrieb Andreas Goss:
 I just stumbled over
 http://www.reddit.com/r/Bitcoin/comments/24b22n/bitmap_app_cointerestorg_openstreetmapcom/
 
 
 So far it looks like menufy.com or someone else has been adding hundrets
 of restaurants with payment:bitcoin=yes to OpenStreetMap, even though
 most of those restaurants do NOT accept Bitcoin at their physical location.
 
 This is the user account: http://www.openstreetmap.org/user/Blobo123
 
 It sometimes refer to this
 http://www.coindesk.com/menufy-now-supports-bitcoin-payments-400-us-restaurants/
 which even states: The proprietors might not even be aware that they
 are accepting bitcoin payments.
 
 It would be great if someone with more experiance could look into this,
 especially as a revert is probably needed at least for the
 Bitcoin-payment tag.
 
 Andi
 __
 openstreetmap.org/user/AndiG88
 wiki.openstreetmap.org/wiki/User:AndiG88‎
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk] Menufy.com added hundrets of stores with payment:bitcoin=yes, which don't accept Bitcoin

2014-04-29 Diskussionsfäden Andreas Goss


Am 4/30/14 01:18 , schrieb Simon Poole:

I would be less concerned about the bitcoin aspect of it


I think that is a pretty important aspect considering that CoinMap seems 
to be pretty popular in the Bitcoin community. But if users end up going 
to restaurants where they can't pay with Bitcoin and the owner does not 
even know what Bitcoins are they are going to be get frustrated and use 
alternative services. Which then also means that there is less 
initiative for business owners accepting Bitcoin to make sure they are 
(correctly) listed on OpenStreetMap.


Considering CoinMap has 4000+ listing (according to some recent 
articles) then 700 wrong listings are a significant amount of bad data 
(assuming most of the stores do indeed not accept Bitcoin at they 
physical location).


Andi

PS: I honestly didn't even consider the overall legal aspect of this.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [OSM-talk] Menufy.com added hundrets of stores with payment:bitcoin=yes, which don't accept Bitcoin

2014-04-29 Diskussionsfäden Yves

Then the bitcoin aspect is more a tagging issue: they accept bitcoin through 
menufy.com only.


On 30 avril 2014 02:03:00 UTC+02:00, Andreas Goss andi...@t-online.de wrote:
Am 4/30/14 01:18 , schrieb Simon Poole:
 I would be less concerned about the bitcoin aspect of it

I think that is a pretty important aspect considering that CoinMap
seems 
to be pretty popular in the Bitcoin community. But if users end up
going 
to restaurants where they can't pay with Bitcoin and the owner does not

even know what Bitcoins are they are going to be get frustrated and use

alternative services. Which then also means that there is less 
initiative for business owners accepting Bitcoin to make sure they are 
(correctly) listed on OpenStreetMap.

Considering CoinMap has 4000+ listing (according to some recent 
articles) then 700 wrong listings are a significant amount of bad data 
(assuming most of the stores do indeed not accept Bitcoin at they 
physical location).

Andi

PS: I honestly didn't even consider the overall legal aspect of this.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

-- 
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Wither Sydney suburb boundaries?

2014-04-29 Diskussionsfäden Michael Gratton




On Tue, 29 Apr, 2014 at 11:02 AM, Alex Sims a...@softgrow.com wrote:


On 28 Apr 2014, at 1:53 pm, Michael Gratton m...@vee.net wrote:

On a related note, what's the appropriate way to map suburb-sized 
areas that are partitions? A way for each suburb that share nodes 
along common borders, a way for each suburb that don't duplicate 
nodes along common borders, or using a single way for the border and 
using a relation?


I might express and opinion about suburb mapping as I’ve done a 
fair bit of “mapping for the validator” which I suppose is not 
evil, unlike mapping for the renderer.


I’d prefer relations that depend on single ways, this avoids JOSM 
complaining too much about duplicate ways and can also tie into the 
definition in words that might belong in Wikipedia.


This (and Ian's) sounded like pretty good advice, so I have uploaded a 
boundary for Randwick based on Andrew's OSM version of the ABS 
SSC_2011_AUST, checked and manually adjusted by eyeballing Bing vs SIX 
and the Council's PDF map, and simplified by hand.


The changeset is here: 
http://www.openstreetmap.org/changeset/22023461, does anyone have any 
comments about how it could be improved?


I noticed that as for many suburbs in SA, since I replaced the 
place=suburb node previously used the name of the suburb is no longer 
rendered. What's best practice here, do we really want to different 
entities with the same name?


//Mike




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

Re: [talk-au] Wither Sydney suburb boundaries?

2014-04-29 Diskussionsfäden Ben Kelley

Hi.

I seem to remember there is a way to add the node to a relation so that it
marks where the name should go for the boundary.

   - Ben.

On Apr 30, 2014 12:11 AM, Michael Gratton m...@vee.net wrote:


 I noticed that as for many suburbs in SA, since I replaced the
place=suburb node previously used the name of the suburb is no longer
rendered. What's best practice here, do we really want to different
entities with the same name?

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

Re: [talk-au] Wither Sydney suburb boundaries?

2014-04-29 Diskussionsfäden Ian Sergeant

Admin_centre. 

 On 30 Apr 2014, at 6:11 am, Ben Kelley ben.kel...@gmail.com wrote:
 
 Hi.
 
 I seem to remember there is a way to add the node to a relation so that it 
 marks where the name should go for the boundary.
 
- Ben
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Wither Sydney suburb boundaries?

2014-04-29 Diskussionsfäden Ben Kelley

Thanks Ian. :-)
On Apr 30, 2014 7:31 AM, Ian Sergeant ina...@gmail.com wrote:

 Admin_centre.

 On 30 Apr 2014, at 6:11 am, Ben Kelley ben.kel...@gmail.com wrote:

 Hi.

 I seem to remember there is a way to add the node to a relation so that it
 marks where the name should go for the boundary.

- Ben


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

Re: [Talk-br] onosm.org

Fórum  users: Brazil 
osmbrazil.zapto.orghttp://forum.openstreetmap.org/viewtopic.php?pid=416552#p416552--
serviço no ar! (mas não divulgado, como sugerido)


Em 27 de abril de 2014 09:57, Alexandre Magno Brito de Medeiros 
alexandre@gmail.com escreveu:

 Quando chegar a hora nós discutimos isso. Mas com certeza essas suas são
 sugestões interessantes. Eu penso em algo como um cartão de visitas
 (gráfico) que na realidade é o tal convite. Mas tem de ser econômico. Daí
 eu saiu de bicicleta distribuindo e vou pra casa esperar as Notes.

 Alexandre Magno


 Em 27 de abril de 2014 09:44, Paulo Carvalho paulo.r.m.carva...@gmail.com
  escreveu:

 Eu colocaria Coloque sua empresa no mapa (internet fica muito genérico),
 com sub-título Gratuitamente, no mapa que mais cresce no mundo você
 aparece nas buscas com chances iguais.  Aludindo ao fato do Google
 enviesar as buscas para os que pagam mais ou dão mais audiência.  Ou algo
 desse gênero.



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

[Talk-de] Fwd: [talk-ch] OSM Mappers and developpers invited to the Randa Meetings 2014



We (as in SOSM) have been approached by the organizers of the 2014 Randa
Meeting if OSM developers would like to participate. I think this would
be a good opportunity to work on some larger projects together, one that
cam to mind was OWL, but there are sure to be others.

If there are people from OSM attending I would try and see if the OSMF
could cover some of the costs (aka the accommodation).

Simon


 Original-Nachricht 


Dear all
Randa [1] is a small and beautiful village in the Swiss Alps just two
train stops away from Zermatt with its world famous Matterhorn! The next
Randa Meetings take place from Saturday, 9th to Friday, 15th of August
2014. The association Randa Meetings lead by Mario Fux organises the 5th
Hacking Meeting already.

What are these Randa Meetings?
The goal of the Randa Meetings is to bring groups and people from the
global free software, open source and open data community together for
one week in a nice place to discuss, work and hack on the next big (or
small) thing. Due to its origin so far mainly the KDE community has
participated and we have hosted as much as 50 developers (the house has
a capacity of approx. 100) [2].

The organisers of Randa Meetings provide the place and basic services
such as food, drinks and accommodation (not for free but for a very low
price, see below), meeting rooms and the probably nicest view you can
have for a (developer) meeting. The content comes from the participants.
So you can come with your group and discuss, map or hack on whatever is
important to you.

So do you have a project you are working on within the OSM community?
Bring your people to Randa in August and you will most probably have a
boost for the project. The past meetings have shown that the great
atmosphere and the peaceful surroundings are very positive for the
productivity and focused work. And you can come for just a day or two or
the whole week. It's totally up to you.

Family and friends are welcome, too!
Randa is great also for your family. There are a lot of opportunities
for hiking, mountain biking or just enjoying yourself in a great
panorama. This year we know already from a few bringing their kids along
with them.

What does it cost me?
The accommodation is approx. 20 CHF/person and night (+/-5 CHF) and also
depending on how much sponsoring we can obtain. Family members have to
pay for themself (no sponsored stays).
Food (full board) is provided at 15 CHF/person and day.
Travel expenses are to be covered by the participants. For international
participants on low budget we can provide a special fare train ticket on
request (limited availability).

Interested? Get in contact with us! Pascal Mages (pascal.ma...@sosm.ch)
or Mario Fux (f...@kde.org).
For further information visit http://randa-meetings.ch/

Looking forward to see you in Randa!
Pascal  Mario

[1] http://www.openstreetmap.org/#map=14/46.0999/7.7652
[2] http://community.kde.org/Sprints/Randa


-- 
e-mail signed with CAcert certificate (www.cacert.org)



___
talk-ch mailing list
talk...@openstreetmap.ch
http://lists.openstreetmap.ch/mailman/listinfo/talk-ch



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

[Talk-de] Wochennotiz Nr. 197 22.4.-28.4.2014

2014-04-29 Diskussionsfäden wn reader


Hallo,

die Wochennotiz Nr. 197 mit allen wichtigen Neuigkeiten aus der 
OpenStreetMap Welt ist da:


http://blog.openstreetmap.de/blog/2014/04/wochennotiz-nr-197/

Viel Spaß beim Lesen!

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

[Talk-de] XML von einem Objekt exportieren

2014-04-29 Diskussionsfäden Markus


Wie kann ich von einem Objekt (ID bekannt)
die Daten exportieren?
(so dass ich sie mit einem Texteditor lesen kann)

Mit herzlichem Gruss,
Markus

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

Re: [Talk-de] XML von einem Objekt exportieren

2014-04-29 Diskussionsfäden Ralf GESELLENSETTER

Am 29.04.2014 19:07, schrieb Markus:
 Wie kann ich von einem Objekt (ID bekannt)
 die Daten exportieren?

Spontane Idee: Objekt in JOSM in eine neue
Ebene kopieren, diese als OSM speicher. Feritg.

-- 
PGP/GnuPG: pub 1024D/E6DE0971

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

Re: [Talk-de] LKW Mautinformationen

2014-04-29 Diskussionsfäden Klaus-Geo


This post has NOT been accepted by the mailing list yet.
Hallo Zusammen,

ich wollte mal in der Runde fragen, ob man vllt. das LKW-Maut-Tagging
überarbeiten könnte? Diesbzügl. auch eine internationale
Kartierungsvorschrift festlegen könnte!

Ich will demnächst eine Bachelorarbeit zum Thema LKW-Maut anfangen und hatte
mir vorher gedanken gemacht, ob man das Tagging optimieren könnte.

Aktuell:

toll=yes — Mautpflichtige Straße
toll:hgv=yes — Schwerlastwagen, die Güter oder Produkte transportieren
(siehe Heavy_goods_vehicle, allgemeine Definition für HGV)
toll:N3=yes — Für LKW mit einem zulässigen Gesamtgewicht  12 t
mautpflichtige Straße (bsp. Commercial Truck).
https://wiki.openstreetmap.org/wiki/DE:Key:toll (siehe Large goods vehicle,
entspricht der LKW-Mautpflicht in Deutschland)

Das wäre meine Vorschläge:

1. Vorschlag:

toll:N1=yes — Für Fahrzeuge mit einer zulässigen Gesamtmasse von nicht mehr
als 3,5 Tonnen eingesetzt, bsp. Pick-up-Truck. (siehe Europäische
Fahrzeugklassifikation N1)

toll:N2=yes —Für Fahrzeuge mit einer zulässigen Gesamtmasse von mehr als 3,5
Tonnen bis zu 12 Tonnen eingesetzt, bsp. Commercial Truck. (siehe
Europäische Fahrzeugklassifikation N2)

toll:name = Anschlussnamen für ein späteres Routing (Name kommt von der
Mauttabelle)


2. Vorschlag im Zuge der PKW-Maut-Einführung:

Auszug aus Wiki: The EU general classification of vehicle categories is:
http://en.wikipedia.org/wiki/Directive_2001/116/EC

   Motor vehicles with at least four wheels:
   Category M: used for the carriage of passengers
   Category M1: no more than eight seats in addition to the driver
seat
   more than eight seats in addition to the driver seat:
   Category M2: having a maximum mass not exceeding 5 tonnes
(11,000 lb)
   Category M3: having a maximum mass exceeding 5 tonnes
   Category N: used for the carriage of goods
   Category N1: having a maximum mass not exceeding 3.5 tonnes
(7,700 lb)
   Category N2: having a maximum mass exceeding 3.5 tonnes but not
exceeding 12 tonnes (26,000 lb)
   Category N3: having a maximum mass exceeding 12 tonnes
   Category O: trailers (including semi-trailers)
   Category O1: maximum mass not exceeding 0.75 tonnes (1,700 lb)
   Category O2: exceeding 0.75 tonnes but not exceeding 3.5 tonnes
(7,700 lb)
   Category O3: exceeding 3.5 tonnes but not exceeding 10 tonnes (22,000
lb)
   Category O4: exceeding 10 tonnes
   Symbol G: off-road vehicles
   Special purpose vehicles

PKW-Maut

toll:=yes

toll:class= L1, L2, M

LKW-Maut

toll:hgv=yes

toll:hgv:class=N1, N2, N3

Mautnamen für Anschlussstellenbezeichnung

toll:name= Name des Mautknotens — Anlehnung an die Mauttabelle der Bast,
den der reale AS-Name unterscheidet sich mit dem Mautknoten-Name. (für
spätere Routing?)

toll:operator= Betreiber der Mautstrecke — Wer betreibt die Mautstrecke,
bsp. Toll Collect.

Mautnamen: Diese Namen kommen von der Mauttabelle, die die Bast 3mal im Jahr
veröffentlicht. Die Namen weichen vom realen Anschlussnamen ab. Dies könnte
später für ein OSM-Routing interessant sein.

Ich denke, dass in anderen europäischen Staaten ( Polen, Österreich,
Frankreich (Zukunft), ...) bald eine Abschnittsbezogene Mautgebühr erhoben
werden könnte. Und deshalb überlege ich, dass Tagging ein weinig zu
optimieren und zu vereinfachen.

Was ist eure Meinungen oder Anmerkungen?

Gruß,
Klaus 



--
View this message in context: 
http://gis.19327.n5.nabble.com/LKW-Mautinformationen-tp5717981p5804596.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] XML von einem Objekt exportieren

2014-04-29 Diskussionsfäden Peter Körner


Hi

Am 29.04.2014 19:07, schrieb Markus:

Wie kann ich von einem Objekt (ID bekannt)
die Daten exportieren?
(so dass ich sie mit einem Texteditor lesen kann)


Auf http://www.openstreetmap.org/way/24774635 und vgl. Seiten gibt's 
unten einen XML herunterladen-Link.


Lg

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

[Talk-de] Mapnik nicht für MOB AC und Oruxmap

2014-04-29 Diskussionsfäden tshrub


Hi,

ich habe schon Mal geguugelt: es scheint sich in den letzten Monaten ein 
Problem bei der Verbreitung des OSM-Mapnik-Layouts ergeben zu haben?
In meinem alten Orux (Androis-App) und im MOB AC (zum tiles 
runterladen) komme ich nicht mehr an die original Mapnik-tiles (nur das 
default-tile: rotes Kreuz, Sanduhr etc. ).

Ich wollte grad Mal ein paar meiner Daten nutzen, aber Pustekuchen:
es gibt nur Stoff aus anderen Renderern ... :(
Kennt jemand ggf. eine Möglichkeit, Mapnik in o.g. wieder nutzen zu können?

t.


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

[Talk-it] R: TOWN VILLAGE

Quindi riassumendo:  - possono essere entrambi modelli di mappatura corretti

Personalmente propendo per il modello capoluogo di comune come TOWN e frazioni 
come VILLAGE
ANCHE perché
nella visualizzazione della mappa -  da ingrandimento 9 – compaiono i 
capoluoghi di comune e le frazioni con caratteri di dimensione diversa che 
individuano chiaramente e visivamente “le caratteristiche dei place”.
E trovo che sia un aiuto visuale ed ergonomico formidabile alla consultazione 
della mappa. Ovvero una sua fruibilità.

Infine una piccola polemica:
ma con tutto quello che c’è da mappare, perché accanirsi sulla modifica di tag 
che non sono formalmente scorretti?

Saluti
Beppe



Da: Andrea Musuruane [mailto:musur...@gmail.com] 
Inviato: lunedì 28 aprile 2014 21:46
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] TOWN  VILLAGE

 

L'utente che ha cambiato i tag sono io e l'ho fatto in seguito alla discussione 
che abbiamo fatto qui sui comuni della provincia di Parma.

Ciao, 

Andrea

Il 28/apr/2014 19:34 Giuseppe Amici giuseppeam...@virgilio.it ha scritto:

 

 

Ho da sempre mappato il capoluogo comunale come tag:place=town 

e le località del comune individuate come frazioni con il tag:place=village.

Il wiki fa una distinzione per numero di abitanti:
http://wiki.openstreetmap.org/wiki/Village

che non è supportato dalla normativa italiana in materia, ovvero:
il decreto legislativo 18/8/2000, n.267, Testo Unico delle leggi 
sull'ordinamento degli Enti Locali (TUEL), all'art.18 testualmente recita: 

Art. 18. Titolo di città 
Il titolo di città può essere concesso con decreto del Presidente della 
Repubblica su proposta del Ministro dell'interno ai comuni insigni per ricordi, 
monumenti storici e per l'attuale importanza. 

Rimane il fatto della traduzione sia “Citta” che “Paese” hanno una corretta 
traduzione in “TOWN”
Mentre anche JOSM propone nelle sue “feature”: frazione come village.

Come dirimere la questione con un utente che pedissequamente cambia i miei tag?


Saluti
Beppe


___
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] wtosm

2014-04-29 Diskussionsfäden Luca Delucchi

2014-04-28 22:28 GMT+02:00 Simone F. grop...@gmail.com:


 Il codice di Cristian richiedeva pyspatialite ma avevo trovato il modo di
 sostituirlo con pysqlite2.
 Avevo creato un test per controllare se la soluzione funzionava anche sul
 server fmach.
 Cerca un mio messaggio con:
 Ricapitolando: il test serve per vedere se puoi usare pysqlite2 al posto di
 pyspatialite


ok, dopo controllo e ti rispondo



 Quella scritta dovrebbe comparire solo usando l'opzione -n ma, come ha detto
 Cristian, sarebbe meglio usarla solo di tanto in tanto.

 Se ben ricordo dovresti lanciare lo script tramite:
 python launch_script.py -u -a -t -c -w -s --nofx


no, io lancio questo (la u la faccio prima)

./launch_script.py -n -t -c --nofx --save_stats -w

senza l'opzione n funziona
devo aggiungere l'opzione a??


 Ciao,
 Simone F.



-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [Talk-it] Surface per lastricato

demon.box ha scritto:
 http://gis.19327.n5.nabble.com/file/n5804472/IMG_4507_%28800_x_600%29.jpg 

 che dite? pebblestone o gravel?
Non trovo la foto

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

Re: [Talk-it] R: TOWN VILLAGE

Giuseppe Amici ha scritto:

 Quindi riassumendo: - possono essere entrambi modelli di mappatura
 corretti

 Personalmente propendo per il modello capoluogo di comune come TOWN e
 frazioni come VILLAGE
 ANCHE perché
 nella visualizzazione della mappa - da ingrandimento 9 – compaiono i
 capoluoghi di comune e le frazioni con caratteri di dimensione diversa
 che individuano chiaramente e visivamente “le caratteristiche dei place”.
 E trovo che sia un aiuto visuale ed ergonomico formidabile alla
 consultazione della mappa. Ovvero una sua fruibilità.


-1

Ritengo invece molto più appropriato scegliere i valori del tag place
sulla base dei suggerimenti del wiki, cioè della popolazione. Una
località è town se ha un numero sufficiente di abitanti. Se è più
piccola è village. Se è ancora più piccola è hamlet. Sono molto più
frequenti capoluoghi di comune village e frazioni hamlet.

In generale, l'importanza geografica di una località è correlata al
numero di abitanti. Il fatto che in Italia alcuni paesi vengano per
legge definiti città importa poco in questo contesto. Penso sia più
opportuno garantire una certa uniformità nella mappatura, che può essere
ottenuta seguendo le prassi suggerite nel wiki.

Anche le considerazioni legate alla visualizzazione non sono così
cruciali. L'aspetto più importante è mappare la realtà nel modo più
fedele possibile. Come l'informazione viene poi visualizzata è un
problema diverso, che sta a valle di una mappatura realistica.

Per questo, ritengo che le modifiche di Andrea Musuruane siano adeguate.
Mappare tutti i paesi della provincia di Pavia come town non è
realistico. Anch'io quando incontro incongruenze di questo tipo le correggo.

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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden aborruso

Francesco Piero Paolicelli wrote
 Rimango dell'idea che la parte foto/video si trainante per la diffusione.

E sono d'accordo. Anche per questo sto usando Mapillary, e mi faccio lo
streetview di un giardino pubblico:
http://www.mapillary.com/map/im/AZycU1UZhWJLxBh6GYfUxw

L'app mobile è sia per Android che iOS



-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Official-Google-Blog-Go-back-in-time-with-Street-View-tp5804019p5804494.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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Luca Delucchi

On 29 April 2014 09:20, aborruso aborr...@gmail.com wrote:
 Francesco Piero Paolicelli wrote
 Rimango dell'idea che la parte foto/video si trainante per la diffusione.

 E sono d'accordo. Anche per questo sto usando Mapillary, e mi faccio lo
 streetview di un giardino pubblico:
 http://www.mapillary.com/map/im/AZycU1UZhWJLxBh6GYfUxw

 L'app mobile è sia per Android che iOS


Giusto per segnalare che i dati (in special modo le foto) di Mapillary
non sono liberi, la licenza infatti vieta di utilizzare le immagini
che scopi commerciali...


 -
 Andrea Borruso



-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden aborruso

Ciao Luca,


Luca Delucchi wrote
 Giusto per segnalare che i dati (in special modo le foto) di Mapillary
 non sono liberi, la licenza infatti vieta di utilizzare le immagini
 che scopi commerciali...

è vero, ma l'ho segnalato in risposta a un post su Google. 
Chiedo venia :)




-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Official-Google-Blog-Go-back-in-time-with-Street-View-tp5804019p5804496.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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Luca Delucchi

2014-04-29 9:26 GMT+02:00 aborruso aborr...@gmail.com:
 Ciao Luca,


Ciao Andrea,


 Luca Delucchi wrote
 Giusto per segnalare che i dati (in special modo le foto) di Mapillary
 non sono liberi, la licenza infatti vieta di utilizzare le immagini
 che scopi commerciali...

 è vero, ma l'ho segnalato in risposta a un post su Google.
 Chiedo venia :)


nessun problema, era giusto per segnalare la cosa.
Magari non tutti leggono le licenze d'uso ;-)


 -
 Andrea Borruso



-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Maurizio Napolitano

Il 29/apr/2014 09:29 Luca Delucchi lucadel...@gmail.com ha scritto:

 2014-04-29 9:26 GMT+02:00 aborruso aborr...@gmail.com:
  Ciao Luca,
 

 Ciao Andrea,

 
  Luca Delucchi wrote
  Giusto per segnalare che i dati (in special modo le foto) di Mapillary
  non sono liberi, la licenza infatti vieta di utilizzare le immagini
  che scopi commerciali...
 
  è vero, ma l'ho segnalato in risposta a un post su Google.
  Chiedo venia :)
 

 nessun problema, era giusto per segnalare la cosa.
 Magari non tutti leggono le licenze d'uso ;-)

Concordo su tutti i fronti
Mi sento però di spezzare una lancia a favore visto che comunque è una
alternativa più aperta di streetview
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Francesco Piero Paolicelli

+1

Inviato da iPhone

 Il giorno 29/apr/2014, alle ore 09:20, aborruso aborr...@gmail.com ha 
 scritto:
 
 Francesco Piero Paolicelli wrote
 Rimango dell'idea che la parte foto/video si trainante per la diffusione.
 
 E sono d'accordo. Anche per questo sto usando Mapillary, e mi faccio lo
 streetview di un giardino pubblico:
 http://www.mapillary.com/map/im/AZycU1UZhWJLxBh6GYfUxw
 
 L'app mobile è sia per Android che iOS
 
 
 
 -
 Andrea Borruso 
 
  
 email: aborr...@tin.it 
 website: http://blog.spaziogis.it
 my 2.0 life: http://aborruso.spaziogis.it
 feed: http://feeds2.feedburner.com/Tanto
 38° 7' 48 N, 13° 21' 9 E 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Official-Google-Blog-Go-back-in-time-with-Street-View-tp5804019p5804494.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

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

Re: [Talk-it] R: TOWN VILLAGE

2014-04-29 Diskussionsfäden Simone Saviolo

Il giorno 29 aprile 2014 09:09, solitone solit...@mail.com ha scritto:

 Giuseppe Amici ha scritto:
 
  Quindi riassumendo: - possono essere entrambi modelli di mappatura
  corretti
 
  Personalmente propendo per il modello capoluogo di comune come TOWN e
  frazioni come VILLAGE
  ANCHE perché
  nella visualizzazione della mappa - da ingrandimento 9 – compaiono i
  capoluoghi di comune e le frazioni con caratteri di dimensione diversa
  che individuano chiaramente e visivamente “le caratteristiche dei place”.
  E trovo che sia un aiuto visuale ed ergonomico formidabile alla
  consultazione della mappa. Ovvero una sua fruibilità.
 

 -1

 Ritengo invece molto più appropriato scegliere i valori del tag place
 sulla base dei suggerimenti del wiki, cioè della popolazione. Una
 località è town se ha un numero sufficiente di abitanti. Se è più
 piccola è village. Se è ancora più piccola è hamlet. Sono molto più
 frequenti capoluoghi di comune village e frazioni hamlet.

 In generale, l'importanza geografica di una località è correlata al
 numero di abitanti. Il fatto che in Italia alcuni paesi vengano per
 legge definiti città importa poco in questo contesto. Penso sia più
 opportuno garantire una certa uniformità nella mappatura, che può essere
 ottenuta seguendo le prassi suggerite nel wiki.

 Anche le considerazioni legate alla visualizzazione non sono così
 cruciali. L'aspetto più importante è mappare la realtà nel modo più
 fedele possibile. Come l'informazione viene poi visualizzata è un
 problema diverso, che sta a valle di una mappatura realistica.

 Per questo, ritengo che le modifiche di Andrea Musuruane siano adeguate.
 Mappare tutti i paesi della provincia di Pavia come town non è
 realistico. Anch'io quando incontro incongruenze di questo tipo le
 correggo.


Basta! Non ne posso più di queste discussioni sui place... si ripropongono
periodicamente come dei formidabili peperoni, e non si arriva mai da
nessuna parte.

In generale, l'importanza geografica di una località è VAGAMENTE correlata
al numero di abitanti. È correlata in maniera molto più stretta alla sua
posizione geografica, alla distribuzione della densità di abitanti nei
dintorni, alla distribuzione della densità dei servizi nei dintorni, alla
presenza o meno di attrattive economiche (fabbriche, strade, etc.) e/o
turistiche. Un centro urbano di 50.000 abitanti può essere un punto di
riferimento per un territorio punteggiato di paesi di meno di 5000
abitanti; uno di 120.000 può essere just another città della cintura se
si trova nel mezzo di una grande conurbazione.

Posto il fatto che esempi proprio estremi (city di 30.000, town di 140.000)
in Italia non me ne vengono in mente, non ho alcuna intenzione di cambiare
una city in town perché nel 2013 è passata sotto soglia scendendo sotto
un magico numero di abitanti stabilito arbitrariamente. Numero tondo,
ovviamente, mica 64.324.

D'altro canto non concordo neanche con l'idea che capoluogo di Comune =
town. La traduzione village=frazione in JOSM è sbagliata, è già stato
segnalato ripetutamente. È sbagliata anche perché nel caso di Comuni
sparsi, con molti centri abitati, non è sempre detto che il capoluogo sia
il centro principale. Posso inoltre portare esempi di paesi, capoluoghi di
Comune e unici centri abitati del Comune, che hanno a malapena un bar, una
farmacia e una scuola elementare nei locali del Municipio - altro che town,
alcuni viene persino da chiedersi se sono village :-)

Quindi:

- grosso centro urbano, con servizi che attirano la gente da fuori, di
quelli che dici questo centro è la 'capitale' del distretto qua attorno
(es: si dice il Vercellese, il Biellese, il Monferrato, il
Monregalese) = ALMENO TOWN.
*Di solito* questo coincide con centri urbani di almeno 20.000 abitanti, ma
potrebbero essere 15.000 - ad esempio in Valsesia parlano di Borgosesia
come se fosse una grande capitale europea, perché è il centro più grosso
che hanno nel raggio di 40 km, e poi in realtà contando tutte le cinquanta
frazioni sparse per i fianchi della montagna fa 13.000 abitanti scarsi.

- GROSSO centro urbano, magari centro di una (anche piccola) metropoli
(ricordando che la metropoli non si riconosce dal numero di abitanti ma
dalla forza dell'agglomerato urbano) = CITY.
Non metterei city ad Alba o a Bra, anche se sono un punto di riferimento
per il circondario. Novara e Alessandria sono city, anche se Alessandria
non raggiunge il numero magico di 100.000 che si citava un tempo. Però: in
Piemonte, a parte Torino (900.000 abitanti), c'è solo Novara (102.000)
sopra la soglia. Poi gli altri capoluoghi sono Alessandria (90.000), Asti
(75.000), Cuneo (55.000), Vercelli (46.000), Biella (44.000) e Verbania
(30.000). Cinque dei primi dieci Comuni piemontesi per popolazione sono
parte della prima cintura di Torino, e hanno più abitanti di metà dei
capoluoghi di provincia. Però Vercelli è un punto di riferimento per il
circondario, Moncalieri che fa 10.000 abitanti in più no. Biella è la testa
di una

Re: [Talk-it] R: TOWN VILLAGE

Simone Saviolo ha scritto:
 Basta! Non ne posso più di queste discussioni sui place... si
 ripropongono periodicamente come dei formidabili peperoni, e non si
 arriva mai da nessuna parte. 

 In generale, l'importanza geografica di una località è VAGAMENTE
 correlata al numero di abitanti. È correlata in maniera molto più
 stretta alla sua posizione geografica, alla distribuzione della
 densità di abitanti nei dintorni, alla distribuzione della densità dei
 servizi nei dintorni, alla presenza o meno di attrattive economiche
 (fabbriche, strade, etc.) e/o turistiche. Un centro urbano di 50.000
 abitanti può essere un punto di riferimento per un territorio
 punteggiato di paesi di meno di 5000 abitanti; uno di 120.000 può
 essere just another città della cintura se si trova nel mezzo di una
 grande conurbazione.

Sono d'accordo che la popolazione non sia l'unico criterio da tenere in
considerazione. Teniamo conto, però, che non è pensabile che tutte le
località della provincia di Pavia siano punti di riferimento nel
territorio e meritino il titolo di town, anche supposto che per legge
siano state nominate città. Questo non capita in altre province e non
vedo perché Pavia debba essere diversa.

 Spero sempre che riusciamo a raggiungere un consenso - o almeno un
 compromesso. Scusate il papiro, ma voglio che scendiamo nel concreto,
 perché altrimenti finiamo sempre solo per dire più di 100.000, meno
 di 100.000. (Oltretutto 100.000 sembra proprio scelto a caso, in
 Veneto ci sono tre Comuni di 250.000 abitanti, il Molise ne fa 300.000
 in tutto). 

Sono anche d'accordo che il criterio della popolazione non debba essere
seguito in maniera rigida, considerando le soglie indicate come
vincolanti. Ma perché non integri il wiki (inglese e italiano) con
queste tue considerazioni, in modo da rendere noti a tutti i buoni
criteri da seguire che proponi? Altrimenti la cosa resta tra noi e non è
molto utile.

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

Re: [Talk-it] R: TOWN VILLAGE

2014-04-29 Diskussionsfäden Francesco Pelullo

Il giorno 29 aprile 2014 10:17, solitone solit...@mail.com ha scritto:

 Ma perché non integri il wiki (inglese e italiano) con
 queste tue considerazioni, in modo da rendere noti a tutti i buoni
 criteri da seguire che proponi? Altrimenti la cosa resta tra noi e non è
 molto utile.


+1
Lo strumento più indicato è la pagina discussioni del tag.
Il problema è che spesso non esiste nemmeno la pagina in italiano del
tag...

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

Re: [Talk-it] R: TOWN VILLAGE

2014-04-29 Diskussionsfäden Alessandro Rubini

 Basta! Non ne posso piu` di queste discussioni sui place...
 [...]

Grazie simone. Sono completamente d'accordo, da utente abituale di
cartografia, pur senza una preparazione specifica sulla tecnologia
moderna.

A volte leggendo questa lista sembra proprio che si perda il senso del
mondo reale (che nulla ha a che fare con la legislazione italiana e il
livello amministrativo dato alle localita`).

Esattamente come per la rete viaria (primary, secondary, tertiary,
quaternary (che si scrive unclassified)) per i centri urbani ci deve
essere una gerarchia sensata in base a come le cose sono e vengono
vissute nel mondo reale.  Altrimenti la mappa e` inutilizzabile.

Dopo di che abbiamo un problema di rendering: ci sono zone in cui a
certi livelli di ingrandimento non si vede nemmeno un nome, ma questo
va sistemato a livello di rendering, non di database. E sono cosciente
che non e` assolutamente banale da affrontare, ma non e` certo
promuovendo tutti i comuni a town che si migliora la situazione.

/alessandro

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

Re: [Talk-it] R: TOWN VILLAGE

2014-04-29 Diskussionsfäden Simone Saviolo

Il giorno 29 aprile 2014 10:17, solitone solit...@mail.com ha scritto:

 Simone Saviolo ha scritto:
  Basta! Non ne posso più di queste discussioni sui place... si
  ripropongono periodicamente come dei formidabili peperoni, e non si
  arriva mai da nessuna parte.
 
  In generale, l'importanza geografica di una località è VAGAMENTE
  correlata al numero di abitanti. È correlata in maniera molto più
  stretta alla sua posizione geografica, alla distribuzione della
  densità di abitanti nei dintorni, alla distribuzione della densità dei
  servizi nei dintorni, alla presenza o meno di attrattive economiche
  (fabbriche, strade, etc.) e/o turistiche. Un centro urbano di 50.000
  abitanti può essere un punto di riferimento per un territorio
  punteggiato di paesi di meno di 5000 abitanti; uno di 120.000 può
  essere just another città della cintura se si trova nel mezzo di una
  grande conurbazione.

 Sono d'accordo che la popolazione non sia l'unico criterio da tenere in
 considerazione. Teniamo conto, però, che non è pensabile che tutte le
 località della provincia di Pavia siano punti di riferimento nel
 territorio e meritino il titolo di town, anche supposto che per legge
 siano state nominate città. Questo non capita in altre province e non
 vedo perché Pavia debba essere diversa.


+1

Mi sono dimenticato di scriverlo prima, ma tutto il mio ragionamento
prescinde completamente dal titolo legale di città. Per me, in questo
ambito quello ha lo stesso valore della Medaglia alle Città Benemerite del
Risorgimento Nazionale.

 Spero sempre che riusciamo a raggiungere un consenso - o almeno un
  compromesso. Scusate il papiro, ma voglio che scendiamo nel concreto,
  perché altrimenti finiamo sempre solo per dire più di 100.000, meno
  di 100.000. (Oltretutto 100.000 sembra proprio scelto a caso, in
  Veneto ci sono tre Comuni di 250.000 abitanti, il Molise ne fa 300.000
  in tutto).

 Sono anche d'accordo che il criterio della popolazione non debba essere
 seguito in maniera rigida, considerando le soglie indicate come
 vincolanti. Ma perché non integri il wiki (inglese e italiano) con
 queste tue considerazioni, in modo da rendere noti a tutti i buoni
 criteri da seguire che proponi? Altrimenti la cosa resta tra noi e non è
 molto utile.


Hai ragione. Vedrò di inaugurare la pagina, se non c'è già :-)

Ciao,

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

Re: [Talk-it] Surface per lastricato

2014-04-29 Diskussionsfäden demon.box

scusa riprovo.

http://gis.19327.n5.nabble.com/file/n5804511/IMG_4507_%281024_x_768%29.jpg 

dimmi x favore se ora si vede.
grazie, ciao
--enrico




--
View this message in context: 
http://gis.19327.n5.nabble.com/Surface-per-lastricato-tp5804308p5804511.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

Re: [Talk-it] Surface per lastricato

demon.box ha scritto:
 scusa riprovo.

 http://gis.19327.n5.nabble.com/file/n5804511/IMG_4507_%281024_x_768%29.jpg 

 dimmi x favore se ora si vede.

Sì, si vede.

Io questa la considererei gravel, anche se le dimensioni sono un po'
troppo grandi, dato che pebblestone fa pensare a sassi arrotondati e
smussati, levigati per es. dall'azione dell'acqua.

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

[Talk-it] R: R: TOWN VILLAGE

Vedo che viene omessa in toto il nocciuolo della questione:
Ovvero che la traduzione dall’inglese di TOWN è sia Citta che Paese.

Sarebbe bello come fa qualcuno dire “BASTA!” e con un colpo di spugna 
cancellare le discussioni.
Il fatto che le discussioni si riaccendano dovrebbe invece suggerire proprio 
che “non sono esaurite”, anzi si basano su degli assunti non condivisi. Ergo 
non c’è un accordo sul “reale” oggettivamente mappato.

Alle volte sento fare riferimenti al wiky come se fosse “la parola del 
signore”. Come la mettiamo se questo wiky è contradditorio ad esempio nella sua 
traduzione in una lingua locale? O se traduce una parola in una accezione 
restrittiva?

A volte si tenta di dirimere la questione con riferimenti legali. E questi sono 
presi ancora una volta come “voce del Verbo”. (a titolo di esempio la legalità 
o meno di mettere i nomi in sardo)

A volte è chi con arroganza impone un punto di vista.

Insomma il mondo è vario. Ma per piacere risparmiatemi e risparmiateci la 
posizione di persone che sentono di avere la verità in tasca – o di portare 
l’acqua in mano.

Infine ricordo che “un accordo condiviso” – o un modello di tagging, qualora lo 
si ritenga insufficiente lo si cambia. In questo sta il mostrare intelligenza. 
Invece molte volte qui mi pare che ci siano persone che hanno sempre e solo 
bisogno di adeguarsi a norme, dimenticando che queste norme le hanno fatte 
persone “fallaci” come loro.

Una buona giornata.
Beppe

 

Da: Simone Saviolo [mailto:simone.savi...@gmail.com] 
Inviato: martedì 29 aprile 2014 10:32
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: TOWN  VILLAGE

 

Il giorno 29 aprile 2014 10:17, solitone solit...@mail.com ha scritto:

Simone Saviolo ha scritto:

 Basta! Non ne posso più di queste discussioni sui place... si
 ripropongono periodicamente come dei formidabili peperoni, e non si
 arriva mai da nessuna parte.

 In generale, l'importanza geografica di una località è VAGAMENTE
 correlata al numero di abitanti. È correlata in maniera molto più
 stretta alla sua posizione geografica, alla distribuzione della
 densità di abitanti nei dintorni, alla distribuzione della densità dei
 servizi nei dintorni, alla presenza o meno di attrattive economiche
 (fabbriche, strade, etc.) e/o turistiche. Un centro urbano di 50.000
 abitanti può essere un punto di riferimento per un territorio
 punteggiato di paesi di meno di 5000 abitanti; uno di 120.000 può
 essere just another città della cintura se si trova nel mezzo di una
 grande conurbazione.

Sono d'accordo che la popolazione non sia l'unico criterio da tenere in
considerazione. Teniamo conto, però, che non è pensabile che tutte le
località della provincia di Pavia siano punti di riferimento nel
territorio e meritino il titolo di town, anche supposto che per legge
siano state nominate città. Questo non capita in altre province e non
vedo perché Pavia debba essere diversa.

 

+1

 

Mi sono dimenticato di scriverlo prima, ma tutto il mio ragionamento prescinde 
completamente dal titolo legale di città. Per me, in questo ambito quello ha 
lo stesso valore della Medaglia alle Città Benemerite del Risorgimento 
Nazionale. 

 

 Spero sempre che riusciamo a raggiungere un consenso - o almeno un
 compromesso. Scusate il papiro, ma voglio che scendiamo nel concreto,
 perché altrimenti finiamo sempre solo per dire più di 100.000, meno
 di 100.000. (Oltretutto 100.000 sembra proprio scelto a caso, in
 Veneto ci sono tre Comuni di 250.000 abitanti, il Molise ne fa 300.000
 in tutto).

Sono anche d'accordo che il criterio della popolazione non debba essere
seguito in maniera rigida, considerando le soglie indicate come
vincolanti. Ma perché non integri il wiki (inglese e italiano) con
queste tue considerazioni, in modo da rendere noti a tutti i buoni
criteri da seguire che proponi? Altrimenti la cosa resta tra noi e non è
molto utile.

 

Hai ragione. Vedrò di inaugurare la pagina, se non c'è già :-)

 

Ciao,

 

Simone

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

[Talk-it] Violazioni

2014-04-29 Diskussionsfäden Simone Cortesi

Per chi non lo avesse letto

http://openstreetmap.it/2014/04/attribuzione-e-arrivata-lora-di-fare-i-nomi-di-chi-sgarra/

Abbiamo pubblicato la risposta di Steve alle critiche sull'attuale licenza
e sulla necessità di far rispettare sia la clausola di sharealike che di
atrribution.

-- 
Sent from my rotary dial phone. Not a fruit.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: TOWN VILLAGE


  
  
Giuseppe Amici ha scritto:


  
  
  
  
Vedo
che viene omessa in toto il nocciuolo della questione:
Ovvero che la traduzione dallinglese di TOWN  sia Citta
che Paese.
  
  


Il problema  che in italiano non esiste un termine specifico per
"town". Quindi o lo traduci con "piccola citt", oppure con "grande
paese":

city: 1 [countable] a large and important town [1]
town: 1 [countable, uncountable] a place with many houses,
shops/stores, etc. where people live and work. It is larger than a
village but smaller than a city [2]
village: 1 [countable] a very small town located in a country area
[3]


  
Sarebbe
bello come fa qualcuno dire BASTA! e con un colpo di
spugna cancellare le discussioni.
Il fatto che le discussioni si riaccendano dovrebbe invece
suggerire proprio che non sono esaurite, anzi si basano su
degli assunti non condivisi. Ergo non c un accordo sul
reale oggettivamente mappato.
  
  


Non ci sar accordo totale, ma mi pare che, in questo caso, l'unico
che la pensa diversamente sia tu. Quindi, anche se l'accordo non 
al 100%, mi sembra che ci sia una visione piuttosto concordante! In
altri casi quello che dici potrebbe avere peso, ma in questo non
vedo dove sia il problema, francamente. Non ci possiamo inchiodare e
dire, solamente perch un utente la vede diversamente: mappate come
volete, tanto non c' una visione condivisa!

Sul fatto che non sia opportuno utilizzare il titolo legale di
"citt" per il mapping hanno espresso parere favorevole, solo in
questa discussione, Volker, Andrea, Simone e io; tu sei l'unico che
dice il contrario. Recentemente c' stata una discussione simile
[4] che, se ti vai a rileggere tutta, vedrai porta alle stesse
conclusioni.


[1]
http://www.oxfordlearnersdictionaries.com/definition/english/city
[2]
http://www.oxfordlearnersdictionaries.com/definition/english/town
[3]
http://www.oxfordlearnersdictionaries.com/definition/english/village
[4] Uso di place=town pei i comuni non capoluoghi di provincia:
http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.it/40199

  


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

Re: [Talk-it] R: R: TOWN VILLAGE

2014-04-29 Diskussionsfäden Simone Saviolo

Il giorno 29 aprile 2014 13:08, Giuseppe Amici
giuseppeam...@virgilio.itha scritto:

 Vedo che viene omessa in toto il nocciuolo della questione:
 Ovvero che la traduzione dall’inglese di TOWN è sia Citta che Paese.


E la traduzione di village è villaggio. Chi abita più nei villaggi nel
Duemila? Il Pio Collegio delle Orfane di Cristo lo tagghiamo
amenity=college?

La traduzione è culturale; il tagging è formale. Il fatto che la value si
chiami town è solo uno mnemonico: per gli scopi del database invece di
place=town poteva esserci 741=3. Town è la seconda value per importanza
tra le possibili modalità di place; come tale lo si definisce. Palm
Town o Kansas City non c'entrano niente con il nostro schema di tagging.

Sarebbe bello come fa qualcuno dire “BASTA!” e con un colpo di spugna
 cancellare le discussioni.
 Il fatto che le discussioni si riaccendano dovrebbe invece suggerire
 proprio che “non sono esaurite”, anzi si basano su degli assunti non
 condivisi. Ergo non c’è un accordo sul “reale” oggettivamente mappato.


Le discussioni si riaccendono quando nuovi mappatori non accettano le
convenzioni, che sono il risultato di lunghe discussioni all'interno della
comunità. Mappo da quattro anni e mezzo e mi sento ancora un giovinastro
rispetto a chi mappa da più tempo di me e sa perché storicamente sono state
fatte certe scelte.

Le convenzioni non sono scolpite nella roccia eterna ed immutabile, e
possono essere cambiate. Ma che ogni tre mesi debba arrivare qualcuno a
dire trovo inaccettabile che la tale città di 48900 abitanti sia stata
taggata city visto che ha meno di 5 abitanti oppure a stabilire nuovi
schemi di tagging e ad imporli (com'è successo nel caso del pavese o del
parmense), mi sembra esagerato. Una regola non va cambiata solo perché
nella comunità è arrivato un nuovo membro...


 Alle volte sento fare riferimenti al wiky come se fosse “la parola del
 signore”. Come la mettiamo se questo wiky è contradditorio ad esempio nella
 sua traduzione in una lingua locale? O se traduce una parola in una
 accezione restrittiva?


Allora tagga come amenity=bar tutti i bar di paese, che in realtà sono
amenity=cafe. Il wiki serve per coordinarci e documentare le convenzioni.
Non è detto che le convenzioni siano mondiali, ma potrebbero cambiare di
Paese in Paese. Ad esempio le gelaterie esistono solo da noi, per gli
inglesi erano amenity=fast_food, cuisine=ice_cream, perché il nostro
elemento culturale gelateria da loro non esiste.

A volte si tenta di dirimere la questione con riferimenti legali. E questi
 sono presi ancora una volta come “voce del Verbo”. (a titolo di esempio la
 legalità o meno di mettere i nomi in sardo)


Altra questione assolutamente fraintesa. Vuoi mettere il nome in sardo?
name:sc=* è quello che fa per te. Mettilo anche a Vienna e a Washington, se
ti pare. Il problema specifico nasceva su cosa mettere in name=*, che di
norma viene inteso come *il nome ufficiale* del luogo. La città emiliana si
chiama Reggio Emilia, Reggio nell'Emilia, Reggio d'Emilia...? Per dirimere
la questione si guardano i documenti ufficiali. Allo stesso modo, se sui
documenti ufficiali c'è scritto Bolzano - Bozen e Cagliari (non
Cagliari - Casteddu)[1], allora noi metteremo name=Bolzano - Bozen e
name=Cagliari.

[1] Esempio ipotetico: non sono addentro alla questione sarda. Per quanto
ne so io, può darsi che Cagliari abbia il doppio nome ufficiale.


 A volte è chi con arroganza impone un punto di vista.

 Insomma il mondo è vario. Ma per piacere risparmiatemi e risparmiateci la
 posizione di persone che sentono di avere la verità in tasca – o di portare
 l’acqua in mano.

 Infine ricordo che “un accordo condiviso” – o un modello di tagging,
 qualora lo si ritenga insufficiente lo si cambia. In questo sta il mostrare
 intelligenza. Invece molte volte qui mi pare che ci siano persone che hanno
 sempre e solo bisogno di adeguarsi a norme, dimenticando che queste norme
 le hanno fatte persone “fallaci” come loro.


Non mi sembra che qua si sia proposto un nuovo modello di tagging per
sopperire alle mancanze di quello esistente. I problemi che hai rilevato
sono stati tutti affrontati: per individuare il capoluogo si usa capital=8,
e se il rendering non disegna nomi in una certa area è un problema del
rendering (oppure neanche: in fondo non mi aspetto di vedere in Antartide
tante etichette quante nei dintorni di Tokyo). Uno schema in piedi da anni
può essere modificato o anche abbattuto, certo, ma se fosse stato così
banale farlo non sarebbe durato tutti questi anni, no? :-)

Ciao,

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

[Talk-it] conferenza SOTM: early bird in chiusura

2014-04-29 Diskussionsfäden Simone Cortesi

Carissimi,
alla fine del mese, la registrazione early bird per SOTM-EU (a 55euro)
finirà. Dopo di che il prezzo del biglietto sarà 80euro.

http://www.sotm-eu.org/

Vi aspettiamo a Karlsruhe!

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

Re: [Talk-it] Surface per lastricato

2014-04-29 Diskussionsfäden girarsi_liste

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Il 29/04/2014 11:05, solitone ha scritto:
 demon.box ha scritto:
 scusa riprovo.
 
 http://gis.19327.n5.nabble.com/file/n5804511/IMG_4507_%281024_x_768%29.jpg
 
 
 dimmi x favore se ora si vede.
 
 Sì, si vede.
 
 Io questa la considererei gravel, anche se le dimensioni sono un
 po' troppo grandi, dato che pebblestone fa pensare a sassi
 arrotondati e smussati, levigati per es. dall'azione dell'acqua.
 
Anch'io in questo caso vedo gravel e non cobblestone:flattened.



- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlNfxYUACgkQoVS0hKoD3PNkJAD+OlEcUiNJ0T8+oy925y5uRa82
h876vUbapZ/qQEEjx/4A/A0lcd+Oa2KfUbBYRhdDVVRk6spAJg31NKqwZZ0Z8GPt
=zfKQ
-END PGP SIGNATURE-

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

Re: [Talk-it] Violazioni

2014-04-29 Diskussionsfäden Edoardo Yossef Marascalchi

+ 1milione
On Apr 29, 2014 2:44 PM, Simone Cortesi sim...@cortesi.com wrote:

 Per chi non lo avesse letto


 http://openstreetmap.it/2014/04/attribuzione-e-arrivata-lora-di-fare-i-nomi-di-chi-sgarra/

 Abbiamo pubblicato la risposta di Steve alle critiche sull'attuale licenza
 e sulla necessità di far rispettare sia la clausola di sharealike che di
 atrribution.

 --
 Sent from my rotary dial phone. Not a fruit.

 ___
 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] Violazioni

2014-04-29 Diskussionsfäden Francesco Pelullo

Era ora.

Adesso ci dedichiamo a quei buzzurri che importano dati con licenza
incompatibile?

Ciao
/niubii/
 Il 29/apr/2014 13:44 Simone Cortesi sim...@cortesi.com ha scritto:

 Per chi non lo avesse letto


 http://openstreetmap.it/2014/04/attribuzione-e-arrivata-lora-di-fare-i-nomi-di-chi-sgarra/

 Abbiamo pubblicato la risposta di Steve alle critiche sull'attuale licenza
 e sulla necessità di far rispettare sia la clausola di sharealike che di
 atrribution.

 --
 Sent from my rotary dial phone. Not a fruit.

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


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

[Talk-it] Obiettivi sensibili

2014-04-29 Diskussionsfäden sabas88

Ciao,
c'è qualche dichiarazione da qualche parte riguardante dati OSM che
rappresentano obiettivi sensibili, tipo aree militari e simili?
Intendo cose che tirano in ballo sicurezza nazionale e affini.

Si mappa quello che si vede?

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

Re: [Talk-it] wtosm

2014-04-29 Diskussionsfäden Simone F.

Il giorno 29 aprile 2014 08:41, Luca Delucchi lucadel...@gmail.com ha
scritto:

 2014-04-28 22:28 GMT+02:00 Simone F. grop...@gmail.com:
  Quella scritta dovrebbe comparire solo usando l'opzione -n ma, come ha
 detto
  Cristian, sarebbe meglio usarla solo di tanto in tanto.
 
  Se ben ricordo dovresti lanciare lo script tramite:
  python launch_script.py -u -a -t -c -w -s --nofx
 

 no, io lancio questo (la u la faccio prima)

 ./launch_script.py -n -t -c --nofx --save_stats -w

 senza l'opzione n funziona


Bene.

devo aggiungere l'opzione a??


Non serve.
I dati vengono automaticamente analizzati (-a) quando si chiede di creare
le pagine aggiornate (-w).


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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Alberto Nogaro

-Original Message-
From: Luca Delucchi [mailto:lucadel...@gmail.com]
Sent: martedì 29 aprile 2014 09:24
To: openstreetmap list - italiano
Subject: Re: [Talk-it] Official Google Blog: Go back in time with Street
View

Giusto per segnalare che i dati (in special modo le foto) di Mapillary non
sono
liberi, la licenza infatti vieta di utilizzare le immagini che scopi
commerciali...

Non più, oggi hanno annunciato sul blog [1] di avere cambiato la licenza in
CC BY-SA. 

[1] http://blog.mapillary.com/

Ciao,
Alberrto

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

Re: [Talk-it] Obiettivi sensibili

2014-04-29 Diskussionsfäden Leonardo


Relinko la discussione del 2012, potremmo ripartire a parlarne da qui:

https://lists.openstreetmap.org/pipermail/talk-it/2012-October/031203.html

Leonardo

Il 29/04/2014 20:55, sabas88 ha scritto:

Ciao,
c'è qualche dichiarazione da qualche parte riguardante dati OSM che 
rappresentano obiettivi sensibili, tipo aree militari e simili?

Intendo cose che tirano in ballo sicurezza nazionale e affini.

Si mappa quello che si vede?

Grazie,
Stefano


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


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

Re: [Talk-it] Official Google Blog: Go back in time with Street View

2014-04-29 Diskussionsfäden Cristian Consonni

Il 29/apr/2014 21:29 Alberto Nogaro bartosom...@yahoo.it ha scritto:

 -Original Message-
 From: Luca Delucchi [mailto:lucadel...@gmail.com]
 Sent: martedì 29 aprile 2014 09:24
 To: openstreetmap list - italiano
 Subject: Re: [Talk-it] Official Google Blog: Go back in time with Street
 View

 Giusto per segnalare che i dati (in special modo le foto) di Mapillary
non
 sono
 liberi, la licenza infatti vieta di utilizzare le immagini che scopi
 commerciali...

 Non più, oggi hanno annunciato sul blog [1] di avere cambiato la licenza
in
 CC BY-SA.

 [1] http://blog.mapillary.com/

Bella notizia. Negli ultimi due mesi sarà la quarta volta che cambiano
idea/licenze. Speriamo non la cambino più ;-).

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

[Talk-it] Fwd: Wikimedia Foundation OpenStreetMap nel piano annuale WMF

2014-04-29 Diskussionsfäden Cristian Consonni

Ciao,

volevo farvi notare questo passaggio del (la bozza del) piano annuale
di Wikimedia Foundation:
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2013-2014_round2/Wikimedia_Foundation/Proposal_form
il piano comprende una significativa espansione del team di
Engineering[1], con un aumento di 22 unità (rispetto alle 84 attuale,
quindi di più del 25%).

== New software engineers ==

«Could you be more specific about what the 14 new Software Engineers will do?»

«Yeah, to a point. Our work in eng/prod overall is very iterative, of
course, and the below is subject to internal and external feedback,
real world experience and the final budget mount. At a high level,
we're not currently planning to build a whole new development team (at
the scale of the Flow or VisualEditor team). Here are a few goals that
have informed the plan:

We're considering a small (roughly 2 person) effort focused on
mapping-related infrastructure which is a shared need for lots of
projects, esp. mobile. This would be similar to our current search
infrastructure effort (also a 2 person effort), delivering the basics
(e.g. robust, scalable OpenStreetMap tiling service) but not yet a
huge amount of new functionality, rather, enabling other teams to then
leverage this in building features/products (e.g. a map-based nearby
view for mobile). Underlying hypothesis here is that with the shift to
mobile overall, we'll want to leverage geo-related functionality more
consistently across the board as part of new contributory funnels. We
also know it's high on the community's wishlist.
[...]»
(https://meta.wikimedia.org/wiki/Grants_talk:APG/Proposals/2013-2014_round2/Wikimedia_Foundation/Proposal_form#New_software_engineers)

La risposta è di Erik Moëller, Deputy Director e Vice President of
Engineering and Product Development, in pratica il capo della parte
tecnica di Wikimedia Foundation.

Ciao,

[1]
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2013-2014_round2/Wikimedia_Foundation/Proposal_form#Staff_and_long-term_contractors

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

[Talk-it] R: R: R: TOWN VILLAGE

Ringrazio tutti, 
per il loro tempo e per la loro saggezza.

Ritornino pure alle loro discussioni preferite.

Beppe

 

Da: Simone Saviolo [mailto:simone.savi...@gmail.com] 
Inviato: martedì 29 aprile 2014 15:42
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: R: TOWN  VILLAGE

 

Il giorno 29 aprile 2014 13:08, Giuseppe Amici giuseppeam...@virgilio.it ha 
scritto:

Vedo che viene omessa in toto il nocciuolo della questione:
Ovvero che la traduzione dall’inglese di TOWN è sia Citta che Paese.

 

E la traduzione di village è villaggio. Chi abita più nei villaggi nel Duemila? 
Il Pio Collegio delle Orfane di Cristo lo tagghiamo amenity=college?

 

La traduzione è culturale; il tagging è formale. Il fatto che la value si 
chiami town è solo uno mnemonico: per gli scopi del database invece di 
place=town poteva esserci 741=3. Town è la seconda value per importanza tra 
le possibili modalità di place; come tale lo si definisce. Palm Town o 
Kansas City non c'entrano niente con il nostro schema di tagging. 

 

Sarebbe bello come fa qualcuno dire “BASTA!” e con un colpo di spugna 
cancellare le discussioni.
Il fatto che le discussioni si riaccendano dovrebbe invece suggerire proprio 
che “non sono esaurite”, anzi si basano su degli assunti non condivisi. Ergo 
non c’è un accordo sul “reale” oggettivamente mappato.

 

Le discussioni si riaccendono quando nuovi mappatori non accettano le 
convenzioni, che sono il risultato di lunghe discussioni all'interno della 
comunità. Mappo da quattro anni e mezzo e mi sento ancora un giovinastro 
rispetto a chi mappa da più tempo di me e sa perché storicamente sono state 
fatte certe scelte. 

 

Le convenzioni non sono scolpite nella roccia eterna ed immutabile, e possono 
essere cambiate. Ma che ogni tre mesi debba arrivare qualcuno a dire trovo 
inaccettabile che la tale città di 48900 abitanti sia stata taggata city visto 
che ha meno di 5 abitanti oppure a stabilire nuovi schemi di tagging e ad 
imporli (com'è successo nel caso del pavese o del parmense), mi sembra 
esagerato. Una regola non va cambiata solo perché nella comunità è arrivato un 
nuovo membro...

 

Alle volte sento fare riferimenti al wiky come se fosse “la parola del 
signore”. Come la mettiamo se questo wiky è contradditorio ad esempio nella sua 
traduzione in una lingua locale? O se traduce una parola in una accezione 
restrittiva?

 

Allora tagga come amenity=bar tutti i bar di paese, che in realtà sono 
amenity=cafe. Il wiki serve per coordinarci e documentare le convenzioni. Non è 
detto che le convenzioni siano mondiali, ma potrebbero cambiare di Paese in 
Paese. Ad esempio le gelaterie esistono solo da noi, per gli inglesi erano 
amenity=fast_food, cuisine=ice_cream, perché il nostro elemento culturale 
gelateria da loro non esiste. 

 

A volte si tenta di dirimere la questione con riferimenti legali. E questi sono 
presi ancora una volta come “voce del Verbo”. (a titolo di esempio la legalità 
o meno di mettere i nomi in sardo)

 

Altra questione assolutamente fraintesa. Vuoi mettere il nome in sardo? 
name:sc=* è quello che fa per te. Mettilo anche a Vienna e a Washington, se ti 
pare. Il problema specifico nasceva su cosa mettere in name=*, che di norma 
viene inteso come *il nome ufficiale* del luogo. La città emiliana si chiama 
Reggio Emilia, Reggio nell'Emilia, Reggio d'Emilia...? Per dirimere la 
questione si guardano i documenti ufficiali. Allo stesso modo, se sui documenti 
ufficiali c'è scritto Bolzano - Bozen e Cagliari (non Cagliari - 
Casteddu)[1], allora noi metteremo name=Bolzano - Bozen e name=Cagliari. 

 

[1] Esempio ipotetico: non sono addentro alla questione sarda. Per quanto ne so 
io, può darsi che Cagliari abbia il doppio nome ufficiale.

 

A volte è chi con arroganza impone un punto di vista.

Insomma il mondo è vario. Ma per piacere risparmiatemi e risparmiateci la 
posizione di persone che sentono di avere la verità in tasca – o di portare 
l’acqua in mano.

Infine ricordo che “un accordo condiviso” – o un modello di tagging, qualora lo 
si ritenga insufficiente lo si cambia. In questo sta il mostrare intelligenza. 
Invece molte volte qui mi pare che ci siano persone che hanno sempre e solo 
bisogno di adeguarsi a norme, dimenticando che queste norme le hanno fatte 
persone “fallaci” come loro.

 

Non mi sembra che qua si sia proposto un nuovo modello di tagging per sopperire 
alle mancanze di quello esistente. I problemi che hai rilevato sono stati tutti 
affrontati: per individuare il capoluogo si usa capital=8, e se il rendering 
non disegna nomi in una certa area è un problema del rendering (oppure neanche: 
in fondo non mi aspetto di vedere in Antartide tante etichette quante nei 
dintorni di Tokyo). Uno schema in piedi da anni può essere modificato o anche 
abbattuto, certo, ma se fosse stato così banale farlo non sarebbe durato tutti 
questi anni, no? :-)

 

Ciao,

 

Simone

___
Talk-it mailing

[Talk-it] R: R: R: TOWN VILLAGE

Ringrazio Pelullo che mi ha fatto sorridere.

 


Il 29/apr/2014 13:09 Giuseppe Amici giuseppeam...@virgilio.it ha scritto:

 Una buona giornata.

Amen.
:-)
:-(

Ciao
/niubii/

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

Re: [Talk-it] Violazioni

2014-04-29 Diskussionsfäden Francesca Valentina

Grandi!
Il 29/apr/2014 13:44 Simone Cortesi sim...@cortesi.com ha scritto:

 Per chi non lo avesse letto


 http://openstreetmap.it/2014/04/attribuzione-e-arrivata-lora-di-fare-i-nomi-di-chi-sgarra/

 Abbiamo pubblicato la risposta di Steve alle critiche sull'attuale licenza
 e sulla necessità di far rispettare sia la clausola di sharealike che di
 atrribution.

 --
 Sent from my rotary dial phone. Not a fruit.

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


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

[Talk-se] Relationer och Sörmlandsleden

2014-04-29 Diskussionsfäden Claes Holmerson

Hej, 
Jag heter Claes och har ganska nyligen börjat intressera mig för OpenStreetMap. 
Jag har gjort några smärre tillägg och ville sen pussla ihop delar av 
Sörmlandsleden som inte var sorterade till etapper än. Sörmlandsleden (197845) 
har en rad relations för vissa etapper, men också lösa delar. Nu har jag skapat 
ytterligare relations för etapp 31-34 på samma sätt som jag såg att det var 
gjort för andra. 
Nu finns referenser direkt från leden till vissa paths, och via 
etapp-relations. Jag _tror_ att paths som ingår i etapp-relations bör tas bort 
från 197845 men tänkte höra så jag inte gör fel? 
Mvh Claes 


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

Re: [Talk-se] Relationer och Sörmlandsleden

2014-04-29 Diskussionsfäden Ture Pålsson


29 apr 2014 kl. 18.37 skrev Claes Holmerson:

 Hej, 
 Jag heter Claes och har ganska nyligen börjat intressera mig för 
 OpenStreetMap. Jag har gjort några smärre tillägg och ville sen pussla ihop 
 delar av Sörmlandsleden som inte var sorterade till etapper än. 
 Sörmlandsleden (197845) har en rad relations för vissa etapper, men också 
 lösa delar. Nu har jag skapat ytterligare relations för etapp 31-34 på samma 
 sätt som jag såg att det var gjort för andra.

Heja! :-)

  
 Nu finns referenser direkt från leden till vissa paths, och via 
 etapp-relations. Jag _tror_ att paths som ingår i etapp-relations bör tas 
 bort från 197845 men tänkte höra så jag inte gör fel? 

Ja, jag tycker i alla fall det är snyggast om varje enskilt bit är kopplad till 
topprelationen på exakt ett sätt; antigen via en etapprelation (snyggast) eller 
direkt. Dvs, precis vad jag tror du var på väg att göra. Eller kortare 
uttryckt: Låter bra! Fortsätt!

 -- Ture



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

Re: [Talk-se] Relationer och Sörmlandsleden

2014-04-29 Diskussionsfäden Claes Holmerson



 Ja, jag tycker i alla fall det är snyggast om varje enskilt bit är kopplad 
 till topprelationen på exakt ett sätt; antigen via en etapprelation 
 (snyggast) eller direkt. Dvs, precis vad jag tror du var på väg att göra. 
 Eller kortare uttryckt: Låter bra! Fortsätt!

Tänkte försöka mig på det men finns det något bra knep att hitta såna 
dubbelrefererade paths via sök i tex JOSM, för att sen lätt kunna ta bort dem? 
Det skulle kännas tryggare att hitta dem med hjälp av ett sök än att manuellt 
klicka och jämföra, följt av delete en efter en.


Claes

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

Re: [Talk-se] Relationer och Sörmlandsleden

2014-04-29 Diskussionsfäden bengt bäverman

Hejsan

Eftersom det är jag som knåpat ihop de flesta relationerna för
Sörmlandsleden så tänkte jag bara säga att det är väldigt tacksamt om
du fixar till de lösa bitarna som idag ligger i topprelationen så att
de ligger i respektive etapprelation där de rimligen borde finnas i.
Jag såg att det fanns en massa löst härom dagen, men har inte haft tid
att fixa det.  Gör det gärna. Hör gärna av dig om det är nått du
undrar över.

Något sätt att per automatik kontrollera om etapperna innehåller några
dubletter vet jag inte.

vänligen
   Bengt

Den 29 april 2014 23:00 skrev Claes Holmerson claespost-...@yahoo.se:


 Ja, jag tycker i alla fall det är snyggast om varje enskilt bit är kopplad 
 till topprelationen på exakt ett sätt; antigen via en etapprelation 
 (snyggast) eller direkt. Dvs, precis vad jag tror du var på väg att göra. 
 Eller kortare uttryckt: Låter bra! Fortsätt!

 Tänkte försöka mig på det men finns det något bra knep att hitta såna 
 dubbelrefererade paths via sök i tex JOSM, för att sen lätt kunna ta bort 
 dem? Det skulle kännas tryggare att hitta dem med hjälp av ett sök än att 
 manuellt klicka och jämföra, följt av delete en efter en.


 Claes

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

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

[Talk-es] Odd edits by Tino Pinilla

2014-04-29 Diskussionsfäden Paul Norman

I saw a number of odd edits by Tino Pinilla in Provincia de 
Barcelona, Catalunya, Spain, such as http://www.osm.org/changeset/21898498

The changeset has the tags created_by=Tino Pinilla and 
source=knowledge, and the ways have tags like CAS=VIA21.

The spacing of nodes is odd, and not what I'd expect to see.

Since that changeset, they've deleted other data and then retagged 
their ways with more conventional tags. Combined, it's very odd.

Could some local glance over what they've done? If necessary I can 
help, and if it becomes required I can undo all of their changes, 
but I'd rather not do that.


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

[Talk-ee] MTÜ liikmemaksud

2014-04-29 Diskussionsfäden Jaak Laineste (Nutiteq)

Tere,

Info MTÜ Avatud Maakaardi Selts liikmetele: liikmemaks 2014.a. eest on 10 EUR, 
selle palun kanda ülekandega:
 
Saaja: AVATUD MAAKAARDI SELTS 
Konto: EE971010220105782019
SEB pank
Summa: 10 EUR

Tärmin: 1. juuni 2014

Ette tänades,
Jaak
juhatuse nimel___
Talk-ee mailing list
Talk-ee@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ee

[Talk-at] place=locality

2014-04-29 Diskussionsfäden Stephan Bösch-Plepelits

Hi!

Ist Euch eigentlich schon aufgefallen, wie sehr die place=locality in Wien
(und möglicherweise auch anderswo?) derzeit wuchern? Laut OSM Wiki
beschreibt place=locality eine unbewohnte Örtlichkeit, Lokalität oder
Flur. Derer gibt es innerhalb des bebauten Wien wohl kaum.

Ich hab einen Overpass Query erstellt um das Problem zu verdeutlichen:
http://overpass-turbo.eu/s/3cK

Beispiele:
http://www.openstreetmap.org/node/264872644
  Der Carl-Szokoll-Platz. Viele Plätze in Wien sind als solche
  place=locality bezeichnet. Das ist genau das Problem, das ich vor einiger
  Zeit einmal auf der Mailingliste angesprochen hab, allerdings haben wir
  das nie fertig diskutiert. Siehe
  https://lists.openstreetmap.org/pipermail/talk-at/2012-December/005163.html

http://www.openstreetmap.org/node/319439963
  Verteilerkreis Favoriten? Nun, neighbourhood ist es keine. Keine Ahnung
  was man damit machen soll. Vermutlich fällt das eigentlich auch unter
  Platz?

http://www.openstreetmap.org/node/2202464214
  Das Schloßquadrat. Ein verbreitetes Problem, wo eher
  place=neighbourhood angebracht wäre. Ich werde mal ein bisschen Zeit
  damit verbringen solche Fälle zu verändern. (wenn ihr das lest, wird dies
  zum Teil schon passiert sein).

http://www.openstreetmap.org/node/685115:
  Was skurilles: Die Albertinapassage. Ich hab das gleich auf
  amenity=restaurant geändert. Hier wurde sogar einfach der Kreuzungspunkt
  von Ring und Opernstraße verwendet, inkl. layer=-1. Brr.
  Solche Beispiele gibt es aber einige, wo vermutlich dieses Tag verwendet
  wurde, damit es halt prominent auf der Karte steht.

Tja, vielleicht schaffen wir es ja gemeinsam dieses Problem ein wenig
einzudämmen ...

gruesse,
Stephan
-- 
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,-.
| Stephan Bösch-Plepelits,|
| Technische Universität Wien   -Studien Informatik  Raumplanung |
| Projects:   |
|  openstreetbrowser.org  couchsurfing.org  tubasis.at  bl.mud.at |
| Contact:|
|  Mail: sk...@xover.mud.at  Blog: plepe.at |
|  Twitter: twitter.com/plepe  Jabber: sk...@jabber.at  |
`-'

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

Re: [Talk-at] place=locality

2014-04-29 Diskussionsfäden Friedrich Volkmann

On 29.04.2014 22:06, Stephan Bösch-Plepelits wrote:
 Ist Euch eigentlich schon aufgefallen, wie sehr die place=locality in Wien
 (und möglicherweise auch anderswo?) derzeit wuchern? Laut OSM Wiki
 beschreibt place=locality eine unbewohnte Örtlichkeit, Lokalität oder
 Flur. Derer gibt es innerhalb des bebauten Wien wohl kaum.

Wo du die Definition schon ansprichst... In NÖ gibt es etliche
place=locality Nodes mit population0, für Rotten/Katastralgemeinden/dgl. -
Die meisten gehören wohl auf place=hamlet geändert, unklar ist mitunter die
Lage. (Wo ist der Ortskern einer Streusiedlung?)

   Verteilerkreis Favoriten? Nun, neighbourhood ist es keine. Keine Ahnung
   was man damit machen soll. Vermutlich fällt das eigentlich auch unter
   Platz?

Als Favoritner, der sein halbes Leben in der Umgebung des Verteilerkreises
verbracht hat, verstehe ich darunter den Kreisverkehr, also den Straßennamen
des highway=primary + junction=roundabout. Der ist jetzt mit name=Altes
Landgut getaggt - meiner Meinung nach genau verkehrt. Altes Landgut wäre
richtig place=locality, wobei dieser Name sowieso schon lang nicht mehr
gebräuchlich ist, außer im Namen der Haltestelle.

Am Kreisverkehr fehlt übrigens auch das ref=* - fragt sich nur ob B16 oder B225.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-at] place=locality

2014-04-29 Diskussionsfäden Ondřej Hošek

2014-04-29 23:17 GMT+02:00 Friedrich Volkmann b...@volki.at:

 On 29.04.2014 22:06, Stephan Bösch-Plepelits wrote:
Verteilerkreis Favoriten? Nun, neighbourhood ist es keine. Keine Ahnung
was man damit machen soll. Vermutlich fällt das eigentlich auch unter
Platz?

 Als Favoritner, der sein halbes Leben in der Umgebung des Verteilerkreises
 verbracht hat, verstehe ich darunter den Kreisverkehr, also den
 Straßennamen
 des highway=primary + junction=roundabout. Der ist jetzt mit name=Altes
 Landgut getaggt - meiner Meinung nach genau verkehrt. Altes Landgut wäre
 richtig place=locality, wobei dieser Name sowieso schon lang nicht mehr
 gebräuchlich ist, außer im Namen der Haltestelle.


Laut wien.at-Stadtplan ist Altes Landgut jedoch noch immer der
behördliche Name der Verkehrsfläche (des Kreisverkehrs sowie seiner
Sekante), Verteilerkreis Favoriten dann die deskriptivistische
Bezeichnung, die ziemlich stark auf seine Rolle als Südosttangente-Ausfahrt
anspielt. Ich weiß nicht, ob am Kreisverkehr oder der Querstraße
Straßennamensschilder aufgestellt sind; ein Besuch wäre im Interesse der
ground truth sicher empfehlenswert.

Ich finde es auf jeden Fall sinnvoll, Verteilerkreis Favoriten zu den
Namen des Kreisverkehrs dazuzunehmen; welcher nun der Primär- und welcher
der alternative Name ist, müssen wir wohl noch ausdiskutieren.

Liebe Grüße,
~~ Ondra
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-cat] Proposta etiquetatge carreteres i proposta portal

2014-04-29 Diskussionsfäden Jan Esquerra

Bon dia,

com alguns ja us imagineu, jo estic més en la línia d'en Fermí i en Mateu
que no pas la que proposen l'Hèctor i en Carlos. Però amb matisos.

Estic totalment en desacord amb que el primer criteri per decidir la
categoria (highway) siguin característiques constructives/tècniques com
l'amplada, els vorals, núm. de carrils, velocitats, etc. Per alguns
d'aquests conceptes ja hi ha la seva etiqueta específica (i pels que no la
tenen encara, ens la podem inventar).

Però no veig del tot malament tenir en compte les característiques
constructives per decantar-nos una categoria amunt o avall en casos
concrets on hi hagi dubtes o controvèrsia. Al cap i a la fi el mapa ha de
ser útil, per exemple, per escollir ruta, ja sigui mirant els colors o amb
algorismes d'enrutament.
Però cal evitar de totes totes els canvis de categoria a trams en mig del
recorregut que no té cap ni peus que una carretera perdi importància en mig
del no res (per mapes de colorins ja tenim
http://www.itoworld.com/map/group/2).

Tampoc crec que ens hàgim de cenyir estrictament al què estableixen
oficialment les administracions (mitjançant els catàlegs, nomenclatures i
colors de la senyalització), que en ocasions està lluny de la realitat o
basat en previsió d'actuacions futures que potser no seran, ni establir
l'ordre en funció de qui té les competències. Estem fent el mapa oficial de
les administracions? Si de cas aquesta categorització oficial ens pot
servir d'ajuda, referència o punt de partida, però no és dogma.

Pel què entenc de la definició a
http://wiki.openstreetmap.org/wiki/Key:highway la categoria depèn d'un
ordre jeràrquic d'importància, però passa sovint que, en una jerarquia,
estar més amunt no necessàriament vol dir ser millor.

Conyes a banda, a la pàgina en anglès comença l'ordre jeràrquic per la més
important i va baixant, que fent una analogia seria com un arbre: tronc,
branca gruixuda, branca no tant gruixuda, ..., branquilló. Pensat així
podem tenir en un mateix bosc i de costat, un roure centenari amb un senyor
tronc i branques de campionat, i un roure jove i esprimatxat. En ambdós el
tronc és el tronc, les primeres branques que es ramifiquen són les
primeres, etc., però és evident que un tronc amb l'altre no tenen res a
veure.

Donant-li voltes al tema, se m'ha acudit capgirar l'ordre i començar de
baix a dalt, el que seria fer l'analogia amb un riu. Comença amb rierols,
que s'ajunten per formar un riuet, que va a parar a un riu més gran, etc.
Així podem tenir un riu com la Muga que recull quatre riuets i 16 rierols,
creua una comarca i va a petar al mar, o un senyor riu com l'Ebre que abans
d'arribar al mar a creuat mitja península i ha recollit aigua d'un munt de
rius, riuets i rierols. D'aquesta manera quan parlem de rierol, a tots ens
ve el cap si fa no fa el mateix tant si correspon a la conca de la Muga o a
la de l'Ebre. Però podem diferenciar perfectament un riu d'un mega riu. Amb
altres tags (amplada, cabal ...) podem acabar d'afinar, perquè ja us dic jo
que no és el mateix la Muga que la Noguera Pallaresa.

És una idea.

- tertiary: uneix pobles petits entre sí i aquests amb altres carreteres
més importants
- secondary: uneix pobles grans, ciutats petites entre sí, i amb altres
carreteres més importants
- primary: uneix ciutats entre sí, i aquestes amb carreteres més importants,
- trunk: la més important de totes que no reuneix les característiques per
ser autopista/autovia, uneix grans ciutats, vertebra el territori

- motorway: per autopistes i autovies exclusivament, perquè la definició
implica unes característiques tècniques, constructives i d'ús legal, que no
totes les carreteres compleixen per molt que ho pugui semblar.

A banda del debat de quin criteri fer servir, penso que estaria bé obrir
algun un espai de discussió amb exemples concrets de carreteres que porten
controvèrsia amb propostes i argumentacions de la categoria que cadascú li
donaria. Potser ens en faríem creus de que els punts de vista no estan tant
allunyats (o sí).

Salut

Jan

PD. la guerra de canvis de categoria és tal, que hi ha carreteres que en un
zoom es veuen d'un color i en un altre zoom d'un altre. El Mapnik no dóna a
l'abast!!!
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [Talk-cat] layer + trobada + no digest

2014-04-29 Diskussionsfäden yo paseopor

M'ha agradat molt el resum
http://wiki.openstreetmap.org/wiki/Pyr%C3%A9n%C3%A9es-Orientales#Rassemblement_.C3.A0_Sarri.C3.A0_de_Ter_le_5_avril_2014així
que voto per traduir-lo ;)

salut i mapes
yopaseopor


2014-04-28 22:20 GMT+02:00 Felip Manyer i Ballester fe...@openstreetmap.cat
:

 El 28/04/14 21:07, en/na Simó Albert i Beltran ha escrit:
  franc...@eclipso.eu writes:
   off topic: Algú podria fer cinc cèntims de la trobada de Sarrià de Ter?
 
  Hi ha un extens resum al wiki:
 
 http://wiki.openstreetmap.org/wiki/WikiProject_Catalan/Trobades#Resum_de_la_reuni.C3.B3_a_Sarri.C3.A0_de_Ter
 I tant, un extens resum de dos punts que deixa tota la llibertat a la
 capacitat d'interpretació del lector :-) Jo en vaig fer un resumet en
 franximà pels meus col·legues del Nord :

 http://wiki.openstreetmap.org/wiki/Pyr%C3%A9n%C3%A9es-Orientales#Rassemblement_.C3.A0_Sarri.C3.A0_de_Ter_le_5_avril_2014
 Si penseu que té un interès, podeu inspirar-vos-en.

 --
 Atentament,

 Felip.

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

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

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

2014-04-29 Diskussionsfäden Marián Kyral

Ještě bych Petra doplnil:

Petr udělal vizualizaci dat v RUIAN na http://ruian.poloha.net
(http://ruian.poloha.net). Stačí si vpravo nahoře zapnout vrstvu budov. 
Podklad je OSM. Tato vrstva je také zobrazitelná v editoru JOSM, kde můžeme 
porovnat satelitní foto, KM a RUIAN. Pár ilustračních příkladů přikládám. 
Růžová je RUIAN, barevné čáry KM a podklad je Bing Sat.

Tady je třeba jeden dvůr jako budova: http://kyralovi.cz/tmp/josm/dvur_jako_
budova.png

A příklad chybějících budov: http://kyralovi.cz/tmp/josm/chybejici_budovy.
png
(bohužel se zatím nedá odkazovat přímo). Toto místo je Frýdek-Místek, 
sídliště Slezská: 49°40'41.195N, 18°21'52.831E
Chybí školní budovy bez č.p.. Chybějící vchody do panelových domů ve 
skutečnosti nechybí, jen jsou všechny na stejném místě.

Další problém, na který docela často narážíme, je že v KM je přes budovu 
nějaká čára (hranice KM, vedení...) a následkem toho je v RUIAN budova buď 
nekompletní, nebo rozdělená na více kousků.
http://kyralovi.cz/tmp/josm/nekompletni_budova.png

Případně je řada garáží ve které jedna garáž chybí (ale v KM je)
http://kyralovi.cz/tmp/josm/dira_v_rade_garazi.png

Marián


-- Původní zpráva --
Od: Petr Vejsada o...@propsychology.cz
Komu: talk-cz@openstreetmap.org
Datum: 27. 4. 2014 18:48:00
Předmět: Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

Dobrý den,

děkujeme za odezvu, pokusím se sepsat aktuální problémy.

- definiční bod jednoho stavebního objektu uvnitř hranic jiného stavebního 
objektu. Stavební objekt A má definiční bod i hranice. Stavební objekt B má 
pouze definiční bod, který leží uvnitř polygonu hranic stavebního objektu A.

Oba objekty A i B mají své adresní místo (adresní místa), která jsou 
vzájemně 
nepodobná či jsou naopak zvláštně podobná. Například jeden stavební objekt 
má 
adresní místo s č.ev. 45 a druhý s č.ev. 1045. Domnívám se, že jde o nějakou

systematickou chybu. Vyskytuje se to různých KÚ a budou to řádově desítky 
tisíc případů. Mohu vytvořit automaticky seznam takovýchto dvojic stavebních

objektů. Myslím si, že jeden z těch stavebních objektů reálně neexistuje, 
nemám však možnost zjistit, který to je. Nevím, zda adresní místo má být č.
ev. 
45 nebo č.ev. 1045. To je asi současný největší problém.

Dále můžeme provést nějakou základní kontrolu umístění adresních míst. Co se

stává:

- adresní místo leží úplně mimo katastrální území. Rekord, co jsem viděl, 
bylo 
 asi 56 kilometrů mimo.

- adresní místo je velmi daleko od stavebního objektu, ke kterému náleží; až

několik kilometrů.

- adresní místo, které má ulici, je velmi daleko od této ulice, případně 
taková ulice v dosahu několika kilometrů vůbec neexistuje. Možná chybí 
definiční čára ulice, možná je adresní místo úplně mimo.

Toto jsou problémy, které lze více-méně zjistit vhodným dotazem z aktuální 
databáze.

Pak se vyskytují případy, kdy několik stavebních objektů má stejnou 
geometrii 
a asi i stejný definiční bod. Typicky jde o panelový dům např. s pěti 
vchody, 
vedený jako 5 stavebních objektů. V RÚIAN je je těchto pět stavebních 
objektů, 
ale leží na sobě, místo toho, aby ležely vedle sebe.

Dále je to záměna volnéjho prostoru a stavebního objektu. Tam, kde je ve 
skutečnosti nádvoří, je v RÚIAN stavební objekt a tam, kde je ve skutečnosti

stavební objekt, v RÚIAN není. 51247984 je odstrašujícím případem takového 
stavebního objektu. Toto neumím zjistit automaticky s dostatečnou 
spolehlivostí, toto by se muselo hlásit individuálně.

Myslím, že toto pro začátek bohatě stačí a že to přináší práce více než 
dost. 
Těším se na odezvu a třeba nějaký návrh, jak dá postupovat/spolupracovat.

--
S pozdravem
Petr Vejsada

Dne Pá 25. dubna 2014 21:59:53, Petr Souček napsal(a):

 Dobrý večer,
 
 nejdříve bych Vás chtěl ujistit, že ČÚZK jako správce jednoho ze 
základních
 registrů RÚIAN má určitě zájem o zpětnou vazbu od uživatelů. Je to jeden 
ze
 způsobů, jak zkvalitňovat data RÚIAN. Rádi od Vás vaše připomínky,
 reklamace převezmeme a budeme se snažit je ověřit a opravit. 
 Chtěl bych se zeptat o reklamaci jakých údajů uvažujete?
 - o definiční body adresních míst
 - o definiční body stavebních objektů
 - o definiční body parcel
 - existenci adresních míst, stavebních objektů
 - atd.
 
 V současné době připravujeme automatizovanou linku na příjem a distribuci
 reklamací některých údajů. V obdobné podobě jako u definičních bodů parcel
 a budov, které se vedou v ISKN, viz
 http://data.cuzk.cz/defbod/reklamace.php. V těchto případech jsou údaje
 předávány na příslušné katastrální pracoviště (dnes jich je celkem 97 v
 celé republice), které ji řeší. V případě dalších údajů vedených v RÚIAN
 (adresní místa, stavební objekty, atd.) to bude trošku složitější, neboť
 reklamace budou řešit editoři těchto údajů, kterými jsou stavební úřady a
 obce. 
 Rozhodně nám jde o to, abychom data získali ve strukturované podobě, např.
v
 XML. 
 Pěkný víkend přeje
 
 Petr Souček
 
 ---
 Ing. Petr Souček, Ph.D.
 Český úřad zeměměřický a katastrální

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

2014-04-29 Diskussionsfäden Jachym Cepicky

Pánové, 

díky všem za pozitivní zpětnou vazbu. V původním vláknu se navrhovalo, aby se
vytvořilo nějaké strukturované XML obsahující tyto chyby. Má-li mít naše
spolupráce s ČUZK opravdu nějaký smysl, musí z nás vypadnout tohle. Na ČUZK jsou
lidi šikovní, kteří se XML souboru nezaleknou a už si to rosparserují sami. Ale
slovní popis problémů nebo obrázky neřku-li odkaz na JOSM není to, co by jim
pomohlo.

Chystá se někdo, dát dohromady nějaký XML soubor s chybama?

Dík

Jachym

On Tue, Apr 29, 2014 at 09:47:42AM +0200, Marián Kyral wrote:
Ještě bych Petra doplnil:
 
Petr udělal vizualizaci dat v RUIAN na [1]http://ruian.poloha.net. Stačí
si vpravo nahoře zapnout vrstvu budov. Podklad je OSM. Tato vrstva je také
zobrazitelná v editoru JOSM, kde můžeme porovnat satelitní foto, KM a
RUIAN. Pár ilustračních příkladů přikládám. Růžová je RUIAN, barevné čáry
KM a podklad je Bing Sat.
 
Tady je třeba jeden dvůr jako budova:
http://kyralovi.cz/tmp/josm/dvur_jako_budova.png
 
A příklad chybějících budov:
http://kyralovi.cz/tmp/josm/chybejici_budovy.png
(bohužel se zatím nedá odkazovat přímo). Toto místo je Frýdek-Místek,
sídliště Slezská: 49°40'41.195N, 18°21'52.831E
Chybí školní budovy bez č.p.. Chybějící vchody do panelových domů ve
skutečnosti nechybí, jen jsou všechny na stejném místě.
 
Další problém, na který docela často narážíme, je že v KM je přes budovu
nějaká čára (hranice KM, vedení...) a následkem toho je v RUIAN budova buď
nekompletní, nebo rozdělená na více kousků.
http://kyralovi.cz/tmp/josm/nekompletni_budova.png
 
Případně je řada garáží ve které jedna garáž chybí (ale v KM je)
http://kyralovi.cz/tmp/josm/dira_v_rade_garazi.png
 
Marián
 
-- Původní zpráva --
Od: Petr Vejsada o...@propsychology.cz
Komu: talk-cz@openstreetmap.org
Datum: 27. 4. 2014 18:48:00
Předmět: Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM
 
  Dobrý den,
 
  děkujeme za odezvu, pokusím se sepsat aktuální problémy.
 
  - definiční bod jednoho stavebního objektu uvnitř hranic jiného
  stavebního
  objektu. Stavební objekt A má definiční bod i hranice. Stavební objekt B
  má
  pouze definiční bod, který leží uvnitř polygonu hranic stavebního
  objektu A.
  Oba objekty A i B mají své adresní místo (adresní místa), která jsou
  vzájemně
  nepodobná či jsou naopak zvláštně podobná. Například jeden stavební
  objekt má
  adresní místo s č.ev. 45 a druhý s č.ev. 1045. Domnívám se, že jde o
  nějakou
  systematickou chybu. Vyskytuje se to různých KÚ a budou to řádově
  desítky
  tisíc případů. Mohu vytvořit automaticky seznam takovýchto dvojic
  stavebních
  objektů. Myslím si, že jeden z těch stavebních objektů reálně
  neexistuje,
  nemám však možnost zjistit, který to je. Nevím, zda adresní místo má být
  č.ev.
  45 nebo č.ev. 1045. To je asi současný největší problém.
 
  Dále můžeme provést nějakou základní kontrolu umístění adresních míst.
  Co se
  stává:
 
  - adresní místo leží úplně mimo katastrální území. Rekord, co jsem
  viděl, bylo
   asi 56 kilometrů mimo.
 
  - adresní místo je velmi daleko od stavebního objektu, ke kterému
  náleží; až
  několik kilometrů.
 
  - adresní místo, které má ulici, je velmi daleko od této ulice, případně
  taková ulice v dosahu několika kilometrů vůbec neexistuje. Možná chybí
  definiční čára ulice, možná je adresní místo úplně mimo.
 
  Toto jsou problémy, které lze více-méně zjistit vhodným dotazem z
  aktuální
  databáze.
 
  Pak se vyskytují případy, kdy několik stavebních objektů má stejnou
  geometrii
  a asi i stejný definiční bod. Typicky jde o panelový dům např. s pěti
  vchody,
  vedený jako 5 stavebních objektů. V RÚIAN je je těchto pět stavebních
  objektů,
  ale leží na sobě, místo toho, aby ležely vedle sebe.
 
  Dále je to záměna volnéjho prostoru a stavebního objektu. Tam, kde je ve
  skutečnosti nádvoří, je v RÚIAN stavební objekt a tam, kde je ve
  skutečnosti
  stavební objekt, v RÚIAN není. 51247984 je odstrašujícím případem
  takového
  stavebního objektu. Toto neumím zjistit automaticky s dostatečnou
  spolehlivostí, toto by se muselo hlásit individuálně.
 
  Myslím, že toto pro začátek bohatě stačí a že to přináší práce více než
  dost.
  Těším se na odezvu a třeba nějaký návrh, jak dá
  postupovat/spolupracovat.
 
  --
  S pozdravem
  Petr Vejsada
 
  Dne Pá 25. dubna 2014 21:59:53, Petr Souček napsal(a):
 
   Dobrý večer,
  
   nejdříve bych Vás chtěl ujistit, že ČÚZK jako správce jednoho ze
  základních
   registrů RÚIAN má určitě zájem o zpětnou vazbu od uživatelů. Je to
  jeden ze
   způsobů, jak zkvalitňovat data RÚIAN. Rádi od Vás vaše připomínky,
   reklamace převezmeme a

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

2014-04-29 Diskussionsfäden Marián Kyral

Oba emaily byly v reakcí na:

  Rádi od Vás vaše připomínky,
  reklamace převezmeme a budeme se snažit je ověřit a opravit.
  Chtěl bych se zeptat o reklamaci jakých údajů uvažujete?
  - o definiční body adresních míst
  - o definiční body stavebních objektů
  - o definiční body parcel
  - existenci adresních míst, stavebních objektů
  - atd.
 

Jedná se o úvod a očekávám další diskuzi. Různé typy chyb budou vyžadovat 
různé postupy. 
1) Chyby dohledatelné vhodným dotazem do databáze:
  Pro Petra není problém vytáhnout z databáze potřebná data buď jako csv, 
nebo zabalené do xml. Jde o to, dohodnout se na formátu a adrese kam to 
poslat.

2) Chyby strojově nedohledatelné - (dvůr jako budova, nekompletní budova, 
chybějící budova...)
  Tady bych si představoval nějaký plugin do JOMS, buď samostatný, nebo jako
součást pointinfo. Opět je třeba dohodnout:
- jaký formát
- kam odesílat
- podobu toho pluginu

Moje představa:
* V menu JOSM vyberu volnu Nahlásit chybu do RUIAN
* Kliknu na místo chyby
* Otevře se nějaký průvodce, kde vyberu typ chyby.
* Dle typu chyby se z RUIAN dotáhnou relevantní objekty v okolí
* Označím 0 až X objektů, kterých se tato chyba týká
* Vyplním detaily problému
* Odešlu

V odeslaném hlášení bude jako zdroj uveden projekt Openstreetmap (talk-cz?) 
a kontaktní osoba bude OSM ID uživatele (plus jeho email?).
Připadně by se mohly všechny takto vygenerované chyby zároveň poslat do talk
-cz nebo, pokud jich bude moc, tak do nějaké nové specializované konference,
ať to tady nezaplevelíme.

Byl by pak přehled, kdo, co a kdy nahlásil.




Ono ideální by asi byl nějaký systém na evidenci požadavků (ala Trac, 
Bugzila), ale to asi nebude reálné.




Jak to vidíte? Návrhy a připomínky vítány. Pokusím se spíchnout nějaké demo,
ale poslední dobou se času moc nedostává :-(




Marián





-- Původní zpráva --
Od: Jachym Cepicky jachym.cepi...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 29. 4. 2014 12:43:13
Předmět: Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

Pánové, 

díky všem za pozitivní zpětnou vazbu. V původním vláknu se navrhovalo, aby 
se
vytvořilo nějaké strukturované XML obsahující tyto chyby. Má-li mít naše
spolupráce s ČUZK opravdu nějaký smysl, musí z nás vypadnout tohle. Na ČUZK 
jsou
lidi šikovní, kteří se XML souboru nezaleknou a už si to rosparserují sami. 
Ale
slovní popis problémů nebo obrázky neřku-li odkaz na JOSM není to, co by jim
pomohlo.

Chystá se někdo, dát dohromady nějaký XML soubor s chybama?

Dík

Jachym

On Tue, Apr 29, 2014 at 09:47:42AM +0200, Marián Kyral wrote:
 Ještě bych Petra doplnil:
 
 Petr udělal vizualizaci dat v RUIAN na [1]http://ruian.poloha.net. Stačí
 si vpravo nahoře zapnout vrstvu budov. Podklad je OSM. Tato vrstva je také
 zobrazitelná v editoru JOSM, kde můžeme porovnat satelitní foto, KM a
 RUIAN. Pár ilustračních příkladů přikládám. Růžová je RUIAN, barevné čáry
 KM a podklad je Bing Sat.
 
 Tady je třeba jeden dvůr jako budova:
 http://kyralovi.cz/tmp/josm/dvur_jako_budova.png
 
 A příklad chybějících budov:
 http://kyralovi.cz/tmp/josm/chybejici_budovy.png
 (bohužel se zatím nedá odkazovat přímo). Toto místo je Frýdek-Místek,
 sídliště Slezská: 49°40'41.195N, 18°21'52.831E
 Chybí školní budovy bez č.p.. Chybějící vchody do panelových domů ve
 skutečnosti nechybí, jen jsou všechny na stejném místě.
 
 Další problém, na který docela často narážíme, je že v KM je přes budovu
 nějaká čára (hranice KM, vedení...) a následkem toho je v RUIAN budova buď
 nekompletní, nebo rozdělená na více kousků.
 http://kyralovi.cz/tmp/josm/nekompletni_budova.png
 
 Případně je řada garáží ve které jedna garáž chybí (ale v KM je)
 http://kyralovi.cz/tmp/josm/dira_v_rade_garazi.png
 
 Marián
 
 -- Původní zpráva --
 Od: Petr Vejsada o...@propsychology.cz
 Komu: talk-cz@openstreetmap.org
 Datum: 27. 4. 2014 18:48:00
 Předmět: Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM
 
 Dobrý den,
 
 děkujeme za odezvu, pokusím se sepsat aktuální problémy.
 
 - definiční bod jednoho stavebního objektu uvnitř hranic jiného
 stavebního
 objektu. Stavební objekt A má definiční bod i hranice. Stavební objekt B
 má
 pouze definiční bod, který leží uvnitř polygonu hranic stavebního
 objektu A.
 Oba objekty A i B mají své adresní místo (adresní místa), která jsou
 vzájemně
 nepodobná či jsou naopak zvláštně podobná. Například jeden stavební
 objekt má
 adresní místo s č.ev. 45 a druhý s č.ev. 1045. Domnívám se, že jde o
 nějakou
 systematickou chybu. Vyskytuje se to různých KÚ a budou to řádově
 desítky
 tisíc případů. Mohu vytvořit automaticky seznam takovýchto dvojic
 stavebních
 objektů. Myslím si, že jeden z těch stavebních objektů reálně
 neexistuje,
 nemám však možnost zjistit, který to je. Nevím, zda adresní místo má být
 č.ev.
 45 nebo č.ev. 1045. To je asi současný největší problém.
 
 Dále můžeme provést nějakou základní kontrolu umístění adresních míst.
 Co se
 stává:
 
 - adresní místo leží úplně mimo

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

2014-04-29 Diskussionsfäden Petr Vejsada

Ahoj,

ano, přesně tak jsem to myslel. Slovní popis a tvoje obrázky měly představit 
charakter chyb a teď čekám, že pan Souček napíše, jak tedy máme chyby hlásit.

Ano, myslím, že mohu udělat automatický report těch duchů uvnitř budovy a s 
tím souvisejících, respektive podobných chyb.

Ad čas - na to, jaký je to žrout času si 'stěžuji' dost často, ale problém je, 
že mě to celkem baví. Myslím tedy, že i naši spolupráci s ČÚZK bychom měli tak 
trochu limitovat - jedna věc je hlášení chyb a vzájemná pomoc, jiná věc je 
dělat práci za ně. IMO by mělo úplně stačit třeba ohlásit, že SO XY ohraničuje 
dvůr a nikoli budovu. Vypracovat správnou geometrii a poslat ji na ČÚZK v XML 
už mi připadá opravdu moc. Nebráním se tomu, ale to už opravdu přesahuje rámec 
výpomoci, takže DPP nebo fakturky by to mohly spravit. Ostatní samozřejmě 
mohou pomáhat, jak uznají za vhodné ;-)

Praha-Smíchov, Kováků číslo orientační 30. To je jen příklad.

Stačí prostudovat celý Palác Křižík II, nákupní centrum Nový Smíchov, Multkino 
Cinestar Anděl, je to tam samý duch, to je máme vypisovat všechny?

Vypadá to, že u těch zdvojených SO má vždy jeden z nich minimum údajů, kdežto 
ten druhý je kompletní (počet bytů, pater atd.). Někde bude chyba v tom, že se 
z databáze nemažou. Jsou to IMO historická data a jen se tváří jako aktuální. 
Pokud to tak je, tak by měl ČÚZK přijít na podstatu té chyby, odstranit ji a 
tím by byl snad tento největší problém vyřešen a pak už bychom mohli 
reportovat ty jednotlivosti.

Jako typ chyby bych určitě uvažoval 'Opilost zaměstnanců stavebního odboru 
obce', protože jak tam někteří mrskají ty adresní body, to se dá těžko 
vysvětlit jinak ;-).

Ten reportovací systém bych nějak maximálně zjednodušil, ID objektu, ID typu 
chyby, text, třeba jako nějaký PHP skript přes web. Bugzilla, Mantis atd. 
samozřejmě zprovoznit můžeme, ale je to IMO zbytečné. Počkal bych, zda se pan 
Souček vyjádří a uvidíme, co by vlastně bylo pro ČÚZK od nás přínosné.


Dne Út 29. dubna 2014 14:46:12, Marián Kyral napsal(a):

 Oba emaily byly v reakcí na:
   Rádi od Vás vaše připomínky,
   reklamace převezmeme a budeme se snažit je ověřit a opravit.
   Chtěl bych se zeptat o reklamaci jakých údajů uvažujete?
   - o definiční body adresních míst
   - o definiční body stavebních objektů
   - o definiční body parcel
   - existenci adresních míst, stavebních objektů
   - atd.
 
 Jedná se o úvod a očekávám další diskuzi. Různé typy chyb budou vyžadovat
 různé postupy.
 1) Chyby dohledatelné vhodným dotazem do databáze:
   Pro Petra není problém vytáhnout z databáze potřebná data buď jako csv,
 nebo zabalené do xml. Jde o to, dohodnout se na formátu a adrese kam to
 poslat.
 
 2) Chyby strojově nedohledatelné - (dvůr jako budova, nekompletní budova,
 chybějící budova...)
   Tady bych si představoval nějaký plugin do JOMS, buď samostatný, nebo jako
 součást pointinfo. Opět je třeba dohodnout:
 - jaký formát
 - kam odesílat
 - podobu toho pluginu
 
 Moje představa:
 * V menu JOSM vyberu volnu Nahlásit chybu do RUIAN
 * Kliknu na místo chyby
 * Otevře se nějaký průvodce, kde vyberu typ chyby.
 * Dle typu chyby se z RUIAN dotáhnou relevantní objekty v okolí
 * Označím 0 až X objektů, kterých se tato chyba týká
 * Vyplním detaily problému
 * Odešlu
 
 V odeslaném hlášení bude jako zdroj uveden projekt Openstreetmap (talk-cz?)
 a kontaktní osoba bude OSM ID uživatele (plus jeho email?).
 Připadně by se mohly všechny takto vygenerované chyby zároveň poslat do talk
 -cz nebo, pokud jich bude moc, tak do nějaké nové specializované
 konference, ať to tady nezaplevelíme.
 
 Byl by pak přehled, kdo, co a kdy nahlásil.
 
 
 
 
 Ono ideální by asi byl nějaký systém na evidenci požadavků (ala Trac,
 Bugzila), ale to asi nebude reálné.
 
 
 
 
 Jak to vidíte? Návrhy a připomínky vítány. Pokusím se spíchnout nějaké demo,
 ale poslední dobou se času moc nedostává :-(
 
 
 
 
 Marián
 
 
 
 
 
 -- Původní zpráva --
 Od: Jachym Cepicky jachym.cepi...@gmail.com
 Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
 Datum: 29. 4. 2014 12:43:13
 Předmět: Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM
 
 Pánové,
 
 díky všem za pozitivní zpětnou vazbu. V původním vláknu se navrhovalo, aby
 se
 vytvořilo nějaké strukturované XML obsahující tyto chyby. Má-li mít naše
 spolupráce s ČUZK opravdu nějaký smysl, musí z nás vypadnout tohle. Na ČUZK
 jsou
 lidi šikovní, kteří se XML souboru nezaleknou a už si to rosparserují sami.
 Ale
 slovní popis problémů nebo obrázky neřku-li odkaz na JOSM není to, co by jim
 pomohlo.
 
 Chystá se někdo, dát dohromady nějaký XML soubor s chybama?
 
 Dík
 
 Jachym
 
 On Tue, Apr 29, 2014 at 09:47:42AM +0200, Marián Kyral wrote:
  Ještě bych Petra doplnil:
  
  Petr udělal vizualizaci dat v RUIAN na [1]http://ruian.poloha.net. Stačí
  si vpravo nahoře zapnout vrstvu budov. Podklad je OSM. Tato vrstva je také
  zobrazitelná v editoru JOSM, kde můžeme porovnat satelitní foto, KM a
  RUIAN. Pár ilustračních

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

2014-04-29 Diskussionsfäden Jachym Cepicky

Absolutně souhlasím. My děláme Open Data, ČUZK dělá Státní mapové dílo spol.
Tím, že do toho přispějeme z toho bezprostředně moc nic nemáme. Když přispějeme
do OSM, tak z toho zpětně profituje celá komunita.

Na druhou stranu, je to příležitost, jak být uznaní jistou částí české
geo-komunity. Někdo z vás by možná řekl, že o uznání nestojí, ale já myslím, že
dlouhodobá pozitiva převládají.

Takže souhlasím s tím, že report typu zde je chyba bohatě stačí. Ani nejsme
ta správná autorita na správnou opravu.

Abych se ujistil: z naší strany se teď čeká na ČUZK, aby vydefinoval základní
strukturu XML, které my budeme produkovat?

Jachym

P.S. Píšu my, ale všichni víte, že v tom nic nedělám. Vážím si vaší práce a
snažím se ji alespoň podporovat a propagovat ven, skromě se počítám za člena
komunity, byť pasivního. Díky za vaši práci!

On Tue, Apr 29, 2014 at 08:30:55PM +0200, Petr Vejsada wrote:
Ahoj,

ano, přesně tak jsem to myslel. Slovní popis a tvoje obrázky měly představit
charakter chyb a teď čekám, že pan Souček napíše, jak tedy máme chyby hlásit.

Ano, myslím, že mohu udělat automatický report těch duchů uvnitř budovy a s
tím souvisejících, respektive podobných chyb.

Ad čas - na to, jaký je to žrout času si 'stěžuji' dost často, ale problém
je,
že mě to celkem baví. Myslím tedy, že i naši spolupráci s ČÚZK bychom měli
tak
trochu limitovat - jedna věc je hlášení chyb a vzájemná pomoc, jiná věc je
dělat práci za ně. IMO by mělo úplně stačit třeba ohlásit, že SO XY
ohraničuje
dvůr a nikoli budovu. Vypracovat správnou geometrii a poslat ji na ČÚZK v XML
už mi připadá opravdu moc. Nebráním se tomu, ale to už opravdu přesahuje
rámec
výpomoci, takže DPP nebo fakturky by to mohly spravit. Ostatní samozřejmě
mohou pomáhat, jak uznají za vhodné ;-)

Praha-Smíchov, Kováků číslo orientační 30. To je jen příklad.

Stačí prostudovat celý Palác Křižík II, nákupní centrum Nový Smíchov,
Multkino
Cinestar Anděl, je to tam samý duch, to je máme vypisovat všechny?

Vypadá to, že u těch zdvojených SO má vždy jeden z nich minimum údajů, kdežto
ten druhý je kompletní (počet bytů, pater atd.). Někde bude chyba v tom, že
se
z databáze nemažou. Jsou to IMO historická data a jen se tváří jako aktuální.
Pokud to tak je, tak by měl ČÚZK přijít na podstatu té chyby, odstranit ji a
tím by byl snad tento největší problém vyřešen a pak už bychom mohli
reportovat ty jednotlivosti.

Jako typ chyby bych určitě uvažoval 'Opilost zaměstnanců stavebního odboru
obce', protože jak tam někteří mrskají ty adresní body, to se dá těžko
vysvětlit jinak ;-).

Ten reportovací systém bych nějak maximálně zjednodušil, ID objektu, ID typu
chyby, text, třeba jako nějaký PHP skript přes web. Bugzilla, Mantis atd.
samozřejmě zprovoznit můžeme, ale je to IMO zbytečné. Počkal bych, zda se pan
Souček vyjádří a uvidíme, co by vlastně bylo pro ČÚZK od nás přínosné.

Dne Út 29. dubna 2014 14:46:12, Marián Kyral napsal(a):

Oba emaily byly v reakcí na:
Rádi od Vás vaše připomínky,
reklamace převezmeme a budeme se snažit je ověřit a opravit.
Chtěl bych se zeptat o reklamaci jakých údajů uvažujete?
- o definiční body adresních míst
- o definiční body stavebních objektů
- o definiční body parcel
- existenci adresních míst, stavebních objektů
- atd.

Jedná se o úvod a očekávám další diskuzi. Různé typy chyb budou vyžadovat
různé postupy.
1) Chyby dohledatelné vhodným dotazem do databáze:
Pro Petra není problém vytáhnout z databáze potřebná data buď jako csv,
nebo zabalené do xml. Jde o to, dohodnout se na formátu a adrese kam to
poslat.

2) Chyby strojově nedohledatelné - (dvůr jako budova, nekompletní budova,
chybějící budova...)
Tady bych si představoval nějaký plugin do JOMS, buď samostatný, nebo jako
součást pointinfo. Opět je třeba dohodnout:
- jaký formát
- kam odesílat
- podobu toho pluginu

Moje představa:
* V menu JOSM vyberu volnu Nahlásit chybu do RUIAN
* Kliknu na místo chyby
* Otevře se nějaký průvodce, kde vyberu typ chyby.
* Dle typu chyby se z RUIAN dotáhnou relevantní objekty v okolí
* Označím 0 až X objektů, kterých se tato chyba týká
* Vyplním detaily problému
* Odešlu

V odeslaném hlášení bude jako zdroj uveden projekt Openstreetmap (talk-cz?)
a kontaktní osoba bude OSM ID uživatele (plus jeho email?).
Připadně by se mohly všechny takto vygenerované chyby zároveň poslat do talk
-cz nebo, pokud jich bude moc, tak do nějaké nové specializované
konference, ať to tady nezaplevelíme.

Byl by pak přehled, kdo, co a kdy nahlásil.

Ono ideální by asi byl nějaký systém na evidenci požadavků (ala Trac,
Bugzila), ale to asi nebude reálné.

Jak to vidíte? Návrhy a připomínky vítány. Pokusím se spíchnout nějaké demo,
ale poslední dobou se času moc nedostává :-(

Marián

-- Původní zpráva --
Od: Jachym Cepicky

[OSM-talk-fr] Cartopartie Vernon (Eure) avec France 3 Normandie

2014-04-29 Diskussionsfäden RatZilla$

Bonjour,

France 3 Normandie devait m'interviewer aujourd'hui. Au détour de Vernon je
leur montrerai comment on cartographie. Cartopartie de 30minutes improvisée
ce matin autour du Centre Social des Pénitents à 11:00 avec les agents et
jeunes du centre en vacance.

Je vous tiens au courant quand le sujet doit être diffusé.

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

Re: [OSM-talk-fr] service=alley

2014-04-29 Diskussionsfäden Christian Quest

A corriger donc... car les tags ne correspondent pas à la réalité.


Le 28 avril 2014 22:10, Yves yve...@gmail.com a écrit :

 C'est des tags pour le rendu: les rues sont étroites et un highway
 residential deborderai sur les bâtiments.



 On 28 avril 2014 19:59:04 UTC+02:00, Jérôme Amagat 
 jerome.ama...@gmail.com wrote:

 Bonjours

 Comment ça marche les service=alley?

 Je regardais Lagnieu dans l'ain, tous le centre ville et tagger avec ces
 alley (highway=service et service=alley) : http://overpass-turbo.eu/s/3bP
 Dans d'autres endroits (dans cette commune ou ailleurs), ce sont des rues
 étroites ou bien des routes dans un lotissement qui sont tagger ainsi.

 Quand on regarde le wiki
 http://wiki.openstreetmap.org/wiki/Tag:service%3Dalley
 Que ça soit en anglais ou en francais j'ai pas l'impression que c'est
 fait pour ça.

 Cordialement

 --

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


 --
 Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

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




-- 
Christian Quest - OpenStreetMap France
Conférence State Of The Map France du 4 au 6 avril à
Parishttp://openstreetmap.fr/sotmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rapport nombre de bâtiments par adresse, pour contrôle qualité

2014-04-29 Diskussionsfäden Ab_fab

On pourrait également suivre le carroyage INSEE (*), qui affinerait les
résultats


(*)
http://tile.openstreetmap.fr/?zoom=13lat=47.23526lon=-1.592layers=B000TFF


Le 28 avril 2014 23:29, Pierre Knobel pierr...@gmail.com a écrit :

 Bonjour,

 En même temps que je rajoute les adresses j'en profite pour fusionner les
 bâtiments les plus fragmentés, et je me dit que ça pourrait faire un bon
 outil de contrôle qualité d'avoir une couche de polygônes de communes
 coloriés par leur rapport nombre de bâtiments sur nombre de tags
 addr:housenumber pour toute la France.

 Je ne m'attend pas à ce que ce soit un indicateur rigoureux, mais ça
 permettrait d'avoir un rapide aperçu de l'état d'avancement du projet
 adresses à intervalle régulier. Et pour les zones dont on sait que les
 adresses ont été importées, on pourrait utiliser ça comme indicateur de
 fragmentation des bâtiments.

 Je m'attend à ce que le rapport soit proche de 2:1 pour les zones bien
 cartographiées. Entre 2:1 et 1:1 je verrais bien un dégradé du vert clair
 au vert foncé. De 2:1 à l'infini il faudrait un dégradé du vert au rouge.
 En dessous de 1:1, quand on a plus de noeuds d'adresses que de bâtiments,
 je mettrais une couleur à part, par exemple le jaune.

 Qu'est-ce que vous en pensez ? Est-ce que ça vous semble utile ? Est-ce
 que c'est compliqué à mettre en place ? J'imagine que ça fait un gros
 volume de données à traiter et à maintenir à jour.


 Pierre

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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rapport nombre de bâtiments par adresse, pour contrôle qualité

2014-04-29 Diskussionsfäden Ab_fab

(re)bonjour,

Il y a également ce principe des UTF-grid qui pourrait être intéressant
https://github.com/mapbox/mbtiles-spec/blob/master/1.1/utfgrid.md

Bonne journée



Le 28 avril 2014 23:29, Pierre Knobel pierr...@gmail.com a écrit :

 Bonjour,

 En même temps que je rajoute les adresses j'en profite pour fusionner les
 bâtiments les plus fragmentés, et je me dit que ça pourrait faire un bon
 outil de contrôle qualité d'avoir une couche de polygônes de communes
 coloriés par leur rapport nombre de bâtiments sur nombre de tags
 addr:housenumber pour toute la France.

 Je ne m'attend pas à ce que ce soit un indicateur rigoureux, mais ça
 permettrait d'avoir un rapide aperçu de l'état d'avancement du projet
 adresses à intervalle régulier. Et pour les zones dont on sait que les
 adresses ont été importées, on pourrait utiliser ça comme indicateur de
 fragmentation des bâtiments.

 Je m'attend à ce que le rapport soit proche de 2:1 pour les zones bien
 cartographiées. Entre 2:1 et 1:1 je verrais bien un dégradé du vert clair
 au vert foncé. De 2:1 à l'infini il faudrait un dégradé du vert au rouge.
 En dessous de 1:1, quand on a plus de noeuds d'adresses que de bâtiments,
 je mettrais une couleur à part, par exemple le jaune.

 Qu'est-ce que vous en pensez ? Est-ce que ça vous semble utile ? Est-ce
 que c'est compliqué à mettre en place ? J'imagine que ça fait un gros
 volume de données à traiter et à maintenir à jour.


 Pierre

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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] service=alley

2014-04-29 Diskussionsfäden Tyndare

Le 28 avril 2014 22:10, Yves yve...@gmail.com a écrit :
 C'est des tags pour le rendu: les rues sont étroites et un highway
 residential deborderai sur les bâtiments.

Ou alors c'est tagué pour le routage. Comment taguer les rues étroites
des centres historiques qui ne sont pas vraiment conseillées pour le
trafic, genre c'est plus rapide de faire le tour, comment les
distinguer des autres highway=residential ?
Pour les rues très étroites ou quasiment aucune voiture ne circule je
pense que service=alley peut être approprié.
Pour l'exemple de Lagnieu ça n'a pas l'air d'être le cas, mais est-ce
que certaines highway actuellement residential ne mériteraient pas du
coup d'être passées en tertiary ?

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

Re: [OSM-talk-fr] service=alley

2014-04-28 22:10 GMT+02:00 Yves yve...@gmail.com:
 C'est des tags pour le rendu: les rues sont étroites et un highway
 residential deborderai sur les bâtiments.

Pas tout à fait. En réalité, il n'existe pas de bon tag pour les
rues étroites qui ne sont pas des voies de service (quelque chose
d'inconnu aux usa ou en Australie). Les tags complémentaires comme
narrow, width ou lanes sur des residential ne sont exploités par
personne, ce qui, au bout de 9 ou 10 ans de projet, est un bon
indicateur de leur succès...
Pour compenser cette faiblesse, le highway=service + service=alley
est depuis longtemps ré-employé pour cet usage (je pense à tord, faute
d'avoir créer un nouveau highway speécifique)

C'est pourquoi le wiki tient compte de cette extension (depuis aout 13):
In some medieval European settlements alleys may be the very narrow
streets which run in-between buildings, providing public
through-access. 

Pieren

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

[OSM-talk-fr] Share alike ou le partage à l'identique

Pour ceux qui ne suivent pas les listes de diffusion anglophones ou
n'ont pas eu la chance d'aller au SOTM-US ni d'en voir les vidéos, je
voudrais quand même les tenir au courant d'une attaque sans précédent
sur la license d'OSM (c.a.d. ODbL), bref sur le mode de partage de nos
données.

Pour faire court, il s'agirait de supprimer la clause share alike de
la license pour basculer dans un modèle public domain (domaine
public, en bon français). Cette clause est fortement contestée par
Mapbox, une entreprise devenue au fil du temps un acteur important
dans l'écosystème d'OpenStreetMap. Ce sont eux qui ont développé
l'actuel éditeur en ligne iD,eux aussi qui ont changé le design de
la page d'accueil, eux qui ont embaucher les meilleurs experts
logiciels qui gravitent autour d'OSM (les auteurs de mapnik, osrm,
nominatim). Pour ceux qui les suivent, on sait qu'ils remportent un
certain nombre de succès commerciaux grâce à OSM (Craig, multiples
sites de presse,etc), et c'est tant mieux. Mais ils rencontrent aussi
certains freins dans leurs activités commerciales avec la licence
actuelle qui les empêche de faire tout ce qui pourrait être fait grâce
à OSM sans cette clause share-alike.
Pour rester court (je vais essayer), l'exemple le plus cité par Mapbox
concerne la base adresse de New-York. Cette base est publiée par la
ville dans le domaine public (comme la plupart des données publiques
aux USA d'ailleurs). Mapbox s'est lancé dans l'organisation d'un
import par la masse (crowdsourcing) manuel et contrôlé par le biais
du task manager développé par HOT. Problème : l'effort est important
et les données publiques (comme partout ailleurs) souffrent d'erreurs
et retards par rapport au terrain. L'administration de New-York
souhaiterait fortement pouvoir profiter des améliorations apportées
dans les adresses de New-York dans OSM. Mais ils ne peuvent pas le
faire parce que leurs données sont dans le domaine publique et la
clause share-alike d'OSM les empêchent de le faire. (Un autre
exemple concerne les données d'accessibilité wheelchair qui sont
difficile à réutiliser en dehors d'un projet non compatible avec ODbL)
Suite à ce constat, les dirigeants de Mapbox poussent la communauté à
changer de license et à supprimer cette clause qui, selon eux,
restreignent les usages qui pourraient être fait d'OSM, la version la
plus libre/open étant de supprimer cette clause share-alike,
c.à.d. sans contraintes à part peut-être celle de l'attribution. Cela
s'est traduit par un appel au début du dernier Sotm-us pour ce
changement (la vidéo ici [1]), précédé par un billet sur les blogs
d'osm.org ([2]).
Ce qui en retour a récemment donné lieu à certains échanges savoureux
entre Steve Coast (fondateur d'OSM) et Alex Barth de Mapbox sur la
liste de diffusion legal-talk ([3]). Le principal argument de Steve
est que la clause de partage à l'identique fait que les données ne
peuvent être améliorées par quelques-uns à leur seul profit (c'est le
principe du share-alike) et que l'autre modèle en domaine publique
n'a pas démontré sa supériorité en citant l'exemple de la base de
données géographiques des USA qui est libre de droit (TIGER) et
utilisée par de nombreux acteurs locaux mais dont les mutiples
corrections ne sont pas partagées, faisant au final de cette base
publique un piètre exemple au niveau de la qualité (mais comme c'est
gratuit, beaucoup s'en satisfont). En réponse, Alex avance que la
clause du share-alike est nuisible à la communauté car elle empêche
l'utilisation d'OSM dans de nombreux cas, ce qui pourrait en retour
profiter à OSM, que ce sont essentiellement des données et que les
données sont faites pour être mélangées ou empilées avec d'autres
données avec le plus de liberté possible (more open).
Voila, j'ai essayé de présenter le problème de la manière la plus
neutre possible (je pourrais développer certains points si souhaité).
J'ai bien sûr une opinion sur le sujet mais je voulais avant tout vous
tenir au courant de ce débat qui n'a eu aucun écho en France jusqu'ici
mais qui pourrait potentiellement avoir un impact aussi dans notre
pays si la license venait à changer dans le futur.

Pieren

[1] http://stateofthemap.us/session/more-open/
[2] http://www.openstreetmap.org/user/lxbarth/diary/21221
[3] http://gis.19327.n5.nabble.com/OSM-legal-talk-Attribution-td5804452.html

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

Re: [OSM-talk-fr] Share alike ou le partage à l'identique

2014-04-29 Diskussionsfäden THEVENON Julien

Il me semble qu une partie de la discussion a eu lieu sur Talk non ?
Par contre le principcal argument developpe etait plutot si il n y avait pas de 
Share Alike alors des gens comme Google reutilsieraient nos donnees et 
donneraient une bien meilleure visibilite a OSM

Julien





 De : Pieren pier...@gmail.com
À : talk-fr@openstreetmap.org 
Envoyé le : Mardi 29 avril 2014 15h31
Objet : [OSM-talk-fr] Share alike ou le partage à l'identique
 

Pour ceux qui ne suivent pas les listes de diffusion anglophones ou
n'ont pas eu la chance d'aller au SOTM-US ni d'en voir les vidéos, je
voudrais quand même les tenir au courant d'une attaque sans précédent
sur la license d'OSM (c.a.d. ODbL), bref sur le mode de partage de nos
données.

Pour faire court, il s'agirait de supprimer la clause share alike de
la license pour basculer dans un modèle public domain (domaine
public, en bon français). Cette clause est fortement contestée par
Mapbox, une entreprise devenue au fil du temps un acteur important
dans l'écosystème d'OpenStreetMap. Ce sont eux qui ont développé
l'actuel éditeur en ligne iD,eux aussi qui ont changé le design de
la page d'accueil, eux qui ont embaucher les meilleurs experts
logiciels qui gravitent autour d'OSM (les auteurs de mapnik, osrm,
nominatim). Pour ceux qui les suivent, on sait qu'ils remportent un
certain nombre de succès commerciaux grâce à OSM (Craig, multiples
sites de presse,etc), et c'est tant mieux. Mais ils rencontrent aussi
certains freins dans leurs activités commerciales avec la licence
actuelle qui les empêche de faire tout ce qui pourrait être fait grâce
à OSM sans cette clause share-alike.
Pour rester court (je vais essayer), l'exemple le plus cité par Mapbox
concerne la base adresse de New-York. Cette base est publiée par la
ville dans le domaine public (comme la plupart des données publiques
aux USA d'ailleurs). Mapbox s'est lancé dans l'organisation d'un
import par la masse (crowdsourcing) manuel et contrôlé par le biais
du task manager développé par HOT. Problème : l'effort est important
et les données publiques (comme partout ailleurs) souffrent d'erreurs
et retards par rapport au terrain. L'administration de New-York
souhaiterait fortement pouvoir profiter des améliorations apportées
dans les adresses de New-York dans OSM. Mais ils ne peuvent pas le
faire parce que leurs données sont dans le domaine publique et la
clause share-alike d'OSM les empêchent de le faire. (Un autre
exemple concerne les données d'accessibilité wheelchair qui sont
difficile à réutiliser en dehors d'un projet non compatible avec ODbL)
Suite à ce constat, les dirigeants de Mapbox poussent la communauté à
changer de license et à supprimer cette clause qui, selon eux,
restreignent les usages qui pourraient être fait d'OSM, la version la
plus libre/open étant de supprimer cette clause share-alike,
c.à.d. sans contraintes à part peut-être celle de l'attribution. Cela
s'est traduit par un appel au début du dernier Sotm-us pour ce
changement (la vidéo ici [1]), précédé par un billet sur les blogs
d'osm.org ([2]).
Ce qui en retour a récemment donné lieu à certains échanges savoureux
entre Steve Coast (fondateur d'OSM) et Alex Barth de Mapbox sur la
liste de diffusion legal-talk ([3]). Le principal argument de Steve
est que la clause de partage à l'identique fait que les données ne
peuvent être améliorées par quelques-uns à leur seul profit (c'est le
principe du share-alike) et que l'autre modèle en domaine publique
n'a pas démontré sa supériorité en citant l'exemple de la base de
données géographiques des USA qui est libre de droit (TIGER) et
utilisée par de nombreux acteurs locaux mais dont les mutiples
corrections ne sont pas partagées, faisant au final de cette base
publique un piètre exemple au niveau de la qualité (mais comme c'est
gratuit, beaucoup s'en satisfont). En réponse, Alex avance que la
clause du share-alike est nuisible à la communauté car elle empêche
l'utilisation d'OSM dans de nombreux cas, ce qui pourrait en retour
profiter à OSM, que ce sont essentiellement des données et que les
données sont faites pour être mélangées ou empilées avec d'autres
données avec le plus de liberté possible (more open).
Voila, j'ai essayé de présenter le problème de la manière la plus
neutre possible (je pourrais développer certains points si souhaité).
J'ai bien sûr une opinion sur le sujet mais je voulais avant tout vous
tenir au courant de ce débat qui n'a eu aucun écho en France jusqu'ici
mais qui pourrait potentiellement avoir un impact aussi dans notre
pays si la license venait à changer dans le futur.

Pieren

[1] http://stateofthemap.us/session/more-open/
[2] http://www.openstreetmap.org/user/lxbarth/diary/21221
[3] http://gis.19327.n5.nabble.com/OSM-legal-talk-Attribution-td5804452.html

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

Re: [OSM-talk-fr] Share alike ou le partage à l'identique

2014-04-29 Diskussionsfäden V de Chateau-Thierry

Bonjour,

 De : THEVENON Julien

 Il me semble qu une partie de la discussion a eu lieu sur Talk non ?
 Par contre le principcal argument developpe etait plutot si il n y avait pas 
 de Share
 Alike alors des gens comme Google reutilsieraient nos donnees et donneraient 
 une bien 
 meilleure visibilite a OSM


Merci Pieren de pas avoir fait si court que ça :)
Concernant l'hypothèse de suppression, est-ce que le raisonnement suivant est 
valide :
- à j, OSM supprime la clause SA
- à j+1, n'importe quel éditeur de BD géographiques fermées récupère tout le 
contenu
qui l'intéresse dans OSM pour enrichir sa propre base
Et au delà de j+1, chacun de ces éditeurs, fort de son saut qualitatif ponctuel 
grâce 
à OSM, continue sa petite vie sans reverser quoi que ce soit à OSM et sans plus 
jamais
se servir dedans, s'épargnant les casse-têtes de consolidation dans le temps.

- à j+1 aussi, la valeur singulière d'OSM s'effondre vu que chacun de ses 
concurrents
dispose de son contenu propre ET du contenu OSM en plus. Fin du projet...

C'est très raccourci, je sais. Mais pour le dire de façon claire et partisane : 
je suis
archi-contre la suppression du SA car je ne vois pas le projet y survivre.

vincent

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

Re: [OSM-talk-fr] Share alike ou le partage à l'identique

2014-04-29 Diskussionsfäden Arnaud Vandecasteele

Merci pour ce résumé très intéressant !
J'avais suivi de loin le problème sans en comprendre la totalité...
Je me demande bien qui va gagner ce bras de fer.

De votre point de vue (la communauté fr), nous sommes plutôt pour la
suppression ou la continuité du share alike ?

A.


2014-04-29 11:07 GMT-02:30 THEVENON Julien julien_theve...@yahoo.fr:

 Il me semble qu une partie de la discussion a eu lieu sur Talk non ?
 Par contre le principcal argument developpe etait plutot si il n y avait
 pas de Share Alike alors des gens comme Google reutilsieraient nos donnees
 et donneraient une bien meilleure visibilite a OSM

 Julien


   --
  *De :* Pieren pier...@gmail.com
 *À :* talk-fr@openstreetmap.org
 *Envoyé le :* Mardi 29 avril 2014 15h31
 *Objet :* [OSM-talk-fr] Share alike ou le partage à l'identique

 Pour ceux qui ne suivent pas les listes de diffusion anglophones ou
 n'ont pas eu la chance d'aller au SOTM-US ni d'en voir les vidéos, je
 voudrais quand même les tenir au courant d'une attaque sans précédent
 sur la license d'OSM (c.a.d. ODbL), bref sur le mode de partage de nos
 données.

 Pour faire court, il s'agirait de supprimer la clause share alike de
 la license pour basculer dans un modèle public domain (domaine
 public, en bon français). Cette clause est fortement contestée par
 Mapbox, une entreprise devenue au fil du temps un acteur important
 dans l'écosystème d'OpenStreetMap. Ce sont eux qui ont développé
 l'actuel éditeur en ligne iD,eux aussi qui ont changé le design de
 la page d'accueil, eux qui ont embaucher les meilleurs experts
 logiciels qui gravitent autour d'OSM (les auteurs de mapnik, osrm,
 nominatim). Pour ceux qui les suivent, on sait qu'ils remportent un
 certain nombre de succès commerciaux grâce à OSM (Craig, multiples
 sites de presse,etc), et c'est tant mieux. Mais ils rencontrent aussi
 certains freins dans leurs activités commerciales avec la licence
 actuelle qui les empêche de faire tout ce qui pourrait être fait grâce
 à OSM sans cette clause share-alike.
 Pour rester court (je vais essayer), l'exemple le plus cité par Mapbox
 concerne la base adresse de New-York. Cette base est publiée par la
 ville dans le domaine public (comme la plupart des données publiques
 aux USA d'ailleurs). Mapbox s'est lancé dans l'organisation d'un
 import par la masse (crowdsourcing) manuel et contrôlé par le biais
 du task manager développé par HOT. Problème : l'effort est important
 et les données publiques (comme partout ailleurs) souffrent d'erreurs
 et retards par rapport au terrain. L'administration de New-York
 souhaiterait fortement pouvoir profiter des améliorations apportées
 dans les adresses de New-York dans OSM. Mais ils ne peuvent pas le
 faire parce que leurs données sont dans le domaine publique et la
 clause share-alike d'OSM les empêchent de le faire. (Un autre
 exemple concerne les données d'accessibilité wheelchair qui sont
 difficile à réutiliser en dehors d'un projet non compatible avec ODbL)
 Suite à ce constat, les dirigeants de Mapbox poussent la communauté à
 changer de license et à supprimer cette clause qui, selon eux,
 restreignent les usages qui pourraient être fait d'OSM, la version la
 plus libre/open étant de supprimer cette clause share-alike,
 c.à.d. sans contraintes à part peut-être celle de l'attribution. Cela
 s'est traduit par un appel au début du dernier Sotm-us pour ce
 changement (la vidéo ici [1]), précédé par un billet sur les blogs
 d'osm.org ([2]).
 Ce qui en retour a récemment donné lieu à certains échanges savoureux
 entre Steve Coast (fondateur d'OSM) et Alex Barth de Mapbox sur la
 liste de diffusion legal-talk ([3]). Le principal argument de Steve
 est que la clause de partage à l'identique fait que les données ne
 peuvent être améliorées par quelques-uns à leur seul profit (c'est le
 principe du share-alike) et que l'autre modèle en domaine publique
 n'a pas démontré sa supériorité en citant l'exemple de la base de
 données géographiques des USA qui est libre de droit (TIGER) et
 utilisée par de nombreux acteurs locaux mais dont les mutiples
 corrections ne sont pas partagées, faisant au final de cette base
 publique un piètre exemple au niveau de la qualité (mais comme c'est
 gratuit, beaucoup s'en satisfont). En réponse, Alex avance que la
 clause du share-alike est nuisible à la communauté car elle empêche
 l'utilisation d'OSM dans de nombreux cas, ce qui pourrait en retour
 profiter à OSM, que ce sont essentiellement des données et que les
 données sont faites pour être mélangées ou empilées avec d'autres
 données avec le plus de liberté possible (more open).
 Voila, j'ai essayé de présenter le problème de la manière la plus
 neutre possible (je pourrais développer certains points si souhaité).
 J'ai bien sûr une opinion sur le sujet mais je voulais avant tout vous
 tenir au courant de ce débat qui n'a eu aucun écho en France jusqu'ici
 mais qui pourrait potentiellement avoir un impact aussi dans notre

Re: [OSM-talk-fr] Share alike ou le partage à l'identique

2014-04-29 15:37 GMT+02:00 THEVENON Julien julien_theve...@yahoo.fr:
 Il me semble qu une partie de la discussion a eu lieu sur Talk non ?
 Par contre le principcal argument developpe etait plutot si il n y avait pas
 de Share Alike alors des gens comme Google reutilsieraient nos donnees et
 donneraient une bien meilleure visibilite a OSM


Oui, c'est juste. Le blog d'Alex a permis de lancer une première
discussion sur la liste talk qu'on peut retrouver ici:
http://gis.19327.n5.nabble.com/OpenStreetMap-Isn-t-All-That-Open-Let-s-Change-That-and-Drop-Share-Alike-td5799574.html

Pieren

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

Re: [OSM-talk-fr] Share alike ou le partage à l'identique

2014-04-29 Diskussionsfäden Bruno Cortial

Merci Pieren pour le retour.
Je sors les popcorn...

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

Re: [OSM-talk-fr] Share alike ou le partage à l'identique