date:20120926


ThomasB wrote:

Hang on, you've got this completely wrong.
.

Seems what you mean and what you wrote differ somehow

Richard Fairhurst wrote

And no - this isn't intended to hit restoring a single way via P1 (while
it still exists) or whatever.

But I read it so. Also selecting 10 buildings in JOSM and pressing Q would
fall below your proposal (automated geometry fixup) and require me to add
these extra tags.


Oh come on ...
This is the sort of nit picking that is the whole problem. If we have to write 
down rules that define which key press you are allowed to use then I doubt 
anybody would contribute.


Having said that though, that simple 10 building 'tidy up' would have to be 
justified if it is being applied to 10 buildings that were imported from a 
reliable data source? A lot of buildings are not 'square' certainly around here, 
and 'styling' them is as bad as deleting ones that have been tidied by other 
means and replacing them with a 'stylised' import?


I do get the impression that the Cadastre import has it's own rules on how to 
use it, and those are only available in French, which irritates. But it does 
need to follow the generic rules, which simply allow some tracking of where 
detail is sourced, and also the accuracy of that data. We have been getting some 
information on their process, but I still don't understand some of the problems 
they are flagging as reasons for the practices?


I also think that there needs to be a major distinction between BOTS which 
modify the core data, and import processes which are simply mapping a data 
source into a format that can be merged. I think that THIS is another 
misconception that is causing confusion. I would certainly not view manually 
marking up data from a data source layer, adding additional tags, and then 
merging into the core data. As I've been proposing in other threads, carrying a 
uneditable tags with data seems essential these days? In this case the core 
elements that are copied would have a tag identifying the source and having now 
spent some time looking into this I'd even go as far as flagging when someone 
tries to edit detail that IS identified as coming from a trusted source? Or more 
important that it has been processed DURING the base data 'import'. Which is the 
main reason I'm seeing 'layers' as the main path forward here. Cadastre is at 
least two layers, the original raw data, and a processed view of that data from 
which objects are 'imported' into 'osm'. Both of those layers should be 
accessible for all of us to at least view and it's managing that which is the 
first step here?


So in light of the above, I don't recognise the use of 'bot' tags in some of 
these cases. That really is a different matter relating to changing the data? A 
bot that 'squares up all buildings' would certainly not be appropriate, but it 
might well be as part of creating a 'stylised layer' view of the data?


The project IS the data, not the maps, and ALL of the data is important, not 
just a 'current view' of what people think matter for 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] Proposal for import guidelines

2012-09-26 Per discussione Richard Fairhurst

ThomasB wrote:
 Seems what you mean and what you wrote differ somehow

I'm not sure where you read the extra requirement for discussion or
bureaucracy in what I wrote. Could you clarify?

 But I read it so. Also selecting 10 buildings in JOSM and 
 pressing Q would fall below your proposal (automated 
 geometry fixup) and require me to add these extra tags.

That qualifies as manual drawing actions rather than automated. I was
seeking to address things like xybot's bulk geometry corrections. But if you
have a suggestion for better wording, I'm all ears. :)

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Proposal-for-import-guidelines-tp5727448p5727567.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Multiple Layers for OSM

2012-09-26 Per discussione Jochen Topf

On Tue, Sep 25, 2012 at 12:28:56PM -0700, Dave Sutter wrote:
 It is harder to build because there is added functionality. You have to 
 replace auto ID generation, which isn't too complicated. I'm not sure what 
 you mean about robustness.

robustness is about the behaviour of the system in case of failures.
In this case all servers (which might be a lot in the future) depend
on a single server to give out IDs. If that one doesn't work (or the
network to it), the whole system fails. Of if a random server requests
huge amounts of ID blocks it could bring down the ID server or we could
run out of IDs.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298

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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Jochen Topf

I think there is a misunderstandig here. You seem to suggest that according to
those new guidelines you are supposed to import the data with one account and
then in a second step fix things with the normal account. This is not the case.
It has been a long-standing policy that (whether you do normal edits or any
kind of import) you are supposed to always leave the map in a good state.

In fact it is the biggest problem with imports that people do the import but
don't integrate the data with whats already there. The French community has
been doing that right all along.

Jochen

On Tue, Sep 25, 2012 at 11:36:51PM +0200, Eric Marsden wrote:
 Date: Tue, 25 Sep 2012 23:36:51 +0200
 From: Eric Marsden eric.mars...@free.fr
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] Proposal for import guidelines
 
 Thank you for making this constructive proposal. My feeling is that it
 would constitute a positive change to the current DWG import guidelines,
 which are greatly lacking in subtlety. 
 
 Allow me to point out, and illustrate with the French cadastre case, a
 problem posed by the wish strictly to separate the import component of
 a bulk edit (corrected/checked building geometries) from the
 integration component (resolving conflicts with existing building
 geometries and their tags, improving highway geometries using the high
 resolution cadastre information, etc.). Under the current (French)
 community guidelines for integrating this data, these two steps are
 combined in a single changeset. Separating them would lead to a
 situation where, during the period between these two changesets, the
 database is in an inconsistent state (overlapping buildings, highways
 passing through buildings, etc.).
 
 Whilst this temporary inconsistency in the data is not as severe as it
 would be in a software development project, for instance (the dreaded
 FTBFS), it is rather dirty and could lead to false alerts in error
 checking software.
 
 Whether this data consistency problem is more or less significant than
 the improved tracability of data source copyright that is afforded by
 the proposed import/integration separation is debatable. In my view, the
 costs of the proposed change outweigh its benefits (at least as far as
 the French cadastre situation is concerned -- other bulk edits/imports
 will likely have different tradeoffs). 
 
 -- 
 Eric Marsden
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298

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

Re: [OSM-talk] Proposal for import guidelines

 De : Lester Caine les...@lsces.co.uk

Hi Lester

 I do get the impression that the Cadastre import has it's own rules on 
how to use it, and those are only available in French, which irritates.
You mean you would appreciate a translation of French Cadastre wiki page ?


 But it does need to follow the generic rules, which simply allow some 
tracking of where detail is sourced, and also the accuracy of that data.
Every objects coming from cadastre have a tag source mentionning cadastre. 
This is mandatory and required by French Cadastre to be integrated in 
OSM


 We have been getting some information on their process, but I still 
don't understand some of the problems they are flagging as reasons for 
the practices?
Could you precise which problems you do not understand so we can clarify ?

 import processes which are simply mapping a data source into a format that 
 can be merged.
Concerning French cadastre the manual work to merged the data is quite huge 
whereas for CLC import it was automatically done. Do you consider that this 
manual work is part of the import process or not ?

 I thinks that THIS is another misconception that is causing confusion.
To avoid confusion and misconception is there somewhere an exhaustive clear and 
preceise list of objectives of Guidelines imports rules ?
It would be good to have such a list to be sure that we discuss about the same 
things and the same goals.
It would also allow to discuss on facts and technical points and perform an 
objective evaluation of strengh and weaknesses of various proposal.
For the moment I`m not sure that everyone has the same vision of what we are 
doing and which goals we want to reach.


 Cadastre is at least two layers, the original raw data, and a processed 
view of that data from which objects are 'imported' into 'osm'. Both of 
those layers should be accessible for all of us to at least view
The original data are available on cadastre website cadastre.gouv.fr
The processed data are available town by town on cadastre.openstreetmap.fr
The data after user manual processing in order to solve issues ( coherency with 
existing OSM data, artefacts not detectable by processing scripts etc ) are the 
one sent to OSM ( Data coming from cadastre avec source flag)


Cheers 

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

Re: [OSM-talk] Bad (wrong?) OSM publicity?

2012-09-26 Per discussione Grant Slater

On 26 September 2012 04:19, Daniel Kastl dan...@georepublic.de wrote:

 On Wed, Sep 26, 2012 at 12:59 AM, Jeffrey Warren j...@unterbahn.com wrote:

 OpenStreetMap Japan, a Wikipedia-like service that contains a lot of
 incorrect and outdated information.


 that is really awful. We can't let that kind of statement stand! It
 affects the credibility of all OSM efforts, and is like the kind of FUD
 Wikipedia saw early on. Any possibility of getting a retraction? Though
 really that doesn't even cover it. Some kind of very public rebuttal.


 OSMF Japan (the local Japanese chapter) has already contacted the writer as
 well as the interviewed person and I think there will be an appropriate
 update/correction of the statement.


Meanwhile, contributors to the crowd-sourced service OpenStreetMap
Japan reacted angrily to suggestions by Mapion, a local Japanese map
provider, that the crowdsourcing may have been behind errors in
Apple’s maps. 
http://bits.blogs.nytimes.com/2012/09/25/japanese-look-for-alternatives-to-apples-maps/

/ Grant

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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Eric Marsden

 jt == Jochen Topf joc...@remote.org writes:

  jt I think there is a misunderstandig here. You seem to suggest that 
according to
  jt those new guidelines you are supposed to import the data with one account 
and
  jt then in a second step fix things with the normal account. This is not the 
case.
  jt It has been a long-standing policy that (whether you do normal edits or 
any
  jt kind of import) you are supposed to always leave the map in a good state.

  This means that the import account will agglomerate contributions
  sourced from the import (cleaned up building outlines, for instance)
  and a large number of ordinary, manual edits/improvements (improving
  the road network's geometric precision, adding tags) which are sourced
  from Bing, GPS traces, personal knowledge, etc. Individual changesets
  will be a mix of data from different sources, with different
  copyrights.

  Since there is no change to the clarity of copyright status, I really
  don't understand the point of a separate account for this type of
  import (obviously country-wide, mechanical CLC-type edits are different). 

-- 
Eric Marsden


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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Richard Mann

I think the distinction between mechanical and manual needs to be fleshed
out a bit. To me manual implies a degree of care to other data (relative
location of existing objects, links to other objects, existing versions of
the same or related objects, other tags, consideration of the quality of
the source, cross-referencing to other sources, that sort of thing). The
amount of care depends on what you're doing, but obviously has a tendency
to decline if you're dealing with more data. Telling people that they're
not taking enough care is likely to annoy them. Asking them to
self-describe themselves as a bot when they're taking a lot of care is
also insulting.

So I'd choose some tag names that are a bit less loaded.

But the principle that changesets should have a licence tag where that's
clear/available is a sensible one. As is the message keep your changesets
at human-scale or set up a separate account.

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

Re: [OSM-talk] Bad (wrong?) OSM publicity?

2012-09-26 Per discussione Peteris Krisjanis


 Meanwhile, contributors to the crowd-sourced service OpenStreetMap
 Japan reacted angrily to suggestions by Mapion, a local Japanese map
 provider, that the crowdsourcing may have been behind errors in
 Apple’s maps. 
 http://bits.blogs.nytimes.com/2012/09/25/japanese-look-for-alternatives-to-apples-maps/
 

Thanks Woll Newall for writing that email, OSM got nicer exposure here.
Let's hope someone will be tempted to try it out :)

Peter.


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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Peter Wendorff


Am 26.09.2012 10:30, schrieb THEVENON Julien:

* De :* Lester Caine les...@lsces.co.uk

Hi Lester

* *I do get the impression that the Cadastre import has it's own 
rules on how to use it, and those are only available in French, which 
irritates.

You mean you would appreciate a translation of French Cadastre wiki page ?

* *But it does need to follow the generic rules, which simply 
allow some tracking of where detail is sourced, and also the accuracy 
of that data.
Every objects coming from cadastre have a tag source mentionning 
cadastre. This is mandatory and required by French Cadastre to be 
integrated in OSM


* *We have been getting some information on their process, but I 
still don't understand some of the problems they are flagging as 
reasons for the practices?

Could you precise which problems you do not understand so we can clarify ?

* *import processes which are simply mapping a data source into a 
format that can be merged.
Concerning French cadastre the manual work to merged the data is quite 
huge whereas for CLC import it was automatically done. Do you consider 
that this manual work is part of the import process or not ?
Yes, it is part of the import process, as it's the main preparation of 
the import.
When we import a list of facilities we get from a third party, e.g. 
the fuel station import last year, most of the time the raw data is not 
fitting to osm needs very well.
Most of the time there's some kind of preprocessing, be it manually or 
automatically - and if it's done by a bot that bot usually has to be 
developed, too.

All this is part of the import process IMHO, yes.
* *I thinks that THIS is another misconception that is causing 
confusion.
To avoid confusion and misconception is there somewhere an exhaustive 
clear and preceise list of objectives of Guidelines imports rules ?
It would be good to have such a list to be sure that we discuss about 
the same things and the same goals.
It would also allow to discuss on facts and technical points and 
perform an objective evaluation of strengh and weaknesses of various 
proposal.
For the moment I`m not sure that everyone has the same vision of what 
we are doing and which goals we want to reach.


* *Cadastre is at least two layers, the original raw data, and a 
processed view of that data from which objects are 'imported' into 
'osm'. Both of those layers should be accessible for all of us to at 
least view

The original data are available on cadastre website cadastre.gouv.fr

All versions?
It was said that there are new versions every few years. Do the old, 
then outdated versions stay there?
Apart from that while OSM basically has English as the lingua franca, I 
think it's a bad idea to rely on French only for documentation - inside 
osm as well as for outside documentation like cadastre.gouv.fr.


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

Re: [OSM-talk] Proposal for import guidelines


THEVENON Julien wrote:

* *I do get the impression that the Cadastre import has it's own rules on
how to use it, and those are only available in French, which irritates.
You mean you would appreciate a translation of French Cadastre wiki page ?

That has been a previous request :) The google translation is a little strange.


* *But it does need to follow the generic rules, which simply allow some
tracking of where detail is sourced, and also the accuracy of that data.
Every objects coming from cadastre have a tag source mentionning cadastre. This
is mandatory and required by French Cadastre to be integrated in OSM

And if we can automate that process it would help you?


* *We have been getting some information on their process, but I still don't
understand some of the problems they are flagging as reasons for the practices?
Could you precise which problems you do not understand so we can clarify ?
I'm just repeating things that were being quoted earlier, but I would like to 
have a look at the data myself to see if we are talking about the same things. 
Accessing the French data is difficult for a non French speaker :(



* *import processes which are simply mapping a data source into a format
that can be merged.
Concerning French cadastre the manual work to merged the data is quite huge
whereas for CLC import it was automatically done. Do you consider that this
manual work is part of the import process or not ?

That part of the process simply needs to be identified.
I'm still pushing here for a more robust process that will simplify merging this 
data in future, and the bulk delete that prompted the debate is an example of 
where data HAS already been imported, so the PROCESS to import it needs to be 
addressed ... which is partly being addressed by the layers discussion.
Importing material to work with is the 'automatic' bit, and processing a new 
version of the data to merge with existing data is 'automatic'. See below ...



* *I thinks that THIS is another misconception that is causing confusion.
To avoid confusion and misconception is there somewhere an exhaustive clear and
preceise list of objectives of Guidelines imports rules ?
It would be good to have such a list to be sure that we discuss about the same
things and the same goals.
It would also allow to discuss on facts and technical points and perform an
objective evaluation of strengh and weaknesses of various proposal.
For the moment I`m not sure that everyone has the same vision of what we are
doing and which goals we want to reach.

Totally agree ...
Many of my own requirements have already been addressed via other 'improvements' 
and being able to access a range of historic maps geo-referenced to the base 
'layer' is allowing me to create my own data. But *I* would like to be able to 
combine the simple 'start_date' information into a single layer whch is fine 
where an object still exists, but often nowadays newer 'estates' replace the old 
terraces, or areas bombed out in the past :(



* *Cadastre is at least two layers, the original raw data, and a processed
view of that data from which objects are 'imported' into 'osm'. Both of those
layers should be accessible for all of us to at least view
The original data are available on cadastre website cadastre.gouv.fr
The processed data are available town by town on cadastre.openstreetmap.fr
The data after user manual processing in order to solve issues ( coherency with
existing OSM data, artefacts not detectable by processing scripts etc ) are the
one sent to OSM ( Data coming from cadastre avec source flag.
I can't access the government data as an overlay? The English translation is a 
little light, but I suspect this only give hard copy output? IS the raw data 
available in a manor that we can access directly in a josm or something similar?


The cadastre.openstreetmap.fr seems to a similar problem? I can select a 
Department and then in some cases Ville, but nothing seems to happen?


There is obviously good data available, and all I'm asking is some help in 
viewing it. In the same manor as data is being made usable elsewhere ;) The UK's 
OS data is available as 'layers' we can work with, and it would be nice to see 
the French data similarly available. We have to process the raw OS data into a 
raw format that is correctly geo-referenced, and that raw data is available, so 
I would anticipate that the French data has had similar processing? Is that raw 
data available anywhere? Having got the raw layer(s) we NOW need to process them 
into a 'staging' layer which can be used to integrate later updates - all of 
which should be made available as raw layers - but the staging layer would be 
the one that flags what has or has not been merged. So I'm not sure if 
cadastre.openstreetmap.fr is your 'raw data' layer, in which case there should 
be a 'version select' or your staging layer?


We are missing tools to make all this work, but they are the same tools world 
wide, and we just need

Re: [OSM-talk] Bad (wrong?) OSM publicity?

2012-09-26 Per discussione woll

I was a bit surprised to see the second article:
http://bits.blogs.nytimes.com/2012/09/25/japanese-look-for-alternatives-to-apples-maps/
which had quotes from myself buried in it!

I was expecting to see some kind of up-front retraction on the original
article itself, with input from the local, Japanese-speaking OSM members
that I know have contacted the journalist. I guess that because the NYTimes
is an English-language site, response from an English-speaker/writer was
easier to use?

I think that the original article still needs correcting, because that's the
one that seems to have been linked to from numerous places.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Bad-wrong-OSM-publicity-tp5727276p5727598.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Proposal for import guidelines


Richard Mann wrote:

But the principle that changesets should have a licence tag where that's
clear/available is a sensible one. As is the message keep your changesets at
human-scale or set up a separate account.


Tagging the change set is against the data source is a must.
But I think that a simple 'read-only' tag that automatically identifies the base 
data set is something that is making sense to me. On each object, since looking 
down change set history to find it does not make sense?


This would at least allow editors to issue warnings when a change is made to 
detail provided from a 'trusted' source. The 'squaring up' buildings hit a raw 
nerve with me simply because I DO have to take care of the non-squareness of 
many structures around here and it's those sorts of tidies that could cause more 
problems! - even in the French data?


Being able to pull up an overlay of the original source data when a warning is 
created would also be helpful.


--
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] Proposal for import guidelines

2012-09-26 Per discussione Tobias Knerr

On 26.09.2012 10:13, Richard Fairhurst wrote:
 I'm not sure where you read the extra requirement for discussion or
 bureaucracy in what I wrote. Could you clarify?

Discussion and bureaucracy requirements exist for automated/mechanical
edits according to the policy pages you would like to see combined into
one with with this guideline. Thus your attempted definition of
automated edits seems quite relevant.

Also, your proposed text includes the requirement to create and link to
a documentation page, which imo qualifies as bureaucracy:

 bot_url=link to a page describing the automated edit

 But I read it so. Also selecting 10 buildings in JOSM and 
 pressing Q would fall below your proposal (automated 
 geometry fixup) and require me to add these extra tags.
 
 That qualifies as manual drawing actions rather than automated. I was
 seeking to address things like xybot's bulk geometry corrections. But if you
 have a suggestion for better wording, I'm all ears. :)

If you want to address changes performed by scripts/bots, then why don't
you just say so explicitly and avoid any potential misunderstandings?

==

An 'automated edit' is one where the editing is not carried out by
manual drawing actions. This includes (but is not limited to):

- imports of external data without inspection of individual objects
- any changes performed by a script/bot

==

Of course there are special cases where e.g. a powerful editor is used
to blindly do the exact same thing a script would do, but things like
these are what the not limited to is for.

As for reverts, I wouldn't mention them here at all. There should be
guidelines for them, yes, but they should be looked at separately. Some
of the concepts related to reverts (such as contacting the original
changeset's author personally first, or even dealing with explicit
revert requests by said author) don't really exist elsewhere.

Tobias

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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Richard Fairhurst

Tordanik wrote:
 If you want to address changes performed by scripts/bots, then  
 why don't you just say so explicitly and avoid any potential 
 misunderstandings?

Because it's not just about scripts and bots. The Cadastre situation, which
started all of this off, is often people loading .osm files into JOSM,
running a quick validator check over it, and uploading. In terms of impact
on the map and on the community, there is no significant difference between
this and the same operation using upload.py.

(On a matter of language: if you want to... then why don't you just say
so? comes across as really quite hostile in English. I won't assume that
it's meant as such, as I recognise that English isn't everyone's first
language on this list. However, this is intended as a constructive
suggestion to solve an impasse which we've reached and a rather less hostile
tone would be nice. It doesn't actually make any difference to me personally
- I only _use_ OSM data for the UK, where we don't have imports, and I'm not
on DWG so I don't have to deal with the angry mails. I'm simply trying to
help and getting hostile doesn't really encourage that.)

Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Proposal-for-import-guidelines-tp5727448p5727607.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Proposal for import guidelines


 De : Peter Wendorff wendo...@uni-paderborn.de

 Yes, it is part of the import process, as it's the main preparation of the 
 import.
  When we import a list of facilities we get from a third party, e.g. the 
 fuel station import last year, most of the time the raw data is not 
 fitting to osm needs very well.
  Most of the time there's some kind of preprocessing, be it manually or 
 automatically - and if it's done by a bot that bot usually has to be 
 developed, too.
  All this is part of the import process IMHO, yes

Ok, in our case this is done manually during the merge.

 All versions?

No. On cadastre.gouv.fr you have the current version

 It was said that there are new versions every few years. Do the old, then 
 outdated versions stay there?
On cadastre.openstreetmap.fr data are regenerated periodically or on demand

  Apart from that while OSM basically has English as the lingua franca, I 
 think it's a bad idea to rely on French only for documentation - inside 
 osm as well as for outside documentation like cadastre.gouv.fr.
I guess this at been written in french only because it was targeting french 
communauty for OSM documentation

Cheers 

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

Re: [OSM-talk] Proposal for import guidelines


Richard Fairhurst wrote:

It doesn't actually make any difference to me personally
- I only_use_  OSM data for the UK, where we don't have imports

Yet ;)
I want to get the border layer stuff working directly from the import rather 
than 'importing' it piecemeal into the base 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-talk] Proposal for import guidelines

 De : Richard Fairhurst rich...@systemed.net


Because it's not just about scripts and bots. The Cadastre situation, which
started all of this off, is often people loading .osm files into JOSM,
running a quick validator check over it, and uploading. In terms of impact
on the map and on the community, there is no significant difference between
this and the same operation using upload.py.

What you mention is normally and exception.
The french wiki page about cadastre building integration explicitely mention 
that data should be checked carrefully and merged with the existing to keep 
database coherency and quality.
The french community has also some tools to detect people doing what you 
mention and often perform a revert of the changeset, contact the contributor to 
explain that there are some quality requirements.
Clean cadastre integration is a process that take quite a long time when done 
correctly and that could not be automated, that's why it has been decided to 
not perform a national automated import like CLC but rather to rely on 
contributors which do that city by city

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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Jason Cunningham

On 26 September 2012 11:02, Richard Fairhurst rich...@systemed.net wrote:

 - I only _use_ OSM data for the UK, where we don't have imports, and I'm
 not
 on DWG so I don't have to deal with the angry mails. I'm simply trying to
 help and getting hostile doesn't really encourage that.)

 Richard


I was typing up a response when your email came through. I was based around
the numerous imports in the UK of Ordnance Survey VectorMapDistrict Data. I
guess I'm using a broad definition of import

In the UK we have available data from Ordnance Survey in Rasta and Vector
format. There is a wiki page on how we should use the data with a
requirement we should add a source tag.
http://wiki.openstreetmap.org/wiki/Ordnance_Survey_Opendata
For me the main use of the vector data is adding rivers, water bodies,
coastlines, and boundaries. For these types the Ordnance Survey data is
commonly the best source, but I'd argue strongly it still needs checking. I
read the initial proposal as meaning that if I added a 3 ponds by tracing
over rasta image availabe in Potlatch or JOSM it would not be considered a
manual drawn action, but if copied the vector data then it would fall
under automated edit because it would be an imports of external data.
It would not be a bulk edit but would still require several actions I'd
consider to be over the top (eg adding bot= and bot_url=)

Subsequent discussion suggests that the addition of this vector data would
not be considered an 'automated edit', but I think it would help to make
this clearer. I prefer the wording used by Tobias Knerr

On 26 September 2012 10:51, Tobias Knerr o...@tobias-knerr.de wrote:


 An 'automated edit' is one where the editing is not carried out by
 manual drawing actions. This includes (but is not limited to):

 - imports of external data without inspection of individual objects
 - any changes performed by a script/bot

 Of course there are special cases where e.g. a powerful editor is used
 to blindly do the exact same thing a script would do, but things like
 these are what the not limited to is for.



I'd suggest changing 'automated edit' with something along the lines of
'blind import', and defining it based around lack of inspection of impact
of individual objects. I'd slightly change one of the lines to
-  imports of external data without inspection of individual objects, or
consideration of impact on existing surrounding objects.

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

Re: [OSM-talk] Proposal for import guidelines

2012-09-26 Per discussione Paul Norman

 From: Richard Fairhurst [mailto:rich...@systemed.net]
 Sent: Wednesday, September 26, 2012 3:02 AM
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] Proposal for import guidelines

 Tordanik wrote:
  If you want to address changes performed by scripts/bots, then why
  don't you just say so explicitly and avoid any potential
  misunderstandings?

 Because it's not just about scripts and bots. 

My brief thoughts on what would fall on the mechanical side vs not

Mechanical:
Using (j)xapi to download all post boxes in a city without operator=* and
adding operator=* to them
Changing all McDonalds to McDonald's
Mass-fixing up import tagging
Anything done with absolutely no user intervention (e.g. xybot)

Not:
Using (j)xapi to download all post boxes in a city that you added without
operator=* because you realized they were all one operator and wanted to go
back to fix your earlier surveyed data.

In practice most mechanical edits fall extremely far on the side of being a
mechanical edit so even if it's a somewhat fuzzy line most will clearly be
on one side or the other.

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

Re: [OSM-talk] Proposal for import guidelines

 De : Lester Caine les...@lsces.co.uk

 That has been a previous request :) The google translation is a little 
 strange.
OK I was not aware about that



 And if we can automate that process it would help you?
The add of source tag is already automatic


 I'm just repeating things that were being quoted earlier, but I would 
like to have a look at the data myself to see if we are talking about 
the same things. Accessing the French data is difficult for a non French 
speaker :(
Ok. So by exemple to see official data goto on www.cadastre.gouv.fr
In Commune field type Saint Galmier
In Departement liste choose 42 - LOIRE
Then click on rechercher button

In Ville commune list choose Saint Galmier 42330  ( I know this is 
painfull )
Click on Rechercher ( bottom right )
Click on Vue d ensemble de la commune.
Normally you should have a pop up window that display cadastre data. You can 
zoom/unzoom on it using left panel to make details like river, building, 
streets appear.
This is for the official data.

The corresponding processed data that you can find on 
http://cadastre.openstreetmap.fr/data/ are those data downloaded in PDF format 
processed by a C++ script that analyse geometrical forms and colours to extract 
buildings, railways, rivers and produced separated OSM files.
You have one directory per french department ( in the case of Saint Galmier 
this is number 42 named LOIRE ) containing all the OSM files of cities 
belonging to this department. In my example case the data corresponding to what 
you have seen on cadastre.gouv.fr are located in these files:
http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-city-limit.osm
http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-rails.osm
http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-water.osm
http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER.tar.bz2

The french wiki cadastre page provide a big warning aout poor quality of water 
data and the fact that we need to perform some verifications and cleanup of all 
these data ( building, railways, river etc ) has the analyse is not perfect.


 I can't access the government data as an overlay? The English 
translation is a little light, but I suspect this only give hard copy 
output? IS the raw data available in a manor that we can access directly in a 
josm or something similar?

You can have cadastre has overlay in JOSM using french cadastre plugin.
If you want to perform the test on Saint Galmier you will have to install the 
plugin in JOSM, restart JOSM. Change the projection to Lambert 9 zones and 
choose Lambert CC zone 5, restart JOSM.

In cadastre preferences ( just behind plugin part of preferences dialog window 
) choose vector Grab Multplier 100m thanks to the radio button.
Then in JOSM Cadastre Menu choose Cadastre grab
In the dialog box type SAINT-GLAMIER in Commune field. In department list 
choose 42 - loire. Click on OK and normally you should slowly have a new 
overlay representing french cadastre data. Notice that their are coming in 
picture format.

I'm not sure about if this is possible to do the same with Merkaartor


 The cadastre.openstreetmap.fr seems to a similar problem? I can select a 
 Department and then in some cases Ville, but nothing seems to happen?
Please refer to explainations at the beginning of my email and let me know if 
you are still facing issues


 There is obviously good data available, and all I'm asking is some help 
in viewing it. In the same manor as data is being made usable elsewhere 
;)
 The UK's OS data is available as 'layers' we can work with, and it 
would be nice to see the French data similarly available.
 We have to 
process the raw OS data into a raw format that is correctly 
geo-referenced, and that raw data is available, so I would anticipate 
that the French data has had similar processing?
 Is that raw data 
available anywhere? Having got the raw layer(s) we NOW need to process 
them into a 'staging' layer which can be used to integrate later updates - all 
of which should be made available as raw layers - but the staging layer would 
be the one that flags what has or has not been merged. 

 So 
I'm not sure if cadastre.openstreetmap.fr is your 'raw data' layer, in 
which case there should be a 'version select' or your staging layer?

The georeferencing is already there for vectorised data of cadastre ( for 
raster cadastre data this is much more complex than the example I provide to 
you and we hae no automatic tools at all to 'integrate' them).
We have currently no historic versionning.
For the other points I`m not sure to understand what you mean so I hope that 
the explaination on how to access to official cadastre data and processed data 
will make things more clear

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

Re: [OSM-talk] Proposal for import guidelines


THEVENON Julien wrote:

Clean cadastre integration is a process that take quite a long time when done
correctly and that could not be automated, that's why it has been decided to not
perform a national automated import like CLC but rather to rely on contributors
which do that city by city


But I'm still not clear if that is done of a properly geo-referenced 
overlay/layer? The initial automatic process would be creating that layer 
although I would accept that keeping historic versions is something that could 
be a cost that nobody will cover?


How is the cadastre.openstreetmap.fr data structured? It sounds as if this IS 
the base import of the cadastre data? So what is missing is a 'staging' layer, 
which identifies what has been imported. I presume that the current view is that 
it's this 'automation' that is not practical yet? But the 'extra' tools being 
provided simply allow large blocks of raw data to be copied over once they have 
been identified as building or what ever?


--
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] Proposal for import guidelines

 De : THEVENON Julien julien_theve...@yahoo.fr

 You can have cadastre has overlay in JOSM using french cadastre plugin.
 If you want to perform the test on Saint Galmier you will have to install 
the plugin in JOSM, restart JOSM. Change the projection to Lambert 9 
zones and choose Lambert CC zone 5, restart JOSM.

 In cadastre preferences ( just behind plugin part of preferences dialog 
window ) choose vector Grab Multplier 100m thanks to the radio button.

Sorry I forgot one step. It is mandatory to first get some OSM data because the 
cadastre plugin rely on current JOSM bbox to perform request on Official french 
cadastre servers so
Download some OSM data in Saint Galmier region ( to have an idea where it is 
located 
http://www.openstreetmap.org/?lat=45.588947lon=4.315972zoom=18layers=M  ) 

 Then in JOSM Cadastre Menu choose Cadastre grab
 In the dialog box type SAINT-GLAMIER in Commune field. In department 
list choose 42 - loire. Click on OK and normally you should slowly 
have a new overlay 
 representing french cadastre data. Notice that their are 
coming in picture format.
 I'm not sure about if this is possible to do the same with Merkaartor

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

Re: [OSM-talk] Proposal for import guidelines


 De : Lester Caine les...@lsces.co.uk

But I'm still not clear if that is done of a properly geo-referenced 
overlay/layer? The initial automatic process would be creating that 
layer although I would accept that keeping historic versions is 
something that could be a cost that nobody will cover?

yes the automatic process create a properly geo-referenced OSM file available 
on cadastre.openstreetmap.fr



How is the cadastre.openstreetmap.fr data structured?
Please refer to my previous email ( 13:07 ) if you have not read it at the time 
you wrote this email. I you need more details about it please quote the part of 
text which is not clear, it will be easier for me to answer ;-)


It sounds as if this IS the 
base import of the cadastre data? So what is missing is a 'staging' 
layer, which identifies what has been imported. I presume that the 
current view is that it's this 'automation' that is not practical yet?
There are such tools for administrative boundaries of cities but not for 
buildings. If I remember well nobody mentionned this kind of need up to now has 
the process is manual normally user should perform the import if data are 
already there.

But the 'extra' tools being provided simply allow large blocks of raw 
data to be copied over once they have been identified as building or 
what ever?No the problem with automated tool is that generated building data 
are sometimes artificially splitted due to the fact that cadastre landuse is 
splitted according to landuse ownership whereas in reality building is not 
splitted. You also have some case where OSM data has been draw on top of Bing 
that was not precisely georeference compared to cadastre so you need to adjust 
data. Sometimes water coming from cadastre doesn't exist in real life so that's 
why we need to perform manual check


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

Re: [OSM-talk] Proposal for import guidelines


THEVENON Julien wrote:

The corresponding processed data that you can find on
http://cadastre.openstreetmap.fr/data/ are those data downloaded in PDF format
processed by a C++ script that analyse geometrical forms and colours to extract
buildings, railways, rivers and produced separated OSM files.


Sees the light :)

SO while we have this type of raster data from as a background in potlatch and 
josm and some elements of it in vector files from OS and other sources. You are 
having to stitch together 'pictures' and then your 'automatic processing' is 
recreating vector data from the 'pictures'?


I understand the problems now ... and it only really works because the pictures 
can be simply vectorised.


SO I would be asking if the 'pictures' can be merged to create a single raster 
overlay for France to use as a background 'source' which could potentially be 
used to trace from, but can be used in conjunction with BING imagery to corss 
check? I would classify that as my base import since it's not externally 
available? We have several versions of the OS data along with the historic maps 
for the UK, and I feel sure that should be achievable in France as well?


The vectorised files are the 'staging layer' and I'm sure that since you are 
providing each building as a shape then in the future it should be possible to 
maintain a 'building_id' that can be used with the sort of merge tools I am 
looking for to handle this type of 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-talk] Proposal for import guidelines


 De : Lester Caine les...@lsces.co.uk

 Sees the light :)
Great !


 SO while we have this type of raster data from as a background in 
potlatch and josm and some elements of it in vector files from OS and 
other sources. You are having to stitch together 'pictures' and then 
your 'automatic processing' is recreating vector data from the 
'pictures'?

I don`t know all details but yes this is something like that


 I understand the problems now ... and it only really works because the 
 pictures can be simply vectorised.

yes has pdf is vectorised but if i rember well what you see as a simple yellow 
rectangle is an overlay of different rectangle inside pdf code explaining 
partly why we have some geomtry problems with contigous buildings.


 SO I would be asking if the 'pictures' can be merged to create a single 
raster overlay for France to use as a background 'source' which could 
potentially be used to trace from, but can be used in conjunction with 
BING imagery to corss check?
The French cadastre licence doesn't allow us to redistribute cadastre data as 
they are so I think it is not legally possible to do that.
The other issue is related to projection : Mercator for Bing and Lambert 9 
zones for French cadastre. In addition to that not all the french cities have 
vectorised cadastre data. There are still a lot of cities which have raster 
data that are just scan of cadaster paper plan without georeferencing ( Feurs 
in 42-Loire by example )


 I would classify that as my base import 
since it's not externally available? We have several versions of the OS 
data along with the historic maps for the UK, and I feel sure that 
should be achievable in France as well?
I don't know if some people are interested in historic maps or such kind of map 
aspects in french community

 The vectorised files are 
the 'staging layer' and I'm sure that since you are providing each 
building as a shape then in the future it should be possible to maintain a 
'building_id' that can be used with the sort of merge tools I am 
looking for to handle this type of data?
We have a tool called bati fusion that try to perfom a diff between OSM files 
to make merging easier by using building shape comparison I think but I don`t 
know if it is massively used. I personnally know the guy who developped it if 
you are interested

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

[OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Christian Quest

2012/9/26 THEVENON Julien julien_theve...@yahoo.fr:

 De : Lester Caine les...@lsces.co.uk

 Sees the light :)
 Great !

 SO while we have this type of raster data from as a background in
 potlatch and josm and some elements of it in vector files from OS and 
 other
 sources. You are having to stitch together 'pictures' and then your
 'automatic processing' is recreating vector data from the 'pictures'?

 I don`t know all details but yes this is something like that


The OSM data is extracted from PDF vector data.
If the first version of the script, the PDF we can download on the
cadastre web site were converted to SVG which are analyzed to extract
data into .osm format. The actual script works more or less the same
way, so we are working on vector data all the time and not processing
raster pictures.
Before we had access to a vector based PDF, we tried to do image
recognition to generate vector data from them, but this was not very
successful and was used only for administrative boundaries.


 I understand the problems now ... and it only really works because the
 pictures can be simply vectorised.

 yes has pdf is vectorised but if i rember well what you see as a simple
 yellow rectangle is an overlay of different rectangle inside pdf code
 explaining partly why we have some geomtry problems with contigous
 buildings.

 SO I would be asking if the 'pictures' can be merged to create a single
 raster overlay for France to use as a background 'source' which could
 potentially be used to trace from, but can be used in conjunction with 
 BING
 imagery to corss check?
 The French cadastre licence doesn't allow us to redistribute cadastre data
 as they are so I think it is not legally possible to do that.
 The other issue is related to projection : Mercator for Bing and Lambert 9
 zones for French cadastre. In addition to that not all the french cities
 have vectorised cadastre data. There are still a lot of cities which have
 raster data that are just scan of cadaster paper plan without georeferencing
 ( Feurs in 42-Loire by example )


To cross check with Bing, it is quite easy... generate the .osm file
using cadastre.openstreetmap.fr site. Load the file in JOSM, add bing
imagery and you can do all the cross check that is needed.
Depending on the town, cadastre can be better than bing or the reverse.
We also do cross check with geodesic points as well as GPS traces in
the case the difference is between bing and cadastre is too high.
Bing is not always available at high resolution everywhere in France,
Bing is not always perfectly aligned (especially in mountain area).


 I would classify that as my base import since it's not externally
 available? We have several versions of the OS data along with the historic
 maps for the UK, and I feel sure that should be achievable in France as
 well?
 I don't know if some people are interested in historic maps or such kind of
 map aspects in french community



I also have a full copy of the June 2009 extracted cadastre data on my
disks (around 5GB bzipped osm data).


 The vectorised files are the 'staging layer' and I'm sure that since
 you are providing each building as a shape then in the future it should be
 possible to maintain a 'building_id' that can be used with the sort of 
 merge
 tools I am looking for to handle this type of data?
 We have a tool called bati fusion that try to perfom a diff between OSM
 files to make merging easier by using building shape comparison I think but
 I don`t know if it is massively used. I personnally know the guy who
 developped it if you are interested


Some other tools are under development to clean some artifacts (small
overlaps between buildings).

Osmose (the quality assurance tool developed by the french community)
also displays overlapping buildings (small and large ones) as well as
highways crossing buildings. This helps to detect quick and dirty
cadastre imports by serial importers as we sometime call them ;)

One more thing about the lack of translation of the cadastre wiki
page: it is non intentional, but it acts as an indirect way of
limiting who is doing such imports.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Olivier Croquette

On Sep 26, 2012, at 6:25 PM, Christian Quest wrote:
 The OSM data is extracted from PDF vector data.

To be exhaustive, I have to mention that this is true only for cities that have 
a vector cadaster. 
Some cities (10% as an order of magnitude) have only a raster cadaster, in 
which case the mapper has to draw all the nodes and points manually.

That has been my case until now, and I wonder if this is considered as an 
import, as meant in the guideline.

If yes, then even drawing over bing or other imagery material would be an 
import too. I guess it's not wanted.

If no, it doesn't make any sense to me that a vector based process for the 
cadaster is an import, and a raster based is not. Everything is the same : kind 
of data, license, provider…

There seems to be a contradiction there.


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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Richard Weait

On Wed, Sep 26, 2012 at 12:59 PM, Olivier Croquette m...@ocroquette.de wrote:

 If no, it doesn't make any sense to me that a vector based process for the 
 cadaster is an import, and a raster based is not. Everything is the same : 
 kind of data, license, provider…

 There seems to be a contradiction there.

Yes, this is something of a contradiction or edge case.  May I offer,
from my perspective, an important difference between tracing over
raster, and copy / pasting vectors?  You say:

Some cities (10% as an order of magnitude) have only a raster
cadaster, in which case the mapper has to draw all the nodes and
points manually.

I think that drawing all of the nodes and points manually is an
important difference, from a quality point of view.  Each node or way
that you draw by hand, is carefully considered and placed, one at a
time.  It isn't perfect; nothing is.  I suggest that this leads to a
kind of automatic quality control, as the nodes and ways are placed.

The goal of the vector import procedure is similar, use data from this
area, reconcile it carefully, include it in OpenStreetMap.  The
intention is very good.  But in execution, it is easier to miss a node
or way (or more than one) that needs to be refined before upload.
Again, it isn't perfect; nothing is.  When you are considering
hundreds or thousands of nodes and ways at once, it becomes time
consuming to check them all.

I hope that you'll find the above to be easy to agree with.

My conclusion, is this.  The quality of the hand drawn nodes and ways
will be better because when we draw the nodes and ways by hand they
get more individual attention and care than when we start with a group
of nodes and ways from another file.

So that's why I think that it is different to trace by hand, vs.
vector import.

But what about the rules and edge cases?

I consider what you describe as the raster process to be an import
when the quantity of data is large.  The raster process relies on an
external data source for a large quantity of information.  If that
source is used without considering additional data sources, I think
that the classification as import is very clear.

On the other hand, I think that if the quantity of data is small, if
multiple sources are considered with appropriate weight, and if local
knowledge or an in-person survey is included as well?  Then the
description might be closer to really good mapping.

You ask what is the difference between the raster process and tracing
from aerial imagery alone.  Good question.  We haven't to this point
considered aerial tracing to be an import, but perhaps we should.
Perhaps the reason that tracing aerial imagery is not-an-import is
because it is transformative in a more obvious way?  Tracing aerial
imagery transforms from a (rectified and positioned) picture of the
real world, to a vectorized and tagged abstraction.  Tracing the
raster procedure, if I understand it correctly, transforms from a
raster version of one vectorized and tagged abstraction to second
vectorized and tagged abstraction.

I'd like to repeat here, something that I've said elsewhere.  I think
that the stated goal of the cadastre process, as I understand it, is
admirable.  The idea that data from an external source can not be
contributed to OSM until it has been merged with full consideration of
existing data and (all) other available sources, seems exactly the
right approach.  I hope that this requirement is adopted more widely.

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

Re: [OSM-talk] Any OSM social activities in Europe in the next 2 weeks?

2012-09-26 Per discussione Stefan Keller

Hi Tom

You're welcome at the meeting of users around Zurich! [1]

Yours, Stefan (alias Geonick)

[1] 
http://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#35._OSM-Stammtisch_11._Oktober_2012


2012/9/21 Toby Murray toby.mur...@gmail.com:
 I'm about to leave for a 2 week trip to Europe and wondered if there
 were any local OSM gatherings I could drop in on. Our time isn't
 precisely planned out but here are the highlights. Obviously the
 arrival/departure dates are fixed. The other ones are subject to
 change.

 Budapest: Arriving here on the 23rd and staying for a few days.
 Innsbruck: Will probably be here over the weekend of the 29th/30th
 plus a few days
 Prague: We leave from here on October 6th, will probably arrive a day
 or two earlier.
 London: Spending the evening of the 6th before continuing home

 We will hit Vienna and probably Salzburg along the way but I'm not
 sure how long we will be there.

 Feel free to contact me off list with details. Or on the list if you
 want more exposure for your event!

 Toby

 ___
 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] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Olivier Croquette

On Sep 26, 2012, at 7:44 PM, Richard Weait wrote:
I think that drawing all of the nodes and points manually is an
important difference, from a quality point of view. Each node or way
that you draw by hand, is carefully considered and placed, one at a
time. It isn't perfect; nothing is. I suggest that this leads to a
kind of automatic quality control, as the nodes and ways are placed.

Hi Richard,

I agree that it's an important difference, but you can see it also the other
way around : since the the raster based process is manual, it's more error
prone. For instance, it's easy to forget a building, a street, misinterpret the
image, forget to set a tag (name, source…), introduce inaccuracies of a few
meter, not to mention that some raster maps are not geo-referenced (or badly).
I have been there :-)

So the 2 processes have different sources of errors, and as you say, only a
careful and manual review can provide the quality we all except. This point is
clearly made on the french pages on the Wiki.

My conclusion, is this. The quality of the hand drawn nodes and ways
will be better because when we draw the nodes and ways by hand they
get more individual attention and care than when we start with a group
of nodes and ways from another file.

I don't agree there. The 2 processes have different errors, but it's hard to
say that one is globally better than the other (in terms of quality).

I consider what you describe as the raster process to be an import
when the quantity of data is large. The raster process relies on an
external data source for a large quantity of information. If that
source is used without considering additional data sources, I think
that the classification as import is very clear.

Yes, I agree.
But it doesn't pertain to the normal cadaster import process, because no one is
supposed to import from the cadaster only.
The wiki is really clear about that (french only, sorry):
https://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Import_dans_OSM#Qualit.C3.A9_des_donn.C3.A9es
And what I have seen this is the way mappers work too.

On the other hand, I think that if the quantity of data is small, if
multiple sources are considered with appropriate weight, and if local
knowledge or an in-person survey is included as well? Then the
description might be closer to really good mapping.

You are describing 2 ends of a scale very well. Currently we are in-between,
but nearer to the second one, because we have multiple sources (uploaded GPS
tracks, Bing, existing OSM data, and usually the mapper's own GPS tracks and
knowledge).
The point is that with the time, we tend to go even further in the direction of
the second one, because more and more data is available in the OSM database and
we tend to get more sources, not less.

NB: just FYI and completeness: there are actually 25% of the maps vectorized
according to this page:
https://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Frederik Ramm


Hi,

On 26.09.2012 19:44, Richard Weait wrote:

I think that drawing all of the nodes and points manually is an
important difference, from a quality point of view.  Each node or way
that you draw by hand, is carefully considered and placed, one at a
time.  It isn't perfect; nothing is.  I suggest that this leads to a
kind of automatic quality control, as the nodes and ways are placed.


To give an example, look at this imported building

http://www.remote.org/frederik/tmp/funnybuilding.png

Note how the main building consists of 8 separate parts plus a strange 
diagonal line, and note how the smallest parts are just about 2 metres wide.


Compare to the aerial image:

http://binged.it/UuYSio

A very careful tracer of the aerial image might indeed have created more 
than just one shape for this, but there is hardly anything there on the 
imagery that suggests *such* a complex edifice.


This is not an example that you only find after a long search; it is a 
typical cadastre import building.


Bye
Frederik

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre


Frederik Ramm wrote:

I think that drawing all of the nodes and points manually is an
important difference, from a quality point of view.  Each node or way
that you draw by hand, is carefully considered and placed, one at a
time.  It isn't perfect; nothing is.  I suggest that this leads to a
kind of automatic quality control, as the nodes and ways are placed.


To give an example, look at this imported building

http://www.remote.org/frederik/tmp/funnybuilding.png

Note how the main building consists of 8 separate parts plus a strange diagonal
line, and note how the smallest parts are just about 2 metres wide.

Compare to the aerial image:

http://binged.it/UuYSio

A very careful tracer of the aerial image might indeed have created more than
just one shape for this, but there is hardly anything there on the imagery that
suggests *such* a complex edifice.

This is not an example that you only find after a long search; it is a typical
cadastre import building.


Now that I understand what is going on, I can see where some off the 'extra' 
lines come from, and the diagonal is probably due to a boundary detail from 
changing sheets. However while the source has two different shades of block for 
buildings, I don't think they can be used at this stage to provide useful extra 
lines. The process that is extracting the vectors should further process the 
data so that each block IS a single continuous outline? Later comparison will 
then be easier as long as say 90% of the area matches the previous instance?


Of cause simply importing thousands of these objects without a visual check of 
every one of them is something completely different to hand tracing every one of 
them. I'd prefer that there was some cross check that objects have been 
verified. And in my book, having to manually select objects to import would 
provide that check? So I'd block any area select function, so that hundreds of 
objects can't simply be picked and pushed?


--
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] All you've ever wanted to know about the french cadastre

 De : Frederik Ramm frede...@remote.org

 To give an example, look at this imported building
 http://www.remote.org/frederik/tmp/funnybuilding.png
 Note how the main building consists of 8 separate parts plus a strange 
diagonal line, and note how the smallest parts are just about 2 metres 
wide.
 Compare to the aerial image:
 http://binged.it/UuYSio
 A very careful tracer of the aerial image might indeed have created more 
than just one shape for this, but there is hardly anything there on the 
imagery that suggests *such* a complex edifice.
 This is not an example that you only find after a long search; it is a 
 typical cadastre import building.

It could also have been done by a guy manually drawing on top of cadastre 
without cross check with aerial imagery...(Ok it will make a smaller volume if 
manually done)
In any way using a separated account or add some tags will not prevent this 
case.
Do you think it will make their detection easier ?

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Olivier Croquette

On Sep 26, 2012, at 8:13 PM, Frederik Ramm wrote:
 On 26.09.2012 19:44, Richard Weait wrote:
 I think that drawing all of the nodes and points manually is an
 important difference, from a quality point of view.  Each node or way
 that you draw by hand, is carefully considered and placed, one at a
 time.  It isn't perfect; nothing is.  I suggest that this leads to a
 kind of automatic quality control, as the nodes and ways are placed.
 
 To give an example, look at this imported building
 
 http://www.remote.org/frederik/tmp/funnybuilding.png

http://www.openstreetmap.org/browse/way/182524106

 A very careful tracer of the aerial image might indeed have created more than 
 just one shape for this, but there is hardly anything there on the imagery 
 that suggests *such* a complex edifice.

It's clearly a blind import, that has already been detected and mentioned on 
the talk-fr list. It's bad.

Side note: we have here another big difference between raster and vector 
imports. Vector can easily be imported quick and dirty, raster can't be quick, 
but it can be dirty (typical example: bad geo referencing).

But it doesn't say anything about the quality of vector vs. raster imports 
*when done correctly*.

And if you assume that the contributors generally work incorrectly, then no 
guideline will help, only hard quality gates and review processes will. But 
that's not the OSM spirit.

 This is not an example that you only find after a long search; it is a 
 typical cadastre import building.

Until you can back up your claim with solid numbers, your claim, more 
specifically the wordtypical, is just FUD.
Furthermore it can hurt many hard working french contributors, who for a single 
city spent dozens of hours integrating the cadaster into OSM. 


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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

 De : Lester Caine les...@lsces.co.uk

 Now that I understand what is going on, I can see where some off the 
'extra' lines come from, and the diagonal is probably due to a boundary 
detail from changing sheets.

This is more often due to split of landuse ownership. There is no differences 
between this lines and the one separating adajacent buildings


 However while the source has two different 
shades of block for buildings.
I don't think they can be used at this 
stage to provide useful extra lines.
The process that is extracting the 
vectors should further process the data so that each block IS a single 
continuous outline?
Later comparison will then be easier as long as say 
90% of the area matches the previous instance?


No this is not sufficiant I think because some times you have adjacent 
buildings that are not a single building. You also have cases when line 
separate building parts which have different number of levels or which are 
light buildings ( without wall by example )


 Of cause simply 
importing thousands of these objects without a visual check of every one of 
them is something completely different to hand tracing every one of 
them.
 I'd prefer that there was some cross check that objects have been 
verified.
 And in my book, having to manually select objects to import 
would provide that check?
 So I'd block any area select function, so that hundreds of objects can't 
 simply be picked and pushed?

Please also notice that this is sometime not easy to distinguish on aerial 
imagery if the split line really exist or not.

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre


THEVENON Julien wrote:

* De :* Lester Caine les...@lsces.co.uk

* *Now that I understand what is going on, I can see where some off the
'extra' lines come from, and the diagonal is probably due to a boundary detail
from changing sheets.
This is more often due to split of landuse ownership. There is no differences
between this lines and the one separating adajacent buildings



* *However while the source has two different shades of block for buildings.
**I don't think they can be used at this stage to provide useful extra 
lines.
**The process that is extracting the vectors should further process the data
so that each block IS a single continuous outline?
**Later comparison will then be easier as long as say 90% of the area
matches the previous instance?

No this is not sufficiant I think because some times you have adjacent buildings
that are not a single building. You also have cases when line separate building
parts which have different number of levels or which are light buildings (
without wall by example )


Looking at the source material, there is nothing which can be used to separate 
the blocks displayed into separate buildings, and since we have no means of 
identifying different levels of building, adding 'detail' for that seems 
pointless? All that can be 'accurately' extracted from the source material is 
that there is a 'block' of buildings? So if you are not actually surveying the 
buildings and identifying individual buildings, then normal practice is to draw 
a single box. Frederik's example is the sort of thing that SHOULD have been 
tidied up before importing!



* *Of cause simply importing thousands of these objects without a visual
check of every one of them is something completely different to hand tracing
every one of them.
* *I'd prefer that there was some cross check that objects have been 
verified.
* *And in my book, having to manually select objects to import would provide
that check?
* *So I'd block any area select function, so that hundreds of objects can't
simply be picked and pushed?

Please also notice that this is sometime not easy to distinguish on aerial
imagery if the split line really exist or not.


Hand tracing hundreds of individual elements and not committing them often does 
not make sense. What I am talking about here is selecting hundreds of vectors 
from a file without checking them, and having to select each individually would 
help the checking process. Then perhaps the sort of questionable mapping 
demonstrated would not happen?


Personally I would prefer to see 
http://www.remote.org/frederik/tmp/funnybuilding.png as a single closed outline 
box. If the vectors are not providing closed objects then there is something 
wrong with the data anyway and in my book it should not be allowed to be 
imported? With a decent editor, one should be able to select the outline of a 
block and simply import that ...


--
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] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Pieren

To Richard,
I've seen examples where manually tracing over raster images has been
done roughly and quickly. It's not a guarantee of quality. You are
saying that it's time consuming to check data from external source and
probably more accurate to trace manually over raster images. But it is
also time consuming to draw manually building polygons, much more time
consuming. And if you do the job carefully the final result in OSM is
normally identical in both cases. I don't know where you leave Richard
but if, let say, one of the next SOTM is happening in Berlin, you will
probably have the choice between the plane, the car, the bike or your
feet. Will you prefer to walk and arrive 10 years later or fly during
2 hours ? Instead of spending hours and hours in copying polygons, we
have better time to cross-check the data with other sources, improve
tagging and fix other mistakes. For the same amount of time, the final
result in OSM will be much better if you take the vector data.

To Frederik,
In your example, I agree with you that the diagonal line is a glitch,
most probably coming from a parcel line just underneath. Our guideline
asks to fix them before the upload but it's not always done. When I
see one, I just fix it. This is the way how OSM works. Your second
point is about indoor details. Myself, I'm also in favour of more
simplicity e.g. one polygon per address. But who is able to decide the
level of details on the map ? I started with blank areas five years
ago and I also said forget the buildings. Now we have people
modeling houses in 3d, mapping indoor and tagging draught beers.

Pieren

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Vincent de Chateau-Thierry


Hi,

Le 26/09/2012 19:44, Richard Weait a écrit :


I think that drawing all of the nodes and points manually is an
important difference, from a quality point of view.  Each node or way
that you draw by hand, is carefully considered and placed, one at a
time.  It isn't perfect; nothing is.  I suggest that this leads to a
kind of automatic quality control, as the nodes and ways are placed.



You may draw carefully and at the wrong place at the same time. Drawing 
manually is not a guaranty of right geometry. I (and many others in 
France) used to draw buildings manually before june 2010 and the start 
of the buildings-as-osm-files availability. This is time consuming and a 
pain for both your eyes and wrist and fingers (and mouse too :-) ). So I 
can't believe that after 30 minutes of such drawing your accuracy is 
still at the top.
On the other side as explained by Christian, raw .osm files for 
buildings are directly taken frow a vector source. When we display the 
WMS version of the vector cadastre, we display exactly the same source. 
As a consequence, it is quite easy to cross check .osm files once 
displayed as a layer on the top of the WMS layer. As a matter of facts, 
coordinates stored in the .osm file are the same as the ones used to 
draw building polygons of the WMS layer : the source is the same, only 
the way of displaying it differs (vector layer vs WMS layer). Drawing 
manually can not produce such accurate geometry.



The goal of the vector import procedure is similar, use data from this
area, reconcile it carefully, include it in OpenStreetMap.  The
intention is very good.  But in execution, it is easier to miss a node
or way (or more than one) that needs to be refined before upload.
Again, it isn't perfect; nothing is.  When you are considering
hundreds or thousands of nodes and ways at once, it becomes time
consuming to check them all.



Right. Done carefully, once again, integration of cadastre's buildings 
*is* time consuming.



I hope that you'll find the above to be easy to agree with.

My conclusion, is this.  The quality of the hand drawn nodes and ways
will be better because when we draw the nodes and ways by hand they
get more individual attention and care than when we start with a group
of nodes and ways from another file.

So that's why I think that it is different to trace by hand, vs.
vector import.

But what about the rules and edge cases?

I consider what you describe as the raster process to be an import
when the quantity of data is large.  The raster process relies on an
external data source for a large quantity of information.  If that
source is used without considering additional data sources, I think
that the classification as import is very clear.

On the other hand, I think that if the quantity of data is small, if
multiple sources are considered with appropriate weight, and if local
knowledge or an in-person survey is included as well?  Then the
description might be closer to really good mapping.

You ask what is the difference between the raster process and tracing
from aerial imagery alone.  Good question.  We haven't to this point
considered aerial tracing to be an import, but perhaps we should.
Perhaps the reason that tracing aerial imagery is not-an-import is
because it is transformative in a more obvious way?  Tracing aerial
imagery transforms from a (rectified and positioned) picture of the
real world, to a vectorized and tagged abstraction.  Tracing the
raster procedure, if I understand it correctly, transforms from a
raster version of one vectorized and tagged abstraction to second
vectorized and tagged abstraction.



Tracing the raster procedure transforms from a raster version of a 
*paper map*, not taken from a vectorized source.


As mentioned earlier in this thread, French cadastre is still made of 
rasterized old paper maps in 25% of our municipalities. Sometimes such 
maps are geo-referenced by the Cadastre authorithy and we take it into 
account. But in many cases each map is not georeferenced at all. The 
contributor has to deal with it manually in JOSM. And you can have up to 
dozens of maps for a single municipalities : a kind of puzzle.

See below [1] for a sample.
Before tracing from such maps you have to process a transformation that 
is not a regular orthorectification (we do not use a DEM) but we more or 
less try to translate + rotate + scale maps so that they fit with other 
sources : bing imagery, osm data, survey points.


I can definitly not consider such workflow as part of an import. Even if 
I can draw 1000 buildings in a single day on the top of cadastre maps.


As you can notice French cadastre is all but a single source in a single 
format with a nation-wide repository. It is a compilation of formats 
(vector  raster), projections (Lambert Conformal in best cases, no 
projection at all in worst cases), procedures (from raw osm files to 
manualy geo-referenced maps).


vincent

[1] : follow theses steps to display a sample

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Christian Quest

In France, cadastre is the most official source about buildings and
land ownership. When you buy/sell a building all the documents refers
to the cadastre.

It provides sometime too many details compared to what could be seen
by survey. Does this mean it is wrong to have too many details ?

Considering merging these detailed outlines automatically into a
single block is not a option because in many cases in cities this
would lead to a single building outline for a whole street block
loosing way too many details.

Bing aerial pictures are most of the times a good source, but not the
reference. Cadastre data may be more up to date (we have new buildings
not visible on Bing), and sometimes it is the reverse when Bing
aerials are from 2011 or even 2012. That's usual with different source
of information, that's why I indicate bing year in the source tags
when I trace over bing.

I manually traced building in a village in Burgundy because the
cadastre was only raster there at that time, then the vector version
became available. I updated the whole area and found that vector was
much more accurate and higher quality than what I did manually. I
think it is the case most of the time because of the georeferencing
that is done manually and because inaccuracies/lack of details in the
manual tracing. One important thing when tracing cadastre by hand is
that you cannot cross check with Bing at the same time because of
different projections (Lambert vs Mercator). So cross check with Bing
must be done afterwards, exactly like when using vector data.
That's why I consider manual tracing as a waste of time, and not high
quality compared to using extracted building from vector data.

Buildings, even with some artifacts like the one showed by Frederik
example, are helping a lot adding POI at their right position. This is
also something I learnt after adding POI in my own city and then
adding buildings from vector extraction when it became available (this
summer). I add to relocate a lot of POI added by myself and other
contributors, and adding new ones is now much easier.

--
Christian

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

[OSM-talk] Réf.: Re: All you've ever wanted to know about the french cadastre






--
Le mer. 26 sept. 2012 21:48 HAEC, Lester Caine a écrit

Looking at the source material, there is nothing which can be used to separate 
the blocks displayed into separate buildings, and since we have no means of 
identifying different levels of building, adding 'detail' for that seems 
pointless? All that can be 'accurately' extracted from the source material is 
that there is a 'block' of buildings? So if you are not actually surveying the 
buildings and identifying individual buildings, then normal practice is to 
draw a single box. Frederik's example is the sort of thing that SHOULD have 
been tidied up before importing.

please don't forget that you are talking about something that is considered as 
a bad import by the french community and that you are currently focusing on one 
building whereas there thousand correct buildings imported by hardworking 
mappers.
you also seem to consider that there is only cadastre in the life. majority of 
contributos also use there local knowledge. I personnaly know where buildings 
are separated in my city and where there is a single one or at least I can go 
to check directly. I don't know by heart the number of level for each building 
and I have other priority at the moment(I prefer to concentrate on missing 
roads by example) but I think it would have no sense to remove correct details 
provided by cadastre just because I cannot had the details at the moment. a 
mappers keen of micro mapping or osm2xp will just have to add the missing 
details if he want.

Please don't consider that what you think useless is useless for everyone. few 
weeks ago we had a request from a guy that would like to use osm data to 
compute solar energy potential production. For the moment this not possible but 
it can be done by adding some tags to separated adjacent building to indicate 
orientation of roof. by keeping only the external shape of building block it 
will not be possible


Hand tracing hundreds of individual elements and not committing them often 
does not make sense. What I am talking about here is selecting hundreds of 
vectors from a file without checking them, and having to select each 
individually would help the checking process. Then perhaps the sort of 
questionable mapping demonstrated would not happen?
Personally I would prefer to see 
http://www.remote.org/frederik/tmp/funnybuilding.png as a single closed 
outline box. If the vectors are not providing closed objects then there is 
something wrong with the data anyway and in my book it should not be allowed 
to be imported? With a decent editor, one should be able to select the outline 
of a block and simply import that ...

where did you see open building objects ?

cheers
Julien

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Petr Morávek [Xificurk]

Richard Weait wrote:
 On Wed, Sep 26, 2012 at 12:59 PM, Olivier Croquette m...@ocroquette.de 
 wrote:
 
 If no, it doesn't make any sense to me that a vector based process for the 
 cadaster is an import, and a raster based is not. Everything is the same : 
 kind of data, license, provider…

 There seems to be a contradiction there.
 
 Yes, this is something of a contradiction or edge case.  May I offer,
 from my perspective, an important difference between tracing over
 raster, and copy / pasting vectors?  You say:
 
 Some cities (10% as an order of magnitude) have only a raster
 cadaster, in which case the mapper has to draw all the nodes and
 points manually.
 
 I think that drawing all of the nodes and points manually is an
 important difference, from a quality point of view.  Each node or way
 that you draw by hand, is carefully considered and placed, one at a
 time.  It isn't perfect; nothing is.  I suggest that this leads to a
 kind of automatic quality control, as the nodes and ways are placed.
 
 The goal of the vector import procedure is similar, use data from this
 area, reconcile it carefully, include it in OpenStreetMap.  The
 intention is very good.  But in execution, it is easier to miss a node
 or way (or more than one) that needs to be refined before upload.
 Again, it isn't perfect; nothing is.  When you are considering
 hundreds or thousands of nodes and ways at once, it becomes time
 consuming to check them all.
 
 I hope that you'll find the above to be easy to agree with.
 
 My conclusion, is this.  The quality of the hand drawn nodes and ways
 will be better because when we draw the nodes and ways by hand they
 get more individual attention and care than when we start with a group
 of nodes and ways from another file.
 
 So that's why I think that it is different to trace by hand, vs.
 vector import.

I've read those paragraphs several times, but still don't really get
your logic. Are you claiming that from two options
1) check+manually trace the data,
2) check vector data,
the first one leads to a higher quality output?


My perspective is that man-hours are expensive commodity and we should
treat it that way and put it to a good use. And I don't think that
hand-tracing vector data falls into that category.

Best regards,
Petr Morávek aka Xificurk

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre


Christian Quest wrote:

So cross check with Bing
must be done afterwards, exactly like when using vector data.
That's why I consider manual tracing as a waste of time, and not high
quality compared to using extracted building from vector data.


Christian
I've now seen your source data, and that is showing buildings as 'blocks'. In 
the PDF file are those blocks drawn individually when there are are more than 
one building side by side? Or are the vectors simply the outline of the whole block?


I'm sure that over time improved quality data will evolve, but the current 
vector data that many of us have access to is not ideal. Personally the problems 
I am finding is where we have semi detached houses drawn as a single block, and 
splitting that into two blocks is a pain on potlatch ... I've not tried on JOSM 
yet. But a tool on my 'wish list' is one I can use to select vector lines from a 
'staging layer' and combining them to a closed way to which I can then add extra 
tags. This I think is the best way to use this 'poor quality' vector data and 
convert it to better quality data? I can also see a 'split' tool, where the 
imported vectors are for a 'semi' or 'terrace' and you want to split each out to 
separate buildings.


http://www.openstreetmap.org/?lat=52.048913lon=-1.85734zoom=18 will show my 
own experience with all of this. What is not visible is the Opendata streetview 
layer, and just how bad the vector data is with respect to the current status. 
'New' buildings are actually not too bad, but none of the extensions on the 
houses on Smallbrook Road are present on the OS layer, which seems to be stuck 
with 40+ year old data. Some how I expect the same sort of discrepancies in most 
data, and so I would not use the OS data in the same manor you are using the 
French data, although with my historic hat on it WOULD be nice to retain the 
history of the additions of these extensions over time. Importing buildings from 
the Opendata streetview layer would fill up the UK map, but we do not know what 
date the buildings relate to and then updating and we still need to split and 
add address 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-talk] Réf.: Re: All you've ever wanted to know about the french cadastre


THEVENON Julien wrote:

Personally I would prefer to 
seehttp://www.remote.org/frederik/tmp/funnybuilding.png  as a single closed 
outline box. If the vectors are not providing closed objects then there is 
something wrong with the data anyway and in my book it should not be allowed to 
be imported? With a decent editor, one should be able to select the outline of 
a block and simply import that ...

where did you see open building objects ?

I was referring to the extra line segments within the box ...

--
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] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Vincent Pottier


Le 26/09/2012 23:00, Christian Quest a écrit :

In France, cadastre is the most official source about buildings and
land ownership. When you buy/sell a building all the documents refers
to the cadastre.

It provides sometime too many details compared to what could be seen
by survey. Does this mean it is wrong to have too many details ?

For example the building given by Frederik (OK, they are some mistakes 
in it)


http://osm.org/go/xVR3y4BJp--

Some polygons have the tag wall=no, that explain the number of polygons.
Shour we detele this information by merging them ?
--
FrViPofm

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Christian Quest

2012/9/26 Lester Caine les...@lsces.co.uk:
 Christian Quest wrote:

 So cross check with Bing
 must be done afterwards, exactly like when using vector data.
 That's why I consider manual tracing as a waste of time, and not high
 quality compared to using extracted building from vector data.


 Christian
 I've now seen your source data, and that is showing buildings as 'blocks'.
 In the PDF file are those blocks drawn individually when there are are more
 than one building side by side? Or are the vectors simply the outline of the
 whole block?


There is no single answer as there is many different cases.

Most of the time, a building is defined by a single polygon.
Sometimes, in may be split into multiple polygons if the land/building
ownership has evolved during the past or if the building is composed
of different parts. Auto-merging is almost impossible and manual
merging is not obvious.
Sometimes, one building polygon is covering different building parts.
Auto-split is also almost impossible and manual split also not
obvious.

 I'm sure that over time improved quality data will evolve, but the current
 vector data that many of us have access to is not ideal.

I doubt we will ever have access to a better source nation wide.
Some cities that stepped into opendata do provide building vector data
but they are a minority and most of the time it is the same data
because cities are updating the cadastre data locally then send it to
the nationwide administration.

Cities and town had/have the responsibility to create the vector
version. Some parts of France are fully vectorized, some are still
very late (25% of our 36000+ communes still).


 Personally the
 problems I am finding is where we have semi detached houses drawn as a
 single block, and splitting that into two blocks is a pain on potlatch ...

Well... working with complex objects may be a pain in Potlatch but
this is not typical of building coming from the cadastre.
Some building with wholes in them are even using multipolygon relations.


 I've not tried on JOSM yet. But a tool on my 'wish list' is one I can use to
 select vector lines from a 'staging layer' and combining them to a closed
 way to which I can then add extra tags. This I think is the best way to use
 this 'poor quality' vector data and convert it to better quality data? I can
 also see a 'split' tool, where the imported vectors are for a 'semi' or
 'terrace' and you want to split each out to separate buildings.


I agree that a tool in JOSM (or whatever is your editor of choice) to
split a polygon into 2 smaller polygons could be really helpful, not
only for buildings.


 http://www.openstreetmap.org/?lat=52.048913lon=-1.85734zoom=18 will show
 my own experience with all of this. What is not visible is the Opendata
 streetview layer, and just how bad the vector data is with respect to the
 current status. 'New' buildings are actually not too bad, but none of the
 extensions on the houses on Smallbrook Road are present on the OS layer,
 which seems to be stuck with 40+ year old data. Some how I expect the same
 sort of discrepancies in most data, and so I would not use the OS data in
 the same manor you are using the French data, although with my historic hat
 on it WOULD be nice to retain the history of the additions of these
 extensions over time. Importing buildings from the Opendata streetview layer
 would fill up the UK map, but we do not know what date the buildings relate
 to and then updating and we still need to split and add address data ...


The cadastre is not perfect, but it is not 40+ years old data, it is
closer to 1 or 2 years old in most cases.
The updates are available more or less once a year on a town by town basis.
Cadastre is used to collect taxes and our administration is quite
efficient in that area ;)
In the source tag, dgi means Direction Générale des Impôts (Impôts = taxes).

What's missing from time to time in the cadastre data are state/public
buildings as they don't pay taxes !


One additional thing we have been able to extract from vector cadastre
data is a rough length of highways/path/tracks in each town. This
allows to have a rough idea of the existing/missing ratio as displayed
by this layer: 
http://layers.openstreetmap.fr/?zoom=7lat=47.45473lon=2.19472layers=B00FT

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Vincent Pottier


Le 27/09/2012 00:35, Christian Quest a écrit :

I agree that a tool in JOSM (or whatever is your editor of choice) to
split a polygon into 2 smaller polygons could be really helpful, not
only for buildings.

In JOSM ?

I add 2 nodes (with the middle cross in the segments)
I select them and the polygon
I press alt x
done.

Thanks JOSM.
--
FrViPofm

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012/9/26 Lester Caine les...@lsces.co.uk:
 Personally I would prefer to see
 http://www.remote.org/frederik/tmp/funnybuilding.png as a single closed
 outline box.


I think that 6-7 buildings (looking at the bing aerial
http://it.bing.com/maps/?v=2cp=44.277739~0.502686lvl=20dir=0sty=hwhere1=44,277748%200,502839form=LMLTCC
 , maybe there is more but on a first remote approximation I could see
6 or 7) would be much better than a single closed outline box,
especially, if the tag is something like building=yes which is used
for one building, not groups of them.

There is a really huge difference between 1 big building and 7
adjacent small ones. The problem is, that the cadastre version doesn't
seem to make sense when compared to the aerial imagery. It is better
to have detailed outlines, but only if this detail is depicting
reality.

cheers,
Martin

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Paul Norman

 From: Olivier Croquette [mailto:m...@ocroquette.de]
 Sent: Wednesday, September 26, 2012 11:59 AM
 Subject: Re: [OSM-talk] All you've ever wanted to know about the french
 cadastre

  This is not an example that you only find after a long search; it is a
 typical cadastre import building.

 Until you can back up your claim with solid numbers, your claim, more
 specifically the wordtypical, is just FUD.
 Furthermore it can hurt many hard working french contributors, who for a
 single city spent dozens of hours integrating the cadaster into OSM.

Time for some numbers then...

Detailed data is available upon request.

I decided that to rewind my scripts one week and let them run until I had at
least 15 import changesets by at least 10 different users was the simplest
way to get a representative sample of recent cadastre imports. A set of 16
changesets was generated. A side effect of running the scripts was
generating a list of all changesets that overlapped with the time period. As
there were approximately 11k changesets I used python's random library to
select 1000 random changesets as a representative sample of data the same
age.

By setting these criteria beforehand I avoided any bias that may be present
in existing import changeset lists such as a list from a list of blocks.

Due to technical reasons this analysis is based on the data as it is now,
not as it was immediately after import. This may result in bad imports (e.g.
duplicate uploads) not being considered if they were reverted in the past
week.

The total time reviewed was approximately from Wed, 19 Sep 2012 20:00 to
Thu, 20 Sep 2012 17:30, or approximately 1 day. If there is day to day
variation in import quality this analysis will not show it.

Although not the point of this analysis, one potential measure of
integration with other data is the version of the objects. I present this
for general interest, not for the question of what a typical cadastre
building is.

Previous research into object versions has found they tend to obey a power
law (after normalization with number of v1 objects) where count = version ^
m.

A best fit line on a log-log plot finds m=-4.681 (R^2=0.946) for the
imported ways and m=-2.243 (R^2=0.991). There is a marked difference between
the versions of ways in the two sets of changesets. This is not unexpected
as the cadastre imports are primarily new buildings and involve minimal
changes to existing data. [1] An analysis of buildings in the random
changesets finds m=-3.520 (R^2=0.971) but a similar import building-only
analysis does not find enough data to draw conclusions from.

Changes to ways in cadastre imports cannot be said be similar to changes to
ways in random changesets w.r.t. versions of objects.

Now, the analysis of geometry.

One measure of how broken down into parts buildings are is to take the
buildings, turn them into polygons, combine them into one multipolygon with
ST_Union and then count the number of parts with ST_Dump and compare it with
the original number of buildings. This does not consider buildings made from
multipolygons (e.g. those with an inner hole). I get the following data

Changeset  Joined  Original
13175035 3661  6341
13175649  503  1240
13176058  521   951
13176212  219   341
13176769  922  1510
13177032 1515  2782
13177569 2216  4291
13180264  536   830
13180628 1449  2230
131816982 2
13183198  506   883
13184921  286   462
13185567  255   438
13185645 1135  2373
Total   13726 24674

An analysis of the average number of parts of a building is beyond the scope
of this, but if you assume that a building like Frederik's example on
average consists of 5 parts then 20% of buildings then consist of multiple
ways. (Or 55% of ways are part of these buildings)

For reference, when I ran the same analysis on the random data (but not
grouping by changeset) I found 5023 buildings and 6375 ways. Using the same
assumptions this is 6.7% of buildings.

I repeated the same analysis, looking only at v1 ways and found 4249
buildings and 5497 for the random changesets and 13109 buildings and 23611
ways for import changesets.

Conclusion:

A significant number of cadastre imported buildings consist of multiple
ways, such as in the example Frederik gave. The difference from other
buildings a week old is statistically significant. This is true even if only
looking at the subset of buildings that are new buildings.

[1]: If anyone doubts this I could carry out an analysis on this point. 

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione qunuxy-osmmailingli...@yahoo.com

2012/9/26 Pieren pier...@gmail.com:
 To Frederik,
 In your example, I agree with you that the diagonal line is a glitch,
 most probably coming from a parcel line just underneath.


actually it is not only the diagonal line (which is an obvious error),
but it is also all or most of the divisions, which don't seem to
corrispond at all to real buildings or parts of them (maybe they are
property divisions, but then the property in this ensemble is divided
quite weird) when confronted with the aerial imagery.

cheers,
Martin

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

[OSM-talk] Mapping Chicago's pedways

2012-09-26 Per discussione David Turner

Chicago's pedway system on OSM is a bit wrong -- it's mostly
disconnected from the rest of the map (check out KeepRight for a bunch
of orange lightning bolts).  This can cause problems for routers.
Apparently, Toronto's system has the same issue.

(I should also note that Chicago doesn't have hour_on and hour_off, but
that's a different issue).  

I would like to just connect the pedways to the streets that they
intersect, but that's not physically accurate; in fact, they're through
buildings (and often down stairs or elevators).  Can anyone suggest a
better way to map them so that they're accurate yet routable?

I'm not local to Chicago, so it would be tough for me to go out and
directly investigate myself.  But I've CC'd a colleague who does live in
Chicago and whom I might be able to pester to help out when he gets the
free time.




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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

2012-09-26 Per discussione Vincent de Chateau-Thierry


Hi,

Le 27/09/2012 02:18, Paul Norman a écrit :



Now, the analysis of geometry.

One measure of how broken down into parts buildings are is to take the
buildings, turn them into polygons, combine them into one multipolygon with
ST_Union and then count the number of parts with ST_Dump and compare it with
the original number of buildings. This does not consider buildings made from
multipolygons (e.g. those with an inner hole). I get the following data

Changeset  Joined  Original
13175035 3661  6341
13175649  503  1240
13176058  521   951
13176212  219   341
13176769  922  1510
13177032 1515  2782
13177569 2216  4291
13180264  536   830
13180628 1449  2230
131816982 2
13183198  506   883
13184921  286   462
13185567  255   438
13185645 1135  2373
Total   13726 24674



I am not sure to understand the right way how you deal with multiple 
buildings sharing ways (= sharing walls IRL) and having each a different 
house number.

For instance how many joined buildings would give your analysis here :
http://www.openstreetmap.org/?mlat=48.86494mlon=2.33zoom=18layers=M
= the block between Rue d'Alger and Rue du 29 juillet ?

vincent

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

[OSM-talk] Pre-delete-bot

2012-09-26 Per discussione Tony Morris

Hello,
I am trying to get the OSM data prior to the running of the deletion
bot. I am able to access CC-BY-SA licenced data from geofabrik, but the
deletion occurred prior to the licence change. Is it possible to access
this data, even if it is by region? Thanks for any tips.

-- 
Tony Morris
http://tmorris.net/



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

Re: [OSM-talk-nl] Overlay met spoorkaart

2012-09-26 Per discussione Pander

On 2012-09-24 17:48, Stefan de Konink wrote:
 On 09/24/12 11:31, Pander wrote:
 Is de overheid overigens verplicht deze gegevens (via een API) openlijk
 te ontsluiten?
 
 openOV krijgt binnenkort periodiek de kleinschalige topografische
 informatie van het spoor. We moeten nog even goed duiden welke
 informatie we wel en niet willen hebben.
 
 Verder vraag ik me af waarom je niet gewoon even gezocht hebt in het
 nationale georegister. NWB Spoor staat daar gewoon in.

Omdat ik hier een newbie ben. :)

Voor Stichting OpenTaal heb ik een gigantische collectie toponiemen
aangelegd uit veel verschillende bronnen om onze open source spelling-
en grammaticacontrole op te kunnen verbeteren.

Achter de schermen bij OpenTaal wordt hard gewerkt aan een nieuwe versie
van onze woordenlijsten. Deze zal in omvang wederom het Groene Boekje
overtreffen (is ook niet het doel van Groene Boekje om uitputtend te
zijn) en ondersteund ook mee toponiemen dan voorheen.

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


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

[talk-au] NSW Alphanumeric at last..

2012-09-26 Per discussione Ian Sergeant

At last..

http://smh.drive.com.au/motor-news/ms-and-bs-to-make-driving-simple-as-abc-minister-20120927-26n4w.html

We should be completely ready to go by March 2013, I think.

Not clear how long the transition will be.

Ian.

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Butrus Damaskus

2012/9/25 Sven Geggus li...@fuchsschwanzdomain.de:
 Hallo zusammen,

 unser Tileserver für den deutschen Stil (http://openstreetmap.de/karte.html)
 bzw. (a-d.)tile.openstreetmap.de läuft dank Mithilfe von Frederik Ramm ab
 sofort mit ODbL Daten.

 Desweiteren werden nun immer die atuellen Küstenlinien von
 http://openstreetmapdata.com/data/land-polygons fürs rendering verwendet,
 sodass auch Inseln und Küstenlinien ebenfalls zeitnah (bestenfalls täglich)
 aktualisiert werden sollten.

 Da der Server nicht so oft neu rendert wie der osm.org Tileserver kann man
 ggf. den Trick mit der /dirty URL anwenden um ein Neurendern einzelner tiles
 zu erzwingen.

Hallo,

das habe ich schon mehrmals gehört, dass es so ein Trick gibt, aber
habe nirgendo gefunden,
wo genau das /dirty kommt. Der Onkel Google war leider nicht so sehr
hilfreich, da er den Schrägstrich
ignoriert...

 Derzeit sind die Daten der Küstenlinien vom 23. September, d.h. gestern Nacht
 war wohl wieder was etwas kaputt. Die anderen Daten sollten typischerweise
 weniger als 30 Minuten hinter der API liegen.

 Gruss

 Sven

 --
 Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
 ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
 geeignet (Jaroslaw Kaczynski)
 /me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

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

Re: [Talk-de] openlayer-example komplett downloaden

2012-09-26 Per discussione Walter Nordmann

versuch es mal mit wget -r
http://openlayers.org/dev/examples/mobile-jq.html#mappage; in einem leeren
Verzeichnis.

Sollte auch mit Win gehen, wenn wget istalliert ist.

Gruss
walter



--
View this message in context: 
http://gis.19327.n5.nabble.com/openlayer-example-komplett-downloaden-tp5727477p5727555.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] openlayer-example komplett downloaden

2012-09-26 Per discussione Lars Lingner

Hallo Jan,

lade Dir doch das komplette Archiv herunter:
http://openlayers.org/download/OpenLayers-2.12.tar.gz

Dort sind auch die Beispiele enthalten.

Oder navigiere auf https://github.com/openlayers/openlayers zu dem
Beispiel und lade Dir dort den Quelltext herunter.

Lars

On 25.09.2012 20:30, Jan Tappenbeck wrote:
 HI !
 
 ich versuche mit an einem refresh meiner smartphone-Karte und wollte auf
 dem Beispiel von OL aufbauen.
 
 Leider hakte es immer und immer wieder so das ich von 0 anfangen will.
 Das Problem ist nun das ich es irgendwie nicht gelingen will das
 Beispiel [1] komplett herunterzuladen.
 
 Wenn ich im FF10 Dateispeichern sage - dann kommt so ein Mist raus [2].
 
 Kann mir einer weiterhelfen - auch wenn die Frage d klingt.
 
 Gruß Jan :-)
 
 
 [1] http://openlayers.org/dev/examples/mobile-jq.html#mappage
 
 [2] www.tappenbeck.net/osm/sandbox/jquery/mobile-jq.html
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


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

Re: [Talk-de] ÖPNVKarte, ODbL Daten

2012-09-26 Per discussione Wolfgang Hinsch

Am Dienstag, den 25.09.2012, 23:15 +0200 schrieb Peter Wendorff:
 Am 25.09.2012 22:14, schrieb nimix:
  Hallo zusammen,
  die ÖPNV-Karte läuft seit ein paar Tagen mit ODbL Daten. Ich habe mich
  entschieden, die Tiles weiterhin unter CC-BY-SA zur Verfügung zu stellen.
  Somit ändert sich für alle, die die Tiles nutzen nicht viel, außer dass die
  Attribution entsprechend auf die ODbL angepasst werden muss. 
[..]
 
  Gibt es eigentlich irgendwo eine deutsche Musterattribution? Die Attribution
  auf openstretmap.de scheint mir nicht 100% korrekt, da die Lizenz der Tiles
  fehlt oder?
+1

 Das liegt aber wohl daran, dass die Lizenz des deutschen Kartenstils 
 unklar ist.

Dann sollten sich die Admins schnellstens auf eine Lizenz einigen.
Soweit ich wei0, bleibt die Hauptkarte auf osm.org bei cc-by-sa.

Gruß, Wolfgang


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26.09.2012 um 8:00, schrieb Jochen Topf:

 Da ist noch ein zusätzlicher, leerer SVG-Layer drin, der das verhindert.

Danke.

Habe die SVG-Layer testweise mit Adblock Plus ausgeblendet und danach 
funktioniert Grafik anzeigen.

Verwendet habe ich folgende Filterregel:
openstreetmap.de##svg

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione qunuxy-osmmailingli...@yahoo.com

Am 26.09.2012 um 8:17, schrieb Butrus Damaskus:
 das habe ich schon mehrmals gehört, dass es so ein Trick gibt, aber

 habe nirgendo gefunden,
 wo genau das /dirty kommt.

Beispiel:

Kachel:
http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png

Kachel dirty:
http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png/dirty

Kachel status:
http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png/status

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

Re: [Talk-de] ÖPNVKarte, ODbL Daten

2012-09-26 Per discussione aighes

Das Problem ist, dass der deutsche Stil aus dem allgemeinen abgeleitet 
ist und dessen Lizenz unklar ist. Aus dessen Lizenz ergeben sich aber 
Anforderungen an die Lizenz der Tiles.


Mal ein hypothetisches Beispiel: Der Stile dürfte nur nc genutzt werden, 
dann kann man schlecht die Tiles als PD deklarieren ;)


Henning


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Stephan Wolff s.wo...@web.de wrote:

 Bei osm.org ist der dirty-Trick schon mühsam. Mit Firefox muss ich auf
 Openstreetmap.de zusätzlich die Grafikadresse über Seiteninformation
 anzeigen - Medien und Suchen in der Liste ermitteln. Wäre es viel 
 Arbeit einen Button hinzuzufügen, mit dem man das Tile in Bildmitte mit
 einem Klick als dirty markieren kann?

Oder den ganzen view, den man grade im Openlayers hat. Das habe ich mir
ehrlich gesagt auch schon überlegt.

Wenn das jemand coden mag der Quellcode für die Seite ist unter
http://svn.openstreetmap.org/sites/www.openstreetmap.de/

Gruss

Sven

-- 
Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Michael Kugelmann michaelk_...@gmx.de wrote:

 Wäre es viel Arbeit einen Button hinzuzufügen 
 Ich wäre gegen einen zusätzllichen Button.

OK, ich seh schon wir brauchen ein greasemonkey-script.

Sven

-- 
Der normale Bürger ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Butrus Damaskus butrus.but...@gmail.com wrote:

 das habe ich schon mehrmals gehört, dass es so ein Trick gibt, aber
 habe nirgendo gefunden,
 wo genau das /dirty kommt. Der Onkel Google war leider nicht so sehr
 hilfreich, da er den Schrägstrich
 ignoriert...

Nehmen wir mal an Du hast gerade den Südflügel des Stuttgarter Bahnhofes
gelöscht, weil er für ein völlig sinnloses Prestigeprojekt abgerissen
wurde :)

http://tile.openstreetmap.de/tiles/osmde/17/68879/45133.png wäre also nicht
mehr aktuell.

Nun rufst Du einfach
http://tile.openstreetmap.de/tiles/osmde/17/68879/45133.png/dirty im Browser
auf. Das veranlasst die render toolchain das Meta-Tile (8x8 Kacheln) in dem
dieses Tile drin ist neu zu rechnen.

Gruss

Sven

-- 
Those who do not understand Unix are condemned to reinvent it, poorly
(Henry Spencer)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Wolfgang Hinsch

Am Dienstag, den 25.09.2012, 16:16 + schrieb Sven Geggus:
 aighes o...@aighes.de wrote:
 
  freut mich zu hören. Darf ich dem Lizenzhinweis entnehmen, dass die 
  Tiles auch ODbL sind?
 
 Tja, das ist eine gute Frage. Ich bin nach wie vor der Meinung, dass Tiles
 lediglich ein Endprodukt des Kartenstils sind, so wie etwa ein compiliertes
 Binary ein Endprodukt seines Quellcodes ist.

Ich würde es eher so sehen, dass der Kartenstil eine Art Compiler ist,
mit dem der Quellcode, die OSM-Daten, in die Tiles umgesetzt wird. Dann
spielt die Lizenz des Stils für die Lizenz des Endprodukts keine Rolle.
So ähnlich sieht es ja auch die ODBL vor, die für ein
Nicht-DB-Endprodukt die Lizenz frei lässt. Das würde wieder unterlaufen,
wenn wir jetzt anfangen, den Kartenstil aus Quelle zu bezeichnen.

 
 Nehmen wir mal an, der Stil wäre GPL, Dann dürfte man unter Mitlieferung des
 Quellcodes (sprich in diesem Fall dem Mapnik Style) die Tiles
 selbstverständlich beliebig verbreiten.
 
 Leider ist die Lizenz des deutschen Kartenstils aber nach wie vor unklar,
 weil er ein Derivat des internationalen Stils darstellt und dessen Lizenz
 ebenfalls unklar ist.
 
 Ich selbst würde unser Derivat gerne unter GPL oder besser noch AGPL stellen.

IMO passt die GPL nicht für Dokumente, wie es tiles letztlich sind, wenn
auch nicht auf Papier. Da wären die CC-* oder OpenDocument-Lizenzen wohl
passender.

 
 Wichtiger als die Lizenz der Tiles ist aber ohnehin die tile usage policy,
 denn unsere Bandbreite ist begrenzt.

+1


Gruß, Wolfgang


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione aighes


Am 26.09.2012 10:57, schrieb Sven Geggus:

Michael Kugelmann michaelk_...@gmx.de wrote:


Wäre es viel Arbeit einen Button hinzuzufügen

Ich wäre gegen einen zusätzllichen Button.

OK, ich seh schon wir brauchen ein greasemonkey-script.
Wie wäre es mit einem URL-Parameter? Bspw. ein Permalink mit 
zusätzlichem dirty markiert den aktuellen Ausschnitt zum neurendern.


Knopf fände ich auch eher schlecht. Das dürfte für viele Nutzer 
verwirrend sein.


Henning


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Wolfgang Hinsch osm-lis...@ivkasogis.de wrote:

 Ich würde es eher so sehen, dass der Kartenstil eine Art Compiler ist,
 mit dem der Quellcode, die OSM-Daten, in die Tiles umgesetzt wird.

Quatsch, der Stil kann gar nichts, er ist lediglich der Quellcode, der das
Aussehen der Karte bestimmt, der Compiler ist Mapnik:

Daten+Stil -- compiler (mapnik) -- Tile

Vor diesem Hintergrund fidne ich, dass es ein unhaltbarer Zusatnd ist, dass
der Standard Mapnik Style keine Lizenz hat.

Die OSM tiles mögen CC-by-SA sein. Aber was ist wenn ich identische Tilese
selber rendere? Dann dürfen nach meiner Auffassung die selben Tiles
auch proprietär verteilt werden. Das finde ich nicht unbedingt schlecht,
aber das sollte klargestellt werden.

 IMO passt die GPL nicht für Dokumente, wie es tiles letztlich sind

Natürlich nicht, aber sie passt für mapnik styles.

Sven

-- 
It's easier for our software to compete with Linux when there's piracy than
when there's not. (Bill Gates)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Jochen Topf

On Wed, Sep 26, 2012 at 11:24:49AM +0200, aighes wrote:
 Am 26.09.2012 10:57, schrieb Sven Geggus:
 Michael Kugelmann michaelk_...@gmx.de wrote:
 
 Wäre es viel Arbeit einen Button hinzuzufügen
 Ich wäre gegen einen zusätzllichen Button.
 OK, ich seh schon wir brauchen ein greasemonkey-script.
 Wie wäre es mit einem URL-Parameter? Bspw. ein Permalink mit
 zusätzlichem dirty markiert den aktuellen Ausschnitt zum
 neurendern.
 
 Knopf fände ich auch eher schlecht. Das dürfte für viele Nutzer
 verwirrend sein.

Bitte nicht. Das ist aus gutem Grund so obskur! Wenn das so einfach wäre, dann
macht das jeder per default und der Server ist platt.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Markus


Hallo Henning,


Wie wäre es mit einem URL-Parameter?


und die derty-URL in das Rechtsklick-Menü für die Maus,
zusammen mit anderen nützlichen Dingen:
- Kachel neu rendern
- Mauskoordinate in Zwischenablage kopieren
- ...

Gruss, Markus


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Simon Poole


Sven

Ich würde zugeben, dass man die Lage auch wie du es siehst
interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.

Analoges Beispiel: du hast eine CC-by-SA Textdatei, eine BSD-lizensierte
sed Implementation, und ein GPL sed Skript. Lässt du den Text durch sed
durch mit dem Skript so steht das Resultat unter CC-by-SA, nicht GPL und
auch nicht unter der BSD-Lizenz.

Simon


Am 25.09.2012 18:16, schrieb Sven Geggus:
 aighes o...@aighes.de wrote:

 freut mich zu hören. Darf ich dem Lizenzhinweis entnehmen, dass die 
 Tiles auch ODbL sind?
 Tja, das ist eine gute Frage. Ich bin nach wie vor der Meinung, dass Tiles
 lediglich ein Endprodukt des Kartenstils sind, so wie etwa ein compiliertes
 Binary ein Endprodukt seines Quellcodes ist.

 Nehmen wir mal an, der Stil wäre GPL, Dann dürfte man unter Mitlieferung des
 Quellcodes (sprich in diesem Fall dem Mapnik Style) die Tiles
 selbstverständlich beliebig verbreiten.

 Leider ist die Lizenz des deutschen Kartenstils aber nach wie vor unklar,
 weil er ein Derivat des internationalen Stils darstellt und dessen Lizenz
 ebenfalls unklar ist.

 Ich selbst würde unser Derivat gerne unter GPL oder besser noch AGPL stellen.

 Wichtiger als die Lizenz der Tiles ist aber ohnehin die tile usage policy,
 denn unsere Bandbreite ist begrenzt.

 Gruss

 Sven




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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Simon Poole si...@poole.ch wrote:

 Ich würde zugeben, dass man die Lage auch wie du es siehst
 interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
 dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
 die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.

Der Einfluss auf das Endprodukt ist mir nicht wichtig, wenn man tiles selber
rendert umgeht man die CC-by_SA sowieso elegant.

Interessant finde ich Deine Bezeichnung Verarbeitungsvorschrift,
eigentlich nur ein anderer Name für script oder programm, also doch wieder
Quellcode.

Wie gesagt ich finde dass Stylefiles Quellcode darstellen und eine
entsprechende Lizenz haben sollten. Das betrifft dann nur die Anwendung des
Stils nicht dessen Endprodukt.

Wenn ein Stil z.B. unter AGPL stehen würde dürfte man den beliebig
verwenden, wenn man aber nun Änderungen für den eigenen Tileserver macht
müsste man diese Änderungen veröffentlichen.

Kurioserweise ist uns bei den Daten der virulente charakter wichtig, beim
Stil scheint das aber niemanden zu interessieren.

Gruss

Sven

-- 
Das Einzige wovor wir Angst haben müssen ist die Angst selbst
(Franklin D. Roosevelt)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Simon Poole


Am 26.09.2012 12:03, schrieb Sven Geggus:
 ..

 Interessant finde ich Deine Bezeichnung Verarbeitungsvorschrift,
 eigentlich nur ein anderer Name für script oder programm, also doch wieder
 Quellcode.

 Wie gesagt ich finde dass Stylefiles Quellcode darstellen und eine
 entsprechende Lizenz haben sollten. Das betrifft dann nur die Anwendung des
 Stils nicht dessen Endprodukt.

Dann sind wir ja gleicher Meinung.

 Wenn ein Stil z.B. unter AGPL stehen würde dürfte man den beliebig
 verwenden, wenn man aber nun Änderungen für den eigenen Tileserver macht
 müsste man diese Änderungen veröffentlichen.

 Kurioserweise ist uns bei den Daten der virulente charakter wichtig, beim
 Stil scheint das aber niemanden zu interessieren.
Den Urhebern scheint es zumindest nicht wichtig (gewesen) zu sein.
Nachträglich wird es wohl schwierig werden da ein Konsens zu finden,
kannst es aber versuchen.

Simon


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26. September 2012 11:25 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 Daten+Stil -- compiler (mapnik) -- Tile


Ich würde es eher so sehen:
Daten -- Compiler (mapnik) + Stil -- Tile


 Vor diesem Hintergrund fidne ich, dass es ein unhaltbarer Zusatnd ist, dass
 der Standard Mapnik Style keine Lizenz hat.


+1

Gruß Martin

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Martin Koppenhoefer dieterdre...@gmail.com wrote:

 Daten+Stil -- compiler (mapnik) -- Tile
 
 Ich würde es eher so sehen:
 Daten -- Compiler (mapnik) + Stil -- Tile

Jain. Mapnik ist hier mit einem klassischen Scriptinterpreter oder sowas
vergleichbar und der Stil wäre das script.

Es ist natürlich müsig darüber zu streiten ob ein Stil jetzt eher Software
ist und die Lizenz GPLCo sein sollte oder eher ein künstlerisches Werk
darstellt und die Lizenz wäre eher CCCo. In der Praxis ist so ein Stil
natürlich beides.

Sven

-- 
The term any key does not refer to a particular key on the keyboard. It
simply means to strike any one of the keys on your keyboard or handheld
screen. (Compaq FAQ Entry 2859)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26. September 2012 11:39 schrieb Simon Poole si...@poole.ch:
 Ich würde zugeben, dass man die Lage auch wie du es siehst
 interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
 dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
 die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.


Ein Kartenstil ist doch urheberrechtlich geschützt (potentiell
schützenswert), und das Aussehen der abgeleiteten Kartenwerke aus
OSM-Daten hängt neben den Daten maßgeblich vom Stil ab. Fast alles was
geschützt werden kann (Feature-Auswahl, Farbgebung, Linienstärken,
evtl. Verdrängung und Priorisierung, Schriftarten und -größen,
Symbole, etc.) wird vom Stil (Rules) bestimmt (lediglich Abstraktion
und wiederum Auswahl hängen von den Daten ab).

Gruß Martin

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Simon Poole si...@poole.ch wrote:

 Den Urhebern scheint es zumindest nicht wichtig (gewesen) zu sein.
 Nachträglich wird es wohl schwierig werden da ein Konsens zu finden,
 kannst es aber versuchen.

Jede Lizenz wäre besser als gar keine Lizenz. Vielleicht finden wir ja
Zustimmung der Authoren des Stil unter PD bzw. CC0 zu veröffentlichen.

Wie gesagt ich finde Softwarelizenzen besser geeignet als CC, denn CC
Lizenzen hätte wieder das Problem, dass sie sich auf die erzeugten Tiles
vererbt.

Gruss

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26. September 2012 12:27 schrieb Martin Koppenhoefer
dieterdre...@gmail.com:
 Am 26. September 2012 11:39 schrieb Simon Poole si...@poole.ch:
 Ich würde zugeben, dass man die Lage auch wie du es siehst
 interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
 dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
 die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.


 Ein Kartenstil ist doch urheberrechtlich geschützt (potentiell
 schützenswert), und das Aussehen der abgeleiteten Kartenwerke aus
 OSM-Daten hängt neben den Daten maßgeblich vom Stil ab. Fast alles was
 geschützt werden kann (Feature-Auswahl, Farbgebung, Linienstärken,
 evtl. Verdrängung und Priorisierung, Schriftarten und -größen,
 Symbole, etc.) wird vom Stil (Rules) bestimmt (lediglich Abstraktion
 und wiederum Auswahl hängen von den Daten ab).

@Martin: Und folgt deiner Meinung nach daraus, dass die Tiles die
Lizenz des Kartenstils teilen?

Falk

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Simon Poole


Am 26.09.2012 12:27, schrieb Martin Koppenhoefer:
 Am 26. September 2012 11:39 schrieb Simon Poole si...@poole.ch:
 Ich würde zugeben, dass man die Lage auch wie du es siehst
 interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
 dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
 die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.

 Ein Kartenstil ist doch urheberrechtlich geschützt (potentiell
 schützenswert),

Das ist völlig unbestritten.

  und das Aussehen der abgeleiteten Kartenwerke aus
 OSM-Daten hängt neben den Daten maßgeblich vom Stil ab. Fast alles was
 geschützt werden kann (Feature-Auswahl, Farbgebung, Linienstärken,
 evtl. Verdrängung und Priorisierung, Schriftarten und -größen,
 Symbole, etc.) wird vom Stil (Rules) bestimmt (lediglich Abstraktion
 und wiederum Auswahl hängen von den Daten ab).

Stimmt auch, aber natürlich hängt das konkrete Produkt der Verarbeitung
auch von den Objekten und ihrer der Geometrie in den Daten ab. Wie ich
Eingangs gesagt habe, kann man wohl in guten Treuen verschiedener
Meinung sein wie sich das auf die Lizenz der Tiles auswirkt. Das Gute am
der ODbL ist das man den Konflikt nicht mehr hat, solange ein
entsprechender Quellenhinweis für die Daten vorhanden ist.

Simon



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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26. September 2012 12:34 schrieb Falk Zscheile falk.zsche...@gmail.com:
 Am 26. September 2012 12:27 schrieb Martin Koppenhoefer
 dieterdre...@gmail.com:
 Am 26. September 2012 11:39 schrieb Simon Poole si...@poole.ch:
 Ich würde zugeben, dass man die Lage auch wie du es siehst
 interpretieren kann. Denke aber die verbreitete Sichtweise ist eher,
 dass das Style File eine Verarbeitungsvorschrift für die OSM Daten ist
 die selber keine  keine Wirkung auf der Lizenz des Outputproduktes hat.


 Ein Kartenstil ist doch urheberrechtlich geschützt (potentiell
 schützenswert), und das Aussehen der abgeleiteten Kartenwerke aus
 OSM-Daten hängt neben den Daten maßgeblich vom Stil ab. Fast alles was
 geschützt werden kann (Feature-Auswahl, Farbgebung, Linienstärken,
 evtl. Verdrängung und Priorisierung, Schriftarten und -größen,
 Symbole, etc.) wird vom Stil (Rules) bestimmt (lediglich Abstraktion
 und wiederum Auswahl hängen von den Daten ab).

 @Martin: Und folgt deiner Meinung nach daraus, dass die Tiles die
 Lizenz des Kartenstils teilen?


schwierige Frage denke ich. Vielleicht braucht man ja eine Lizenz, die
genau für einen solchen Fall geschrieben wird/ist, d.h. für Programme
bzw. strukturierte Regeln, die dazu verwendet werden können,
automatisiert Werke abzuleiten, und die vorgibt, unter welcher Lizenz
diese Werke dann stehen dürfen. Im Prinzip sehe ich es ähnlich wie
Sven: die Möglichkeiten zur Tile-lizensierung ergeben sich aus der
Lizenz der Daten UND aus der Lizenz des Stils.

Gruß Martin

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

Re: [Talk-de] openlayer-example komplett downloaden -erledigt

2012-09-26 Per discussione Jan Tappenbeck


Danke für die Hilfe !


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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Simon Poole si...@poole.ch wrote:

 Das Gute am der ODbL ist das man den Konflikt nicht mehr hat, solange ein
 entsprechender Quellenhinweis für die Daten vorhanden ist.

Aber genau das führt nun auch dazu, dass die Lizenz der Styles plötzlich
relevant geworden ist. Vorher war das egal, denn da haben die tiles
automatisch CC-by-SA von den Daten geerbt.

Gruss

Sven

-- 
It's easier for our software to compete with Linux when there's piracy than
when there's not. (Bill Gates)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Am 26. September 2012 13:33 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 Vorher war das egal, denn da haben die tiles
 automatisch CC-by-SA von den Daten geerbt.


zumindest hat man so getan, als wäre es so ;-)

Gruß Martin

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Frederik Ramm


Hallo,

On 09/26/12 13:33, Sven Geggus wrote:

Das Gute am der ODbL ist das man den Konflikt nicht mehr hat, solange ein
entsprechender Quellenhinweis für die Daten vorhanden ist.


Aber genau das führt nun auch dazu, dass die Lizenz der Styles plötzlich
relevant geworden ist. Vorher war das egal, denn da haben die tiles
automatisch CC-by-SA von den Daten geerbt.


Aber wir sind uns doch einig darin, dass die Tiles niemals irgendeine 
Lizenz vom Style erben werden, oder?


Das Maxium, was man mit einer AGPL-artigen Lizenz auf dem Style 
erreichen koennte, ist: Wenn Du diese Tiles weitergibst (wobei Du eine 
beliebige Lizenz mit Attribution waehlen kannst), musst Du auch den 
zugehoerigen Style (der unter AGPL steht) weitergeben.


Dass durch die neue Lizenz hier eine fuer den Stil bedeutsame Aenderung 
eingetreten ist, sehe ich nicht - denn schon unter der alten Lizenz 
konnte ich doch tolle Tiles machen (die ich CC-BY-SA freigab) und den 
Stil fuer mich behalten.


Bye
Frederik

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

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

2012-09-26 Per discussione Chris66

Am 26.09.2012 15:15, schrieb Falk Zscheile:

 Mir sind in letzter Zeit vermehrt fälle von taggen für den Renderer
 aufgefallen. So wurden Natura2000 Gebiete als
 leisure=nature_reserve[1] und nautische Warngebiete als
 landuse=military[2] eingetragen. Dahinter steht natürlich der Gedanke,
 dass, was man einträgt auch sehen zu wollen. 

na, so falsch ist das zumindest für den Laien doch nicht.

Was wären denn Deiner Meinung nach die richtigen Tags?

Christian




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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

Frederik Ramm frede...@remote.org wrote:

 Dass durch die neue Lizenz hier eine fuer den Stil bedeutsame Aenderung 
 eingetreten ist, sehe ich nicht - denn schon unter der alten Lizenz 
 konnte ich doch tolle Tiles machen (die ich CC-BY-SA freigab) und den 
 Stil fuer mich behalten.

Es gab sehr wohl einen Unterschied, denn es hat Dir schlichtweg nichts
gebracht den Stil für Dich zu behalten weil die Tiles ja automatisch
CC-by-SA geworden sind. das hat den Stil indirekt geschützt und dieser
Schutz ist jetzt weg.

Gruss

Sven

-- 
C Is Quirky, Flawed, And An Enormous Success.
(Dennis M. Ritchie)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

Am 26. September 2012 15:49 schrieb Chris66 chris66...@gmx.de:
 Am 26.09.2012 15:15, schrieb Falk Zscheile:

 Mir sind in letzter Zeit vermehrt fälle von taggen für den Renderer
 aufgefallen. So wurden Natura2000 Gebiete als
 leisure=nature_reserve[1] und nautische Warngebiete als
 landuse=military[2] eingetragen. Dahinter steht natürlich der Gedanke,
 dass, was man einträgt auch sehen zu wollen.

 na, so falsch ist das zumindest für den Laien doch nicht.

 Was wären denn Deiner Meinung nach die richtigen Tags?

Ich habe in beiden Fällen keine Ahnung, was das richtige Tag wäre,
aber ich bin mir sicher, dass es nicht das ist, was wir bisher als
Naturschutzgebiet (leisure=nature_reserve) bzw. Sperrgebiet
(landuse=military) getaggt haben. Ich sehe es auch nicht als meine
(zwingende) Aufgabe an, den anderen Usern die Gedankenarbeit
abzunehmen, wie man etwas in der Datenbank erfasst. in beiden Fällen
sind sie sich ja offensichtlich darüber klar was sie da vor sich
haben. Der eine Beschreibt sein Gebiet als Natura 2000 und der andere
zutreffend als Warngebiet (danger_area) beiden gemeinsam ist es aber,
dass dann auch noch ein (falsches) Tag verwendet wird, damit man
etwas in der Karte sieht. DAS macht es nicht einfacher. Wenn da nur
leisure=nature_2000 oder landuse=danger_area stehen würde, dann wäre
es nicht in der Karte und ich hätte keine Schmerzen damit. Aber ich
wollte eigentlich keine Diskussion über richtiges tagging führen ...

Falk

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

2012-09-26 Per discussione Jan Jesse

Hi,
 Am 26.09.2012 15:15, schrieb Falk Zscheile:
 
  Mir sind in letzter Zeit vermehrt fälle von taggen für den Renderer
  aufgefallen. So wurden Natura2000 Gebiete als
  leisure=nature_reserve[1] und nautische Warngebiete als
  landuse=military[2] eingetragen. Dahinter steht natürlich der Gedanke,
  dass, was man einträgt auch sehen zu wollen.
 
 na, so falsch ist das zumindest für den Laien doch nicht.
 
 Was wären denn Deiner Meinung nach die richtigen Tags?
 
 Christian
 

Ich glaube, daß solche für den Renderer gemachten Einträge auf Dauer 
gefährlich sind, da hier keine Realität, sondern ein gewünschtes Kartenbild 
generiert wird. Im Zusammenhang mit nautischen Informationen hat das aber 
inzwischen seine Tradition. OpenSeaMap fährt da eine ziemlich eigenwillige 
Strategie. Schade finde ich, daß sie tatsächlich meinen, alle Informationen 
nach eigenem Schema neu taggen zu müssen, dabei unendlich viele Fehler 
passieren und die Konsistenz der nautischen Informationen zumindest in 
Deutschland erheblich gestört ist.

Die richtigen tags? Ganz klar die, die die Realität beschreiben. Und wenn ich 
das auf einer Karte sehen will, muß ich eben dafür sorgen, daß richtige 
Informationen auch richtig dargestellt werden.

Ach ja: Edit-War? Eindeutig die falsche Strategie. Die Jungs haben mehr 
Ausdauer, als Du glaubst, und der, der den Editwar begonnen hat, eindeutig die 
Community gegen sich. Also denk besser nicht darüber nach 

;-)

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

2012-09-26 Per discussione Frederik Ramm


Hi,

On 09/26/12 16:35, Falk Zscheile wrote:

Ich habe in beiden Fällen keine Ahnung, was das richtige Tag wäre,
aber ich bin mir sicher, dass es nicht das ist, was wir bisher als
Naturschutzgebiet (leisure=nature_reserve) bzw. Sperrgebiet
(landuse=military) getaggt haben.


Ich haette in beiden Faellen gar keine Bedenken, die Tags zu entfernen, 
wenn ich mir *sicher* waere, dass es sich nicht tatsaechlich um ein 
Naturschutzgebiet oder ein militaerisches Sperrgebiet handelt. Der 
einzige Grund, warum ich das jetzt nicht mache, ist, dass ich mir nicht 
sicher bin - was weiss denn ich, ob ein für das ökologische Netzwerk 
NATURA 2000 gemeldetes Schutzgebiet nun ein Naturschutzgebiet ist oder 
nicht, bzw. ob die genannte Danger Area nun deswegen eine Danger Area 
ist, weil dort Schiessuebungen stattfinden oder aus welchem Grund auch 
immer.


Wenn jemand begruenden kann, warum diese Tags falsch sind, dann sollte 
er das den Leute mitteilen und es entsprechend aendern und im Falle 
eines beginnenden Editwars die DWG anschreiben.


Gerade das OpenSeaMap-Team ist in der Vergangenheit oefters mit 
Eigenmaechtigkeiten beim Tagging aufgefallen, auf die man freundlich, 
aber bestimmt hinweisen sollte; OpenSeaMap hat einen eigenen 
Rendering-Stack und kann voellig problemlos auch ein seamark:type = 
restricted_area in die eigenen Karten einzeichnen, die muessen dazu 
kein landuse=military setzen.


Bye
Frederik


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

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

Am 26. September 2012 16:39 schrieb Jan Jesse j...@jesse.de:


 Ich glaube, daß solche für den Renderer gemachten Einträge auf Dauer 
 gefährlich sind, da hier keine Realität,
 sondern ein gewünschtes Kartenbild generiert wird. Im Zusammenhang mit 
 nautischen Informationen hat das aber
 inzwischen seine Tradition. OpenSeaMap fährt da eine ziemlich eigenwillige 
 Strategie. Schade finde ich, daß sie
 tatsächlich meinen, alle Informationen nach eigenem Schema neu taggen zu 
 müssen, dabei unendlich viele Fehler
 passieren und die Konsistenz der nautischen Informationen zumindest in 
 Deutschland erheblich gestört ist.


Auch wenn ich mich im Schema von OpenSeaMap nicht besonders auskenne,
so glaube ich nicht, dass  landuse=military auf das Konto des OSeaM
Schemas geht. OSeaM hatte sich da mit Sicherheit etwas eigenes
ausgedacht, schwerer verständliches ausgedacht ;-)

Aber es kann ja auch nicht die Lösung sein, dass ich den OSeaM-Leuten
auf die Nerven gehe, damit sie
seamark:restricted_area:category=military in der eigenen Karte
darstellen, damit ich dann dem user, der landuse=military unpassend
verwendet schreiben kann Das musst du jetzt nicht mehr machen, OSeaM
kann das jetzt selbst

Gruß, Falk

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Butrus Damaskus

2012/9/26 qunuxy-osmmailingli...@yahoo.com qunuxy-osmmailingli...@yahoo.com:
 Am 26.09.2012 um 8:17, schrieb Butrus Damaskus:
 das habe ich schon mehrmals gehört, dass es so ein Trick gibt, aber

 habe nirgendo gefunden,
 wo genau das /dirty kommt.

 Beispiel:

 Kachel:
 http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png

 Kachel dirty:
 http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png/dirty

 Kachel status:
 http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png/status


OK, danke!
(Konnte nicht ganz glauben, dass man das /dirty wirklich ganz hinten
tut, aber es war wirklich so... :-)

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

Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien

2012-09-26 Per discussione Butrus Damaskus

2012/9/26 Sven Geggus li...@fuchsschwanzdomain.de:
 Michael Kugelmann michaelk_...@gmx.de wrote:

 Wäre es viel Arbeit einen Button hinzuzufügen
 Ich wäre gegen einen zusätzllichen Button.

 OK, ich seh schon wir brauchen ein greasemonkey-script.

 Sven

Oder eher einen JOSM-plugin (oder so was)?

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

2012-09-26 Per discussione Jimmy_K

Am 26.09.2012 16:35, schrieb Falk Zscheile:
 Ich habe in beiden Fällen keine Ahnung, was das richtige Tag wäre,
 aber ich bin mir sicher, dass es nicht das ist, was wir bisher als
 Naturschutzgebiet (leisure=nature_reserve) ...

Warum fallen Natura2000 generell nicht unter Naturschutzgebiete?
Aufgabe der Natura2000 ist es nicht, die Nationalparks, etc. zu
ersetzen, sondern zu stärken. Wenn ich mir aber so die Ziele der beiden
Richtlinien durchlese, dann ist das ziemlich genau das, was ich unter
einem Naturschutzgebiet verstehe (mit sehr wenigen möglichen Ausnahmen).

In diesem Fall kann ich deine Haltung absolut nicht nachvollziehen.


Jimmy

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

Am 26. September 2012 20:44 schrieb Jimmy_K jimm...@gmx.at:
 Am 26.09.2012 16:35, schrieb Falk Zscheile:
 Ich habe in beiden Fällen keine Ahnung, was das richtige Tag wäre,
 aber ich bin mir sicher, dass es nicht das ist, was wir bisher als
 Naturschutzgebiet (leisure=nature_reserve) ...

 Warum fallen Natura2000 generell nicht unter Naturschutzgebiete?
 Aufgabe der Natura2000 ist es nicht, die Nationalparks, etc. zu
 ersetzen, sondern zu stärken. Wenn ich mir aber so die Ziele der beiden
 Richtlinien durchlese, dann ist das ziemlich genau das, was ich unter
 einem Naturschutzgebiet verstehe (mit sehr wenigen möglichen Ausnahmen).

 In diesem Fall kann ich deine Haltung absolut nicht nachvollziehen.


Weil Naturschutzgebiete Nuneinmal dur dann welche sind, wenn der
Deutsche Verordnungsgeber sagt es sind welche
(Bundesnaturschutzgesetz). Da geht vielleicht eine FFH-Richtlinie in
die gleiche Richtung, aber es ist und bleibt etwas anderes, als ein
nach dem Naturschutzgebiet. Es wäre an mir vorbeigegangen, wenn es
einen Konsens dahin geben würde, dass alles, was irgendwie die Natur
schützt  nature_reserve wäre. Zumal der Deutsche Gesetzgeber dort wo
diese Natura2000 Gebiete auf der Ostsee ausgewiesen sind noch nicht
einmal Hoheitsrechte geltend machen kann und so den Schutzzweck
durchsetzen -- sie liegen nämlich außerhalb der 12 sm Zone.

Gruß Falk

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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer

2012-09-26 Per discussione Peter Wendorff


Ohne jetzt das Tag aufweichen zu wollen, nur als Denkanstoß:
Für leisure=nature_reserve im Ausland ist auch nicht das 
Bundesnaturschutzgesetz zuständig, ob das also so festgelegt in OSM 
stimmt, weiß ich nicht (kann sein, hab mich aber noch nicht damit 
beschäftigt). Zumindest kann man aus dem Tag sowieso (weltweit) nicht 
aufs deutsche Recht pochen.


Gruß
Peter

Am 26.09.2012 20:56, schrieb Falk Zscheile:

Am 26. September 2012 20:44 schrieb Jimmy_K jimm...@gmx.at:

Am 26.09.2012 16:35, schrieb Falk Zscheile:

Ich habe in beiden Fällen keine Ahnung, was das richtige Tag wäre,
aber ich bin mir sicher, dass es nicht das ist, was wir bisher als
Naturschutzgebiet (leisure=nature_reserve) ...

Warum fallen Natura2000 generell nicht unter Naturschutzgebiete?
Aufgabe der Natura2000 ist es nicht, die Nationalparks, etc. zu
ersetzen, sondern zu stärken. Wenn ich mir aber so die Ziele der beiden
Richtlinien durchlese, dann ist das ziemlich genau das, was ich unter
einem Naturschutzgebiet verstehe (mit sehr wenigen möglichen Ausnahmen).

In diesem Fall kann ich deine Haltung absolut nicht nachvollziehen.


Weil Naturschutzgebiete Nuneinmal dur dann welche sind, wenn der
Deutsche Verordnungsgeber sagt es sind welche
(Bundesnaturschutzgesetz). Da geht vielleicht eine FFH-Richtlinie in
die gleiche Richtung, aber es ist und bleibt etwas anderes, als ein
nach dem Naturschutzgebiet. Es wäre an mir vorbeigegangen, wenn es
einen Konsens dahin geben würde, dass alles, was irgendwie die Natur
schützt  nature_reserve wäre. Zumal der Deutsche Gesetzgeber dort wo
diese Natura2000 Gebiete auf der Ostsee ausgewiesen sind noch nicht
einmal Hoheitsrechte geltend machen kann und so den Schutzzweck
durchsetzen -- sie liegen nämlich außerhalb der 12 sm Zone.

Gruß Falk

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




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

Re: [Talk-de] Küstenlinien

2012-09-26 Per discussione Markus


Hallo Martin,


In Italien werden die Grenzen auf dem Meer anhand der sog. Basislinie
berechnet (die Grenzen sind ein Offset um 12 nautische Meilen).
Der Verlauf dieser Basislinie ist in einem Gesetz festgelegt


Richtig.


Vermutlich gibt es so eine Basislinie auch in Deutschland?


Richtig.

Basislinien sind meist Geraden zwischen amtlich festgelegten Punkten.
Davon wird die 12-Meilen-Zone abgeleitet.
Dabei werden Buchten, Flussmündungen und Meeresteile zwischen Inseln und 
zwischen Inseln und Festland als zum Land gehörend bezeichnet.

Die Grenzen sind meist mit den Nachbarstaaten in einem Abkommen geregelt.

Siehe http://wiki.openstreetmap.org/wiki/Grenze

Gruss, Markus


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

Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer