Re: [OSM-talk] [possibly OT] Apples IOS 6 Maps and the response

[Toby Murray]

On Thu, Sep 20, 2012 at 1:39 PM, pavithran  wrote:
> The new map replacement from apple in its IOS has drawn a lot of criticism .
>
>  http://www.guardian.co.uk/technology/2012/sep/20/apple-maps-ios6-station-towe>
> Within minutes of the launch of the iOS6 operating system, which comes
> preloaded with Apple Maps, users were reporting that London had been
> relocated to Ontario, Paddington station had vanished, the Sears Tower
> in Chicago had shrunk, and Helsinki railway station had been turned
> into a park.
>
> 
>
> Having said that How much is it OSM data?  There have been messages
> saying its the TomTom data but if you look at
> http://gspa21.ls.apple.com/html/attribution.html
> there is a line "(OSM)
> OpenStreetMap contributors, http://www.openstreetmap.org/ "
>
> Pretty confusing and sad to say that many of the comments were against
> the map app and suggesting that they would hardly  accept anything
> other than google maps .

Also note that it was just reported in IRC that 4chan got it in their
heads that they could troll apple maps by editing OSM:

http://boards.4chan.org/g/res/27736265

The OP and at least one user's edits have been reverted already but as
always, keep an eye out for vandalism.

Toby

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

Re: [OSM-talk] diversity amongst DWG members

[Frederik Ramm]

Hi,

On 20.09.2012 13:46, Lucas Nussbaum wrote:

Are there plans to increase diversity amongst members of the DWG?


We've long been looking for native speakers of a couple of Eastern 
European languages (Russian, Ukrainian) because an above-average number 
of disputes arise in that area and it would be great to have the support 
of a native speaker or two.


Having said that, DWG is not actively recruiting - we're keeping our 
eyes open and dropping a hint here and there and will consider 
applications when we get them, but we don't have a recruiting drive 
going, for fear of attracting the wrong people (those who feel that DWG 
would give them power). And while language capabilities are great, the 
most important thing in a DWG member is that they can listen to people, 
that they are reasonably polite and don't allow themselves to be drawn 
into an argument too quickly. So if we have another good person from the 
UK or Canada or Germany applying we certainly won't sent them away just 
because we'd prefer someone from South America.


You may, from this discussion, get the impression that DWG is a powerful 
police force who make their own rules and block anyone who doesn't 
listen. In reality, DWG work means that you spend a lot of time trying 
to mediate mini conflicts. A mapper calls and complains that another 
mapper has deleted his work; you contact the other mapper and they claim 
that no, the other guy was at fault because he made too many errors and 
didn't listen, and so on - all the time you try and find out what has 
really happened, and who is to blame, and what you can do to make these 
people work together instead of against each other. We're not looking 
for jurors, judges, or policemen at DWG, we don't need politicians or 
the hot-headed and trigger-happy; we mostly need kindergarten teachers ;)


Bye
Frederik

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

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

Re: [OSM-talk] Import guidelines proposal update

[Frederik Ramm]

Hi,

On 20.09.2012 12:29, sly (sylvain letuffe) wrote:

And that's where we disagree. Your are not accepting any distinction about all
different cases in your statement, and it seams you are implicitly denying
the ability of the local community to decide wisely.


What I wanted to say is:

If the negative effects of a bad decision only, or mostly, affect the 
local community, then they can be trusted to take these decisions 
themselves, because they will learn from their mistakes.


If the negative effects however affect other/different people - perhaps 
because they are using the API outside of specifications, or causing 
more work for people elsewhere in the project - then they can't.


Of course, this does not mean that one could not have a system where 
rules are made centrally but execution of these rules is entrusted to 
local communities (and only if that doesn't work, someone else will step 
in).



In the coming years we'll hopefully (...) discussion about what the local
chapters  can decide by themselves and what not.


Any reasons to wait for years?


I don't think we should *wait* for years, I just believe that it will 
take a long, long time to get this worked out properly. There are tons 
of things that need to be at least thought about on the way to a 
federated OSM project.


There are very simple technical things. For example, assume that there 
was a French DWG dealing only with French cases; we don't have the means 
to set things up in a way that the French DWG can only block French 
users. We don't even have a proper definition of local communities and 
who is entitled to whatever privileges we grant local communities - for 
example, we recently had an issue in the Crimea which is part of Ukraine 
but where local mappers would rather not be governed by decisions made 
by the wider Ukrainian community. So, what if a Toulouse mapper comes to 
OSMF and complains that OSMF-FR is unfairly suppressing Languedoc 
self-determination?


What if local communities decide stuff that is considered harmful to the 
project as a whole by someone on the other side of the world? Who would 
adjudicate such a conflict? Can the world-wide community be called to a 
vote that is binding for France? Can the French community make a binding 
rule for Toulouse? How many is a community, anyway? Do they have to be 
incorporated? Do they have to be democratic? What if a national 
community - as has been the case in the past with some Eastern European 
national communities - takes a very liberal attitude towards copyright 
("the government web page says private use only but they never 
prosecuted anyone...")? Can a national community make a deal with a 
sponsor and allow the sponsor to carry the OSM logo?


All this has been discussed for years, on and off, when we talked about 
"local chapters". And I expect that it will be another couple of years 
until we have a structure that works.



That's exactly the discussion we are having
now about a real case need, we have sent a representative of our community we
trust, I have a proposal for the first rule to be discussed and agreed upon.


Personally, I don't think you can disregard all the questions I 
mentioned above and simply make a rule that says a few nice things about 
a national community which might or might not be well defined in any 
particular case. I think that your suggestion is too much like case law: 
There's a rule that leads to a result you don't like, and then you amend 
it with a little extra rule specifically for that purpose. (In your 
case, you have built a "regional limited import" special rule into the 
"separate import account" rule, but what if tomorrow the French 
community decides that they would like to be exempt from something else...?)


I think that we need to take quite a few steps back and stop discussing 
about "oh god oh god a respected French OSMer was blocked by evil DWG, 
where on earth did they get that authority to block him and how can we 
take it away from them".


We should be discussing what rules we need at all, where we don't need 
any rules, who makes these rules, how local communities come into play 
there, and all that. This, I believe, takes a lot of time, and real, 
committed, long-time work by a few individuals who really want to move 
the project forward, rather than just a quick fix for a particular problem.


(Technically, and in the very-long-run, my cloud-nine astronaut 
vapourware vision is of regional communities operating their own 
databases and them all to be in some kind of federated system. But 
that's not something we can decide by a quick wiki poll tomorrow ;)


Bye
Frederik

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

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Christian Rogel]

Le 20 sept. 2012 à 18:59, Simon Poole a écrit :
>> .
> While a more top down organisation of OSM a la Wikipedia or other 
> organisations is imaginable, there has never been a community consensus that 
> such a step would be desirable (if anything it is exactly the opposite). So 
> while the OSMF provides the formal structure for the working groups, most 
> policy decisions are not made or even vetted  by the OSMF board, but are 
> simply decided by the people interested in the issues at hand and 
> (particularly in the case of the DWG) the people that do the work. Not to 
> mention the far larger number of policies (tagging and others) that are not 
> in the remit of any specific working group and are decided by the OSM 
> community at large.


Yes, the OSMF has not be established as a topdown organization, but it has to 
fulfill 
its commitments for maintaining the servers and the free data inside.
Art. 4 of the Memorandum of Association :
"In support of the objects, but not otherwise, the Company shall have power to 
do 
all things incidental or conducive to the attainment of the objects or any of 
them."

That includes responsibility for attaining the objects.

So, as we have a DWG a making tremendous efforts for maintaining a good policy
for the data (including the boring chase of proprietary ones), it may happen 
and it
will happen more and more that a projected decision exceed the field of the data
policy to jump into a "political" field.
In those rare cases, the Board of Directors has to be put in the loop, before 
going further.
We have a good example with the recommendation of a special account muted 
without
announcement and explanation to an obligation.
One more time, no personal reproach here.
But from that example, the Board must think of the growing difficulties to 
handle and be
prepared for that.
It will be no use saying DWG is appertaining to the community as it is no more 
and no
less than an efficient working group fueled by the contributors propositions. 
Responsibility is up to the Board when speaking of rules applicable maybe  to 
every 
contributor or for managing a tool or a resource specific to a part of the 
World.

Christian Rogel
OSMF Member


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

[OSM-talk] [possibly OT] Apples IOS 6 Maps and the response

[pavithran]

The new map replacement from apple in its IOS has drawn a lot of criticism .

http://www.guardian.co.uk/technology/2012/sep/20/apple-maps-ios6-station-towe>
Within minutes of the launch of the iOS6 operating system, which comes
preloaded with Apple Maps, users were reporting that London had been
relocated to Ontario, Paddington station had vanished, the Sears Tower
in Chicago had shrunk, and Helsinki railway station had been turned
into a park.



Having said that How much is it OSM data?  There have been messages
saying its the TomTom data but if you look at
http://gspa21.ls.apple.com/html/attribution.html
there is a line "(OSM)
OpenStreetMap contributors, http://www.openstreetmap.org/ "

Pretty confusing and sad to say that many of the comments were against
the map app and suggesting that they would hardly  accept anything
other than google maps .

Regards,
Pavithran




-- 
pavithran sakamuri
http://look-pavi.blogspot.com

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Lester Caine]

Simon Poole wrote:

Yes, the development in the area of Open Data poses a serious challenge to OSM.
I suspect that the attitude of large parts of the community is that OGD is a
good thing, however I'm also fairly sure that there is no community consensus
that OSM should aspire to import everything that is available just because it is
there. In the end we want to produce an editable, community sourced map of the
world, not simply a copy of data that is available (and remains available)
elsewhere.


In support of importing data that is available, the cadastre dataset is probably 
a good 'benchmark' where fine detail such as building are available, but this 
lacks the additional information such as street names and numbers, which is 
exactly where OSM can step in and enhance the data?


But I view the situation as one were OSM will provide a level playing field 
where a vast basket of OGD data in multiple formats will be merged into a 
coherent whole? And perhaps some of that data will only be accessible on 
secondary servers as overlays?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Pierre Béland]

2012-09-20 Lester Caine wrote

> Alright insisting on a 'new account' may be wrong, but identifying the 
'import source' somewhere is not unreasonable?
> We do have the problem of the 'language' used to inform other users and some 
> English translations on some of the
   cadastre import stuff would help?

> I will add that
 I am very much opposed to any suggestion that the database should be 
'carved up' and managed
> by different local groups. The DWG is not ideal, and as far as I am aware 
> would welcome some additional help from
> wherever. But that is the ideal level to oversee the whole picture and 
in the end arbitrate when groups disagree
> amongst themselves. How many 
'border disputes' will we have if we go down that path?

I will speak for the Québec community only. Management in a large organization 
cannot be made centralized only and with a few rules. When we say management, 
we are talking about following mapping and contributors, informing, teaching, 
organizing social events.  


In Canada, we have the Talk-ca discussion  list were most of the discussion is 
in english. And often, there are no tools for monitoriging at regional or local 
level.

I am a HOT member. Our work brings us in many countries were we try to develop 
local communities. We have to adapt to a multitude of cultures not to talk 
about computer literacy and language problems.

The Knight Foundation 575,000$ award should help to adapt Openstreetmap 
infrastructure to the organization. I see two interesting text written by Kate 
Chapman and Mikel Maron of HOT that give good clues.
Kate Chapman, 
http://www.maploser.com/2012/03/29/all-i-want-for-openstreetmap-is-simple/

Mikel Maron  All I want fo OpenStreetMap ... Is Social and Attention 
http://brainoff.com/weblog/2012/03/30/1773

 

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Simon Poole]

I believe there is some misunderstanding of the relationship between OSM 
and OSMF.


Am 20.09.2012 16:36, schrieb Christian Rogel:

Le 20 sept. 2012 à 13:22, Lester Caine a écrit :


sly (sylvain letuffe) wrote:

We can get back to the topic of governance and discussion about those laws and
who decide them, and how.

Or just get back to fixing the process in the first place?
SO we have less chance of misinterpreting the 'guidelines'?

Yes, it is all about governance and not only a technical issue, although many 
pound for
reducing the debate to it.

OSM is going more and more political (not in the sense of ordinary politics, of 
course).

Some decisions elaborated on technical have to be reviewed and weighed by the
only "political" body we have, namely the Board.

There is no way having a Board which says it is always sticking to our 
brilliant technical team,
whatever they decide.
While a more top down organisation of OSM a la Wikipedia or other 
organisations is imaginable, there has never been a community consensus 
that such a step would be desirable (if anything it is exactly the 
opposite). So while the OSMF provides the formal structure for the 
working groups, most policy decisions are not made or even vetted  by 
the OSMF board, but are simply decided by the people interested in the 
issues at hand and (particularly in the case of the DWG) the people that 
do the work. Not to mention the far larger number of policies (tagging 
and others) that are not in the remit of any specific working group and 
are decided by the OSM community at large.


OSM WG membership is fairly open, but the basic premise is that you join 
to help with the work at hand and influence policy by that, not by using 
a WG as a political grandstand. It is imaginable that if a WG stepped 
very far outside its remit the OSMF board might intervene, but I don't 
know of any such situation and the case in hand is clearly not such a 
situation either. The import guidelines don't restrict the imported 
content outside the legal requirements that it be compatible with our 
distribution terms and simply adds a couple of rules on how to achieve 
community consensus and how to technically implement the import, the 
later are essentially practical  measures to make the core DWG job 
manageable. If at all, as I've pointed out before, the administrative 
and technical requirements are too lax, this is at least what the 
experience during the licence change would indicate.


In the long term we may need more formal ways to produce rules and 
guidelines for OSM as a whole, however this is not something that will 
be easy and will likely be a process of the same order of magnitude as 
the licence change.


[Discussion of more and more OGD becoming available ommited]

Yes, the development in the area of Open Data poses a serious challenge 
to OSM. I suspect that the attitude of large parts of the community is 
that OGD is a good thing, however I'm also fairly sure that there is no 
community consensus that OSM should aspire to import everything that is 
available just because it is there. In the end we want to produce an 
editable, community sourced map of the world, not simply a copy of data 
that is available (and remains available) elsewhere.


I'm sure that the OpenData issue will be a very hot topic over the next 
months and years, but it really belongs in a separate thread and not in 
a discussion over administrative and technical procedures.


Simon

PS: just in case it is not clear, I'm not representing the position of 
the OSMF board in this discussion, just that of a mapper that had to 
chase down a number of rogue imports over the last months.



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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Lester Caine]

Béland Pierre wrote:

2012-09-20 Lester Caine 

 > Comment fields are not documented as well as they should be and the 'problem'
that instigated this thread is to my view of what's
 > on line a very good example of why there WAS a problem. Correctly flagging
information is essential and we do perhaps need
 > a little more 'automatic' actions. I can see that the French data is perhaps
not suited to a 'single import' which is then the problem,
 > since multiple imports already processed in some way are just as much a
problem? Lets try and make the 'initial' import as clean
 > as possible even if that has to be to a staging area from which packets can
be taken and manually processed. Identification can
 > then be married back to the raw data in a location where anybody can see it?

Do you mean that documenting well the comment field would be a satisfactory
solution?


In the short term it would help ... if you check the particular commit that 
caused all this uproar then a few extra words COULD have prevented a problem? I 
accept now there was a discussion on the French list but how many local lists do 
we have now? I can't see any reference to 'cadastre import' with reference to 
that activity but even then I would contest that wiping the original data was 
still wrong - even if a local group 'approved' it - but I'm not from the camp 
that prefer 'only current data' ;) Bulk deletes will always attract attention as 
they should and even if in this case the commit was 'Mistake with merging 
cadastre import - deleting to allow new data to load' I would expect SOMEONE to 
be checking that it was right! As others have said, I find the actions taken by 
DWG totally acceptable as there is no obvious attribution to 'cadastre import' 
... which is all that was asked for previously? Alright insisting on a 'new 
account' may be wrong, but identifying the 'import source' somewhere is not 
unreasonable? We do have the problem of the 'language' used to inform other 
users and some English translations on some of the cadastre import stuff would 
help?


I will add that I am very much opposed to any suggestion that the database 
should be 'carved up' and managed by different local groups. The DWG is not 
ideal, and as far as I am aware would welcome some additional help from 
wherever. But that is the ideal level to oversee the whole picture and in the 
end arbitrate when groups disagree amongst themselves. How many 'border 
disputes' will we have if we go down that path?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Pierre Béland]

2012-09-20 Lester Caine 
> Comment fields are not documented as well as they should be and the 
'problem' that instigated this thread is to my view of what's
> on line a 
very good example of why there WAS a problem. Correctly flagging 
information is essential and we do perhaps need
> a little more 
'automatic' actions. I can see that the French data is perhaps not 
suited to a 'single import' which is then the problem,
> since multiple 
imports already processed in some way are just as much a problem? Lets 
try and make the 'initial' import as clean
> as possible even if that has 
to be to a staging area from which packets can be taken and manually 
processed. Identification can 
> then be married back to the raw data in a 
location where anybody can see it?

Do you mean that documenting well the comment field would be a satisfactory 
solution?
 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Lester Caine]

Pierre Béland wrote:

Check the list of arguments presented here for the mandatory separate account:

1. "it's easier to separate from normal contributions"
2. "it's more effecient for sourcing"
3. "it's easier to identify the source if we change the license. We
faced that issue in the past for ODbl transition"

Lester

Is a separate account is the better and only way to have some metadata
documenting imports? I don't think so.There are various ways to document 
imports.
To be honest I think that the 'separate account' was originally recommended for 
a single import of a complete set of data. So we all knew that this data came 
from 'xxx', but I'm not even sure now that when you select an object it still 
tells you that information?



There were discussions on the Import listin 2009. Andy Allan opinion was that
metadata like attribution should be on the Changeset and not on the geo feature.
Other like Pieren suggested that it is sometime necessary to give attribution on
the geo feature. Andy Allen also stated that using a dedicated account was
something he less bothered about.

When uploading to the OSM database, I think that the Changeset comment field can
be used to both give attribution and indicate that it is bulk edit. This will be
simple and as efficient. It will be easier to manage for both the contributor,
the local chapter and the DWG.


Comment fields are not documented as well as they should be and the 'problem' 
that instigated this thread is to my view of what's on line a very good example 
of why there WAS a problem. Correctly flagging information is essential and we 
do perhaps need a little more 'automatic' actions. I can see that the French 
data is perhaps not suited to a 'single import' which is then the problem, since 
multiple imports already processed in some way are just as much a problem? Lets 
try and make the 'initial' import as clean as possible even if that has to be to 
a staging area from which packets can be taken and manually processed. 
Identification can then be married back to the raw data in a location where 
anybody can see it?


If that Knight Foundation grant is suitable I'd like to propose that it is 
directed towards the very tools I am talking about to take all the currently 
available data sources and importing them in as raw a format as possible into an 
overlay system from where they can be merged with the main database. Rather than 
the quite heroic efforts that are currently being used to import them?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Christian Rogel]

Le 20 sept. 2012 à 13:22, Lester Caine a écrit :

> sly (sylvain letuffe) wrote:
>> We can get back to the topic of governance and discussion about those laws 
>> and
>> who decide them, and how.
> Or just get back to fixing the process in the first place?
> SO we have less chance of misinterpreting the 'guidelines'?

Yes, it is all about governance and not only a technical issue, although many 
pound for 
reducing the debate to it.

OSM is going more and more political (not in the sense of ordinary politics, of 
course).

Some decisions elaborated on technical have to be reviewed and weighed by the 
only "political" body we have, namely the Board.

There is no way having a Board which says it is always sticking to our 
brilliant technical team,
whatever they decide.

We know they are all overworked, so it is not for being reproachful to anybody.

The Board can put a loose lead on minor matters, but not on decisions that 
affect potentially
every contributor and having put mandatory a separated count, as having blocked 
whithout
an inquiry about the fact fall in this category.
And these were a matter of official announcement.

Some unforeseen reactions will happen more and more, but they will have to be 
treated
"politically".

If the Board refuse to manage ours affairs this way, it will be  overtaken more 
and more,
as the community grows and as more and data will be liberated.

It can take the risk to be cornered and make dangerous or exaggerated decisions.

Furthermore, local communities will express desires and propositions.

The Board must go further and have deep reflections about le "political 
governance" of
the OSMF

I repeat that it will be a major concern in the future Annual General Meetings 
and elsewhere.




For illustrating the import issues, not only public geodata were integrated 
(meaning letting correct data 
in their places) under the authority of the Brest District (Communauté urbaine. 
240 000 inh.)
for itds territory, but a whole area of 1500 km2, mainly OSM vacant, was added, 
municipality after 
municipality, by the GIS of  the previous body.

I am pounding on my own local administration for having the same integration 
for completing
and correcting a buildings import from the Cadastre having been cast 
unexpectedly by a 
Dutch citizen.
A bunch of us, in the French community, were working hard for merge thousands 
parts of 
the buildings.
I was happy to see my work enriched, but I do not seek for learning  how to 
import, 
as the GIS is very  good.
I concentrate my efforts on footways, cycleways, green spots, transports...

This Dutch made a good thing : he created a special count. this was 2 years 
ago. ;-).

In France, more and more public GIS are considering having their geodata open, 
and cast
into OSM for many public-friendly applications that could not be handled from 
their 
database directly.
They are interested in working with the general public for signalling incidents 
and
local issues and with local mappers for survey and proposing.

Christian Rogel
OSMF member
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines proposal update

[Lester Caine]

Vincent de Chateau-Thierry wrote:

For the vector data, it is also available as raw .osm files, split into 
thematic layers :
mainly administrative boundaries and buildings.



Sure it can be processed. Change detection for buildings is a topic discussed 
on talk-fr
but there is no real tool vailable yet to deal with it. And as said by 
Jean-Marc,
buildings taken from the cadastre as vector parts don't have any ID at all.


My own interest here is more historic than current and I was looking for the 
development of areas relating to my family tree, but there seems to be a general 
consensus that once an object ceases to exist it should be deleted from the 
database. So we need a home to put that data. You have data from 2009? and 2012 
for France, so it would be nice to retain all this history as well. This is were 
'local' archives may play a roll, and additional servers provide additional 
layers such as the historic data that has been purged ... or older versions of 
imports.


In specific relation to vector imports, I presume that the cadastre data is 
'simply' individual lines? Rather than shapes? So every item currently has it's 
own ID even if it's only a line number on a list, and comparing the 2009 data 
with 2012 will produce a list of lines deleted and lines added? 'Hopefully'!


Some cleaver-clogs could probably put together a bit of code that links lines 
where their ends touch, but if you just manually select lines and 'link' them 
and then add a house number etc. Now we have an ID for those set of lines in the 
import database and we only touch them again if the raw data changes ... 
hopefully the geo-referencing has not changed between versions!


This is the sort of development we can all go around duplicating or club 
together and come up with core code that only needs some local filtering to work 
with a particular import? Isn't it better where we HAVE vector data to make the 
best use of it, and then spend our time enhancing the details ... like adding 
road names and house numbers?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[OSM-talk] Knight awards $575k to improve OpenStreetMap infrastructure

[Alex Barth]

Hello everyone -

I'm excited to announce that the Knight Foundation has awarded a grant of 
$575,000 to Development Seed and MapBox to improve OpenStreetMap infrastructure.

Myself and my colleages from the Development Seed and MapBox team are looking 
forward to closely work with other OpenStreetMap community members to put this 
money to good use. The goal is to improve editing infrastructure to enable 
better and more focused editors, update openstreetmap.org with social features 
to allow better interaction around common tasks, and make it easier to access 
and use OpenStreetMap data. These three components together aim to allow a fast 
growing community to scale better. The community has already identified issues 
in these areas and begun to make massive improvements. We'll collaborate with 
existing efforts as much as possible and do all work in the open, on platforms 
like GitHub and producing exclusively open source code.

These are broad brushstrokes for now, without much technical detail. Right now 
we're getting our house in order - we will follow up in the next weeks with 
more detailed thoughts on where we would like to go. In the meantime, fire away 
with questions here or feel free to get in touch directly under a...@mapbox.com.

Links to announcements:

http://mapbox.com/blog/knight-invests-openstreetmap/
http://www.knightfoundation.org/press-room/press-release/six-ventures-bring-data-public-winners-knight-news/

==

About the Knight Foundation

The Knight Foundation supports transformational projects in journalism, media, 
community and the arts. Knight has a strong track record in providing key 
funding to open source projects such as Document Cloud or Panda. Development 
Seed has worked with Knight in more than one instance before, noteably TileMill 
was launched on a Knight grant.

- TileMill http://www.knightfoundation.org/grants/20094589/
- Panda http://www.knightfoundation.org/grants/20110660/
- DocumentCloud http://www.knightfoundation.org/grants/20110146/

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Pierre Béland]

De : 2012-09-20 Lester Caine 
> Pieren - please stop banging on about this - we know that the current process 
is flawed but it WAS
> put in place when problems arose in the Canadian 
imports, and it IS current practice. If one 'local group'
> is treated as a 'special case' then we will get into a cycle of 'me to' so 
> please lets 
not got there.
 
Lester

I am a canadian contributor since jan 2010 and follow the Talk-Ca list. I dont 
remember a lot of discussions about this since then. Just some people 
expressing that they dont like imports by principle and prefer having fun 
mapping from gps traces.

How much problems? How much discussions? Any consensus? Where and when?


Pierre 



>
> De : Lester Caine 
>À : OSM Talk  
>Envoyé le : Jeudi 20 septembre 2012 7h05
>Objet : Re: [OSM-talk] [Imports] Import guidelines proposal update
> 
>Pieren wrote:
>> Check the list of arguments presented here for the mandatory separate 
>> account:
>
>Pieren - please stop banging on about this - we know that the current process 
>is flawed but it WAS put in place when problems arose in the Canadian imports, 
>and it IS current practice. If one 'local group' is treated as a 'special 
>case' then we will get into a cycle of 'me to' so please lets not got there.
>
>In your particular case, there are arguments either way, and it may be 
>appropriate for someone to say sorry, I don't know that anybody has 
>particularly done anything wrong - on either side! - it is just a matter of 
>miss-understanding what people are saying? On both sides?
>
>Lets move all this energy into fixing the process and getting a robust 
>mechanism moving forward!
>
>-- Lester Caine - G8HFL
>-
>Contact - http://lsces.co.uk/wiki/?page=contact
>L.S.Caine Electronic Services - http://lsces.co.uk
>EnquirySolve - http://enquirysolve.com/
>Model Engineers Digital Workshop - http://medw.co.uk
>Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>___
>talk mailing list
>talk@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk
>
>
>___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] diversity amongst DWG members

[Richard Weait]

On Thu, Sep 20, 2012 at 7:46 AM, Lucas Nussbaum
 wrote:
> Hi,
>
> Following the discussion on the infamous french Cadastre '"imports"',
> I've tried to find the country of living of the DWG members

You might also have a look at other working groups and opportunities
to volunteer for OSMF, in addition to anything that you do for OSM as
a mapper.  It would be nice to have more folks translating OSMF
articles.

http://blog.osmfoundation.org

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Pierre Béland]

On Thu, Sep 20, 2012 at 9:34 AM, Lester Caine  wrote:

Check the list of arguments presented here for the mandatory separate account:

1. "it's easier to separate from normal contributions"
2. "it's more effecient for sourcing"
3. "it's easier to identify the source if we change the license. We
faced that issue in the past for ODbl transition"
Lester 

Is a separate account is the better and only way to have some metadata 
documenting imports? I don't think so.There are various ways to document 
imports. 


There were discussions on the Import listin 2009. Andy Allan opinion was that 
metadata like attribution should be on the Changeset and not 
on the geo feature. Other like Pieren suggested that it is sometime necessary 
to give attribution on the geo feature. Andy Allen also stated that using a 
dedicated account was 
something he less bothered about.

When uploading to the OSM database, I think that the Changeset comment field 
can be used to both give attribution and indicate that it is bulk edit. This 
will be simple and as efficient. It will be easier to manage for both the 
contributor, the local chapter and the DWG.
 
Pierre ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] If you're on Twitter

[Floris Looijesteijn]

Which one has both public transport routing and a Streetview alternative?

This might just confuse your 'typical' iPhone user.

Greets,
Floris

On Thu, Sep 20, 2012 at 2:26 PM, Richard Fairhurst wrote:

> ...you might like to retweet this:
>
> http://twitter.com/**openstreetmap/status/**248759285801185281
>
> :)
>
> cheers
> Richard
>
>
> __**_
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines proposal update

[Vincent de Chateau-Thierry]

> De : "Lester Caine" 
>
> So would it not be better to provide it as an raster overlay instead? And 
> trace 
> from that.
> 
> But I was assuming that this was vector data? 

French cadastre is vector data in about 70-80% of the 36.000 municipalities. 
The rest is
made of old paper maps turned into pixels and delivered as raster data. Both are
available as raster layer in JOSM thanks to the cadastre-fr plugin.

For the vector data, it is also available as raw .osm files, split into 
thematic layers :
mainly administrative boundaries and buildings.

So it can be processed into a 
> database? I am sure that from version to version they are not going to be 
> changing the coordinates of the majority of buildings? All that raw data can 
> be 
> imported as a layer in OSM, but in addition it can be compared with a 
> previous 
> import and identical elements ignored? That just leaves the changes between 
> versions to be processed, and you end up with a better version of the 
> cadastre 
> data than the government ;) And reference it to the rest of the OSM data.

Sure it can be processed. Change detection for buildings is a topic discussed 
on talk-fr
but there is no real tool vailable yet to deal with it. And as said by 
Jean-Marc,
buildings taken from the cadastre as vector parts don't have any ID at all. 

vincent


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-legal-talk] importing ODBl data

[Mike Dupont]

On Thu, Sep 20, 2012 at 3:03 PM, David Groom  wrote:
> Should the licence change to something other than CC-BY-SA 2.0 or ODbL 1.0,
> OSMF have guaranteed that they will identify and remove any data
> incompatible with that licence.
>
> Incidentally, I believe that the burden OSMF have imposed upon themselves
> makes it almost certain that no other licence than CC-BY-SA 2.0 or ODbL 1.0
> would ever be used.

Ok, well then if this is so, then we dont need to leave the license
question open as in the CT. Why all the drama then?

If I can resolve this question, then it should not be a problem for me
to convince people to add the odbl clause to people providing data.

I cannot ask people to agree to an open license, that is out of the
question, but odbl for database rights does not seem to be a problem.

It occurs me then under certain condions then cc-by-sa data from
europe which has database rights anyway might be just fine and a moot
point.

thanks for your answers and opinions,

mike

-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

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

Re: [OSM-talk] Import guidelines proposal update

[Lester Caine]

sly (sylvain letuffe) wrote:

The 'mechanisms' that we use MUST be managed centrally,

What are you talking about ? What "mechanisms" are you refering to ?


Simply the methods by which data is added to the database.
And all I am trying to understand now is why if we HAVE digital data to work 
with for which further versions will be provided over the coming decades someone 
has to manually check every line every year or so? This data was in the 
database, so only the changes needed to be posted, but a mistake was made. We 
learn from mistakes and so what I am trying to learn is if we could have HELPED 
by reducing the chance of the mistake? By providing tools that take advantage of 
the data and process it in a way that it is more useful ... in a format that is 
compatible with later importing to OSM.


I know there is something of a 'cultural' thing here and that has some 
involvement in the recent problems, but at the end of the day we all just want 
to help, and 'diving for the shelter' does not help. Fresh eyes and computing 
power can provide an alternative view ... but it would still be nice if we had a 
core mechanism that said 'this is a raw import from xxx and it's id is yyy'? 
It's the 'id is yyy' that seems to be the stumbling block with some people? But 
I currently see no way to develop an automated update process without.


I see no reason that even if the raw data has no internal id we can't add that 
via the import process? I do it all the time with the raw data I'm being 
supplied, and now the sources are using my id's to improve their end. 
Unfortunately not usable mapping stuff though.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Import guidelines proposal update

[Lester Caine]

Jean-Marc Liotier wrote:

On 20/09/2012 13:18, Lester Caine wrote:

Go on wiping and reloading every time the source data is updated and manually
merging everything.

Sounds ugly doesn't it ? Because it is. Wouldn't it be much better if each
building from the cadastre had a UUID that could be traced so that differential
imports could be performed with little disturbance and little manual work ? Yes.
But sadly that is not how the French cadastre works : it is just a bunch of
georeferenced images.

So the user of cadastral data has to repair the buildings split where a
cadastral plot limit is drawn across, check for proper geographic referencing
using GPS traces, imagery and geodesic reference points, expunge the data that
describes buildings that are already in OSM, check the general sanity of the
data, remove the occasional artefacts... I don't like it either - it is a lousy
cadastre but that's the only one we have.


So would it not be better to provide it as an raster overlay instead? And trace 
from that.


But I was assuming that this was vector data? So it can be processed into a 
database? I am sure that from version to version they are not going to be 
changing the coordinates of the majority of buildings? All that raw data can be 
imported as a layer in OSM, but in addition it can be compared with a previous 
import and identical elements ignored? That just leaves the changes between 
versions to be processed, and you end up with a better version of the cadastre 
data than the government ;) And reference it to the rest of the OSM data.


Some of us are playing similar 'tricks' with the UK OS data ...

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-legal-talk] importing ODBl data

[David Groom]

- Original Message - 
From: "Mike Dupont" 

To: "Licensing and other legal discussions." 
Sent: Thursday, September 20, 2012 6:32 AM
Subject: [OSM-legal-talk] importing ODBl data



Hi there,

I have a question about imports and the ODBl,

I see that some sources have decided to dual license the data
http://wiki.openstreetmap.org/wiki/Import/Catalogue

But how can some third parties data be compatible when the CT says it
can change any time, surly they might be compatible with the current
instance of the license, but how can they be compatible with future
versions of the license when they are no known?



I think the answer to your question is covered by the "clarification on 
license compatibility"  issued by the LWG on 19 July 2011 [1]


"The intent of the Contributor Terms as regards contributions that come from 
or are derived from third parties is:


1) To ask the contributor to be *reasonably* certain that such data can be 
distributed under the specific specific licenses, as explicitly listed in 
clause 3 of the contributor terms:  CC-BY-SA 2.0 and ODbL 1.0. 
Should the license change in the future, continued distribution 
of some data that comes from or is derived from third parties may no longer 
be possible. If this happens, it will have to be removed. This will be the 
responsibility of OSMF."


Should the licence change to something other than CC-BY-SA 2.0 or ODbL 1.0, 
OSMF have guaranteed that they will identify and remove any data 
incompatible with that licence.


Incidentally, I believe that the burden OSMF have imposed upon themselves 
makes it almost certain that no other licence than CC-BY-SA 2.0 or ODbL 1.0 
would ever be used.


David

[1] 
https://docs.google.com/document/preview?id=1-sm2NCRPBKQnb3dn8CFORi5RNE_JpdG02rwYVjLJppI&pli=1



How can a contributor import any data and keep the data open to
license change? How can you keep any imports at all from people who
have not agreed to the CT directly?

thanks
mike

--
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion 
http://SpeedyDeletion.wikia.com

Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3





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

Re: [OSM-talk] diversity amongst DWG members

[Tom Hughes]

On 20/09/12 12:46, Lucas Nussbaum wrote:


Following the discussion on the infamous french Cadastre '"imports"',
I've tried to find the country of living of the DWG members (according
to http://www.osmfoundation.org/wiki/Data_Working_Group):
   Matt Amos (OSMF Board) ; Matt ; UK
   Tom Hughes ; TomH ; UK
   Paul Norman ; pnorman ; near Vancouver, Canada
   Frederik Ramm ; ? ; Germany
   Henning Scholland ; ? ; Germany?
   Grant Slater ; ? ; UK
   Dave Stubbs ; randomjunk ; UK
   Richard Weait ; rw__ ; Toronto, Canada


I have not been a DWG member for some time now (well over a year I think).

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-talk] Import guidelines proposal update

[Jean-Marc Liotier]

On 20/09/2012 13:18, Lester Caine wrote:
Go on wiping and reloading every time the source data is updated and 
manually merging everything.
Sounds ugly doesn't it ? Because it is. Wouldn't it be much better if 
each building from the cadastre had a UUID that could be traced so that 
differential imports could be performed with little disturbance and 
little manual work ? Yes. But sadly that is not how the French cadastre 
works : it is just a bunch of georeferenced images.


So the user of cadastral data has to repair the buildings split where a 
cadastral plot limit is drawn across, check for proper geographic 
referencing using GPS traces, imagery and geodesic reference points, 
expunge the data that describes buildings that are already in OSM, check 
the general sanity of the data, remove the occasional artefacts... I 
don't like it either - it is a lousy cadastre but that's the only one we 
have.



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

[OSM-talk] If you're on Twitter

[Richard Fairhurst]

...you might like to retweet this:

http://twitter.com/openstreetmap/status/248759285801185281

:)

cheers
Richard


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

Re: [OSM-talk] Bing aerial imagery priorities

[Svavar Kjarrval]

Would be nice if they would fix the aereal images in the capital area in
Iceland on the border of Reykjavík and Kópavogur. There are some major
residential areas which can't be adjusted according to imagery due to
that. I'm sure they actually have the images but haven't chosen which
ones to apply to the empty areas.

- Svavar Kjarrval

On 20/09/12 07:28, Hendrik Oesterlin wrote:
> "Hendrik Oesterlin" wrote on 18/06/2011 at 16:27:27 +1100
> subject "[OSM-talk] Bing aerial imagery priorities" :
>
>> "Steve Coast" wrote on 17/06/2011 at 08:09:37 +1100
>> subject "[OSM-talk] Bing aerial imagery priorities" :
>>> I'm speaking personally and there are no guarantees here but I'd like to
>>> get input on what areas you would like Bing to prioritise for aerial 
>>> and/or satellite imagery in the coming year. Please mail 
>>> sco...@microsoft.com with the area in question (I'd love to accept 
>>> bounding boxes but don't really have the time so cities/countries are 
>>> the best).
>>> I will pass this on to the right people and we may or may not be able to
>>> help.
>>> Thanks
>>> Steve
>> New Caledonia and its islands would need some more high res imagery...
> Thank you Steve there are now good new imagery available for mainland
> New Caledonia.
>
> BTW: Is it possible to have both the older imagery and the new one
> available? On the new imagery some of regions are cloudy while on the
> old imagery this regions are clear.
>
> On the Loyalty Islands (Ouvéa, Lifou, Maré) there is no imagery jet:
> http://www.openstreetmap.org/browse/relation/379252
>
> Is it possible to put some imagery there?
>




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

Re: [OSM-talk] diversity amongst DWG members

[Jonathan Bennett]

On 20/09/2012 12:46, Lucas Nussbaum wrote:
> It would certainly be helpful if more local communities would have one
> of their members amongst the DWG members.

It certainly would -- those local communities who feel they need better
representation should decide amongst themselves who they want to
nominate, and then that person can join in with DWG (and any other OSMF
WG they feel is appropriate).



-- 
Jonathan (Jonobennett)

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

Re: [OSM-talk] diversity amongst DWG members

[Floris Looijesteijn]

According to the Plan 2012 PDF they intend to look for new members...

Personally I think they're doing a great job and I would not want to take
their place.

Greets,
Floris

On Thu, Sep 20, 2012 at 1:46 PM, Lucas Nussbaum wrote:

> Hi,
>
> Following the discussion on the infamous french Cadastre '"imports"',
> I've tried to find the country of living of the DWG members (according
> to http://www.osmfoundation.org/wiki/Data_Working_Group):
>   Matt Amos (OSMF Board) ; Matt ; UK
>   Tom Hughes ; TomH ; UK
>   Paul Norman ; pnorman ; near Vancouver, Canada
>   Frederik Ramm ; ? ; Germany
>   Henning Scholland ; ? ; Germany?
>   Grant Slater ; ? ; UK
>   Dave Stubbs ; randomjunk ; UK
>   Richard Weait ; rw__ ; Toronto, Canada
>
> So, it seems that only three countries are represented, that half of the
> members are UK residents, and that 6 out of the 8 members are native
> english speakers, the other two being native german speakers.
>
> Are there plans to increase diversity amongst members of the DWG?
> It would certainly be helpful if more local communities would have one
> of their members amongst the DWG members.
>
> Lucas
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] diversity amongst DWG members

[Grant Slater]

On 20 September 2012 12:46, Lucas Nussbaum  wrote:

>   Grant Slater ; ? ; UK

I am South African, but currently living in the UK. I speak English
and Afrikaans.
http://osm.org/user/Firefishy

/ Grant

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

[OSM-talk] diversity amongst DWG members

[Lucas Nussbaum]

Hi,

Following the discussion on the infamous french Cadastre '"imports"',
I've tried to find the country of living of the DWG members (according
to http://www.osmfoundation.org/wiki/Data_Working_Group):
  Matt Amos (OSMF Board) ; Matt ; UK
  Tom Hughes ; TomH ; UK
  Paul Norman ; pnorman ; near Vancouver, Canada
  Frederik Ramm ; ? ; Germany
  Henning Scholland ; ? ; Germany?
  Grant Slater ; ? ; UK
  Dave Stubbs ; randomjunk ; UK
  Richard Weait ; rw__ ; Toronto, Canada

So, it seems that only three countries are represented, that half of the
members are UK residents, and that 6 out of the 8 members are native
english speakers, the other two being native german speakers.

Are there plans to increase diversity amongst members of the DWG?
It would certainly be helpful if more local communities would have one
of their members amongst the DWG members.

Lucas

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

Re: [OSM-talk] Import guidelines proposal update

[sly (sylvain letuffe)]

> The 'mechanisms' that we use MUST be managed centrally, 

What are you talking about ? What "mechanisms" are you refering to ?

> and it is this mechanism that is currently BROKEN when handling 
> imported data? 

Are you talking about the mechanism that "the dwg is blocking users not using 
a dedicated account for any third changeset over 10k objects wich looks like 
an import to them" ?
Well, I won't use such a word as "broken" since it has proven usefull for 
several cases to prevent and detect vandalism, but I'll be glad to use the 
world "not optimal and to be improved"

> We do not have a robust process in place world wide so we don't  
> want groups running creating their own isolated processes?

Sorry to say it again, but I don't understand you, could you be more precise 
with a specific example ? what "robust process" are you talking about ? which 
isolated processes ?


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Lester Caine]

sly (sylvain letuffe) wrote:

We can get back to the topic of governance and discussion about those laws and
who decide them, and how.

Or just get back to fixing the process in the first place?
SO we have less chance of misinterpreting the 'guidelines'?

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Import guidelines proposal update

[Lester Caine]

sly (sylvain letuffe) wrote:

there's also the technical or procedural aspect (...)
>I don't think these should be decided locally.

And that's where we disagree. Your are not accepting any distinction about all
different cases in your statement, and it seams you are implicitly denying
the ability of the local community to decide wisely.


sly - take a step back.
The 'mechanisms' that we use MUST be managed centrally, along with the core 
software, and it is this mechanism that is currently BROKEN when handling 
imported data? We do not have a robust process in place world wide so we don't 
want groups running creating their own isolated processes?


Now I have no doubt there are some clever people in every local workgroup who 
can take their own data sources and manipulate them in a way that can then be 
imported into the main database. There are no objections to that. Some imports 
will be geo-referencing new raster layers and there is no dispute about that 
process, but when it comes to 'importing' raw data there are big holes in the 
process world wide which still need plugging rather than local groups plouging 
on down their own 'agenda'. Now if there is no interest in supporting a central 
mechanism to work towards AUTOMATICALLY importing LOCALLY processed data then so 
be it. Go on wiping and reloading every time the source data is updated and 
manually merging everything. I happen to think that is the wrong way of doing 
it, but in the case of the French data I don't have the information to suggest 
anything else :( In the case of the UK data we know how, we are just not allowed 
to yet double :(


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Lester Caine]

Pieren wrote:

Check the list of arguments presented here for the mandatory separate account:


Pieren - please stop banging on about this - we know that the current process is 
flawed but it WAS put in place when problems arose in the Canadian imports, and 
it IS current practice. If one 'local group' is treated as a 'special case' then 
we will get into a cycle of 'me to' so please lets not got there.


In your particular case, there are arguments either way, and it may be 
appropriate for someone to say sorry, I don't know that anybody has particularly 
done anything wrong - on either side! - it is just a matter of 
miss-understanding what people are saying? On both sides?


Lets move all this energy into fixing the process and getting a robust mechanism 
moving forward!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Import guidelines proposal update

[sly (sylvain letuffe)]

> > I'd like to propose a change on the wiki page :
> > http://wiki.openstreetmap.org/wiki/Import/Guidelines
> 
> I think that imports, or all automated edits, have multiple aspects. 
Up to that point, we fully agree. 

> there's also the technical or procedural aspect (...)
> I don't think these should be decided locally.
And that's where we disagree. Your are not accepting any distinction about all 
different cases in your statement, and it seams you are implicitly denying 
the ability of the local community to decide wisely.
What I miss is trust, I don't think we can build a world community of local 
communities if no trust is transfered to local communities (or is it a local 
chapter ? I have no clues about what differences there are)

There is a big diplomatic difference between :
"We don't belive your local community is wise enough, so we decide of 
technical and procedural aspects for you and block your users if they don't 
follow this guideline"
and
"We trust your self governance, here is the key to block your own members, we 
are here to back you up in case of emmergency, please designate x 
representative of your community we can talk to, and here are the guideline 
we wish you enforce respect to your members"

> In the coming years we'll hopefully (...) discussion about what the local
> chapters  can decide by themselves and what not.

Any reasons to wait for years ? That's exactly the discussion we are having 
now about a real case need, we have sent a representative of our community we 
trust, I have a proposal for the first rule to be discussed and agreed upon.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Pieren]

On Thu, Sep 20, 2012 at 9:34 AM, Lester Caine  wrote:

Check the list of arguments presented here for the mandatory separate account:

1. "it's easier to separate from normal contributions"
2. "it's more effecient for sourcing"
3. "it's easier to identify the source if we change the license. We
faced that issue in the past for ODbl transition"

1. We said we upload sourced elements. We can easily identify the
changesets. We already reverted bad imports ourselves. Using the same
account was never an issue for us.
And let say, I create my 2nd account. What happens if I use it for
normal contributions ? I will be blocked by the DWG ? Probably not.
Finally I could stay and always contribute with my 2nd account. Or
what will distinguish my import account(s) to my normal contribtuion
account for the DWG ? Attributions in the profile ? Are we blocked if
we specify more than one attribution in the user profile ? Are we
blocked if our contributions do not correspond to the attribution in
the user profile ? or if the DWG is not able to understand/translate
it ?

2. They are other methods for sourcing, each with pros and cons
(available or not in exports, duplicates, etc). And sourcing is
complex because many contributions are mixing several sources. And
rebuilding the whole history of an element is not trivial.

3. In our case, the dataset is released in a kind of "Public Domaine"
where only attribution is required. The risk about a licence change is
null (and it was not an issue for the cc-by-sa to ODbl transition).

Pieren

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[sly (sylvain letuffe)]

On jeudi 20 septembre 2012, Marc SIBERT wrote:
> > The complete
> > ignorance of any contact (threre have been two or three tries) was the
> > reason for the (short term) block, not the disregard of the guidelines.
> >
> In fact I *did* answer twice, in March & September. I explain my point of
> view and the special case of Cadastre import. I do not receive any answer
> after my response, excepte a blocked account a few days ago.
> Nothing to do with foreign language in my personnal case.

Ouch !
I do trust what Marc says, and I guess he has proof to back this up.

What we have then ?
We don't have any discussion at all, and Marc isn't at fault here.
we have a group of admin using their blocking power after sending semi 
automated email without bothering to understand the contributor's answers and 
not refering to the local community he belongs to.

It is clear that this was an enforcement of guidelines "best practices" 
transformed into laws, no need to try to find the reason elsewhere.
We can get back to the topic of governance and discussion about those laws and 
who decide them, and how.

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk] Import guidelines proposal update

[Vincent de Chateau-Thierry]

Hi,

> De : "Michael Kugelmann" 
> On 19.09.2012 23:45, Vincent de Chateau-Thierry wrote:
> > The only criteria for removing French Cadastre data will be the value 
> > of the source tag. 
> That's a bad idea: if someone for what ever reason just decides to 
> remove (or change) the "source=cadastre" tag of a object (and don't 
> change anything else) you can't identify the object any more.
> Or to be more precise: you need to use a lot of effort and check all 
> versions of an object (this means: the whole planet) whether it once had 
> the "source=cadastre" tag. But thats a lot of work to do. Much (!) more 
> easy to identify all the object is if you can take all object created by 
> a special account => just check the changesets.
> Checking all versions of all objects is the thing we just went through 
> with a lot of pain and effort: creating and using the redaction bot. And 
> we are all aware that this was necessary but not nice and a lot of 
> "unporoductive effort". So let's learn from the past and avoid possible 
> issues in the future that can be done easily with very small aditional 
> effort in the presence.
> 

That means that a separate ccount is a way of identifying contributions 
depending
on their source. I can understand that such way is a good practice when a given 
source
is strongly linked to a way of dealing with it : massive upload or single edit.
But the problem with french cadastre remains the same since it is both used in 
massive
_and_ single object uploads.
In my previous mail I pointed out a way :
http://www.openstreetmap.org/browse/way/181674272
This way has one of its nodes which stand for a amenity=cafe :
http://www.openstreetmap.org/browse/node/1920879534
Both geometry of the way and tags for the node come from the same changeset, 
since
I added them at the same time. But node information does not come from the 
Cadastre, it 
is my own survey.
With the separate-account-by-source suggestion, I would have :
1- started JOSM with my account-for-import (which does not exist yet :-) )
2- drawn the way, tagged with "building=yes" and source="Cadastre"
3- uploaded it
4- exit from JOSM and restart with my regular account
5- edited the node tags
6- uploaded 
Wow I don't think such process is "productive". It is artificialy time 
consuming
with basically no gain at all.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk] Import guidelines proposal update

[Pieren]

On Wed, Sep 19, 2012 at 10:55 PM, Richard Weait  wrote:

> I've combined their responses and made them generic.

I take my turn to combine your arguments:

> - "Too hard to register with another email."  I say use
> username+osmimp...@yourisp.com if they support it.  Alternatively,
> those concerned in the French community can surely offer their members
> additional email accounts to support their community.

- Uploading other contributor's work is probably breaking another
"guideline". Using a single separate user account or a proxy user for
all users has been already suggested. It would comply with the import
guideline but we don't want that.

> - "I don't want to change account settings in JOSM."  I say start josm
> with alternate josm.home directory with your saved credentials.  Like:
> java -Xmx2038M -Djosm.home=/home/username/import -jar
> /home/username/bin/josm-latest.jar

- in Europe, the trend is to open more and more public geodata. It's
usual to find contributors uploading external data from 2, 3 or 4
different sources. Each will require a different user account, a
different email address and a different JOSM preference file. Each
time you change something in your preference, you will have to repeat
it in all your homes.

> - "Cadastre is not an import."  Cadastre is an import.  Could you do
> the same thing if there were no Cadastre to import?  No,

- Untrue. The cadastre is also available as WMS. We started by tracing
manually over raster images. I guess what UK users are doing today
with OS buildings, we did it in the past until we were able to
retrieve the vector data.

> - "Cadastre is different; I am careful before I upload."  All mappers
> are careful don't insult the rest of the community. :-)  Fixing and
> reconciling data before upload is the obligation you have when
> contributing.  Cadastre is still an import.

- I agree. Cadastre is an import, but not a blind, automated, large
scale import done after conflation on a GIS application.

> - "No. I want credit for all of my mapping statistics all in one
> place."  Simplest to fix.  UserStat now allows you to combine stats
> from a group of your accounts.

- nobody came here for statistics.

Pieren

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

[OSM-talk] OSM Data layers

[Arun Ganesh]

The import guideline thread spam got me thinking about how such an issue
could be solved cleanly. I have forever had a problem with the OSM data
being one big blob instead of using all that semantic information to group
and organize the objects.

There are a host of issues like importing datasets without breaking
existing data and also the case of historical mapping. I'm no computer
scientist nor have I been following mails to know if this was already
discussed before, but I put down some fantasies I had about a future osm
data layer model on the wiki:

http://wiki.openstreetmap.org/wiki/OSM_Layers

Once again, I have no technical knowledge to reply to any questions on how
this will work, but I hope someone can take something out from it and fix
OSM for the better.

-- 
 Arun Ganesh
(planemad) 
 
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Import guidelines proposal update

[Lester Caine]

Frederik Ramm wrote:

But besides the "content" aspect, there's also the technical or procedural
aspect - things like where and how to document your import, or whether or not
you need a separate import account, or whether it is acceptable to do
large-scale imports with an account the name of which signals disdain for the
project. I don't think these should be decided locally.


Seconded
There are perhaps three separate discussions here ...
1 - How fine a detail should be allowed?
2 - Is the style of raw imported data acceptable to OSM?
3 - Do we need to be able to identify a raw import?

The first is more of a problem than the other two?
People mapping at a macro level only using the same was as the road, boundary, 
edge of building, and so on make it difficult for those of us who are now adding 
the footpaths between that road and building. And some will always oppose adding 
some types of data - such as building. I have no problem with adding the coble 
stones but as an area tagged such, which may actually be the road! The automatic 
reduction of that area to a way for routing is another matter?


The second links to the first when we import a course dataset and it needs to be 
reworked to fit into the OSM 'guidelines'. It may be preferable NOT to import 
the raw data, but provide it as an overlay for tracing? Or rework the raw data 
prior to import to a suitable format.


The third then becomes a matter of 'is this the same data that as provided by 
the raw import'. Personally I think that identifying an element against a 
unique_id from the source data SHOULD be the standard, so that hopefully in 
years to come we can simply automatically scan a new dataset and flag everything 
that has changed? That includes objects that have disappeared! We then need to 
be able to identify those items that have not been modified (point 3) and update 
them if necessary. And those that have (point 2) so we can provide a 'manual 
merge' list.


The 'separate account' was a crude attempt to provide a short term fix for 2/3 
until a proper solution was put in place, and currently is still the best way to 
identify things until a more rugged solution is provided - centrally!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] [Imports] Import guidelines proposal update

[Lester Caine]

Pieren wrote:

There definitely is not general agreement at this time that this passage
>should be changed.

Could you please point out in archives (wiki or mailing list) where
the separate account became generaly agreed ? Or you can simply tell
me the communication channel and an approximate date, I will search
myself.


Pieren - I can remember the discussion in relation to the Canadian imports, but 
I don't have time to go back through. The general jist was that it was difficult 
to separate tidying up imported data from the 'base' import, and short term it 
would not be practical to make changes to the software to identify the 
differences, so the short term fix was to 'request' that the base import had a 
different user id. With the intention that a better solution would be looked into.


We know that the process IS flawed, and that it needs tidying up, and since you 
have practical experience of handing this type of import, how about contributing 
to the overhaul? Actually where is THAT being debated?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] Bing aerial imagery priorities

[Hendrik Oesterlin]

"Hendrik Oesterlin" wrote on 18/06/2011 at 16:27:27 +1100
subject "[OSM-talk] Bing aerial imagery priorities" :

> "Steve Coast" wrote on 17/06/2011 at 08:09:37 +1100
> subject "[OSM-talk] Bing aerial imagery priorities" :

>> I'm speaking personally and there are no guarantees here but I'd like to
>> get input on what areas you would like Bing to prioritise for aerial 
>> and/or satellite imagery in the coming year. Please mail 
>> sco...@microsoft.com with the area in question (I'd love to accept 
>> bounding boxes but don't really have the time so cities/countries are 
>> the best).

>> I will pass this on to the right people and we may or may not be able to
>> help.

>> Thanks

>> Steve

> New Caledonia and its islands would need some more high res imagery...

Thank you Steve there are now good new imagery available for mainland
New Caledonia.

BTW: Is it possible to have both the older imagery and the new one
available? On the new imagery some of regions are cloudy while on the
old imagery this regions are clear.

On the Loyalty Islands (Ouvéa, Lifou, Maré) there is no imagery jet:
http://www.openstreetmap.org/browse/relation/379252

Is it possible to put some imagery there?

-- 
Sincerely 
Hendrik Oesterlin - New Caledonia


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

Re: [OSM-talk] Import guidelines proposal update

[Frederik Ramm]

Hi,

On 09/19/2012 04:24 PM, sly (sylvain letuffe) wrote:

I've read the rather long thread "Import guidelines & OSMF/DWG governance" and
I'd like to propose a change on the wiki page :
http://wiki.openstreetmap.org/wiki/Import/Guidelines


I think that imports, or all automated edits, have multiple aspects. 
Some of them can be covered by local or national policies, others cannot.


For example, I think that a local or national agreement would usually 
have the last word about what data is imported (maybe except in some 
extreme cases where the whole community suffers because someone imports 
every single cobblestone in a city but that's theoretical).


But besides the "content" aspect, there's also the technical or 
procedural aspect - things like where and how to document your import, 
or whether or not you need a separate import account, or whether it is 
acceptable to do large-scale imports with an account the name of which 
signals disdain for the project. I don't think these should be decided 
locally.


In the coming years we'll hopefully develop a good subsidiary structure 
with local chapters in all major communities, and I would expect that 
this will also bring a healthy discussion about what the local chapters 
can decide by themselves and what not.


Bye
Frederik

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

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

Re: [OSM-talk] Import guidelines & OSMF/DWG governance

[Marc SIBERT]

2012/9/19 Michael Kugelmann 

> On 19.09.2012 11:22, Christian Quest wrote:
>
>> We're voting proposed tag scheme.
>>
> ... or not. Frequently nowadays a new value or scheme is invented w/o
> voting. No statement by myself whether I think this is good process or
> not...
>
>
>  So these hard rules are coming from nowhere ? There's no process to set
>> them ?
>>
> Please read the comment of Richard (in the archive:
> http://lists.openstreetmap.**org/pipermail/talk/2012-**
> September/064300.html
> ).
>
>
>  Yes, I'm saying that editing the wiki is not clearly publishing and
>> ANNOUNCING a major change.
>>
> As stated by Richard: the change of the wiki was just a documentation of
> the best practice used since long term, I would not call this a major
> change.
>
> But to point also on the other issue which started the whole discussion:
> if someone contacts you because of you behavior (even if it is in a
> foreign language) you should not completely ignore him. The complete
> ignorance of any contact (threre have been two or three tries) was the
> reason for the (short term) block, not the disregard of the guidelines.
>
> In fact I *did* answer twice, in March & September. I explain my point of
view and the special case of Cadastre import. I do not receive any answer
after my response, excepte a blocked account a few days ago.
Nothing to do with foreign language in my personnal case.


>
> Best ragards,
> Michael.
>
> Regards,


-- 
Marc Sibert
m...@sibert.fr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk