date:20120928

What does Unknown license mean for fotos in the wiki? Isn't there a
requirement for them to be at least available under cc-by-sa?
An example is here: http://wiki.openstreetmap.org/wiki/File:Ballroom.jpg

cheers,
Martin

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

Re: [OSM-legal-talk] Wiki fotos with Unkunown license

2012-09-28 Per discussione Stephan Knauss


On 28.09.2012 10:10, Martin Koppenhoefer wrote:

What does Unknown license mean for fotos in the wiki? Isn't there a
requirement for them to be at least available under cc-by-sa?
An example is here: http://wiki.openstreetmap.org/wiki/File:Ballroom.jpg


Google image search found this picture for sale on this stock photo agency:

http://www.inmagine.com/crb273/crb273017-photo

I suggest to try contacting the wiki-user who uploaded the picture to 
clarify the license and remove the picture completely if we don't get an 
appropriate answer in time.


Stephan


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

Re: [OSM-legal-talk] Wiki fotos with Unkunown license

2012-09-28 Per discussione Dave F.


On 28/09/2012 16:15, Stephan Knauss wrote:
Google image search found this picture for sale on this stock photo 
agency:


Bleedin' hell! Look at those prices! That has got to be a joke.

Dave F.

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

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

2012-09-28 Per discussione Paul Norman

 From: THEVENON Julien [mailto:julien_theve...@yahoo.fr]
 Sent: Thursday, September 27, 2012 10:14 PM
 To: penor...@mac.com; cqu...@openstreetmap.fr; si...@poole.ch
 Cc: talk@openstreetmap.org
 Subject: Réf.: Re: [OSM-talk] All you've ever wanted to know about the
 french cadastre

 Le ven. 28 sept. 2012 02:13 HAEC, Paul Norman a écrit :

 Obviously buildings are part of it, but is there a list of what else?

 Hi,

 I don't think there is a list.
 the information that you can find are highway references,street
 names,city boundaries,cemetery boundaries,buildings,house
 number,hydrographic layer(this one is not really reliable so must be
 cross check carrefully with other sources),railways.
 only buildings railways cemetery boundaries and hydrographic shapes are
 automatically extracted. Other information must be read by contributor
 in cadastre overlay because automatic solutions are not reliable at the
 moment

How do people know what features they can import without going through
additional consultation as a new import?

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

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

2012-09-28 Per discussione THEVENON Julien






--
Le ven. 28 sept. 2012 08:00 HAEC, Paul Norman a écrit :

 From: THEVENON Julien [mailto:julien_theve...@yahoo.fr]
 Sent: Thursday, September 27, 2012 10:14 PM
 To: penor...@mac.com; cqu...@openstreetmap.fr; si...@poole.ch
 Cc: talk@openstreetmap.org
 Subject: Réf.: Re: [OSM-talk] All you've ever wanted to know about the
 french cadastre
 
 
 Le ven. 28 sept. 2012 02:13 HAEC, Paul Norman a écrit :
 
 
 Obviously buildings are part of it, but is there a list of what else?
 
 
 Hi,
 
 I don't think there is a list.
 the information that you can find are highway references,street
 names,city boundaries,cemetery boundaries,buildings,house
 number,hydrographic layer(this one is not really reliable so must be
 cross check carrefully with other sources),railways.
 only buildings railways cemetery boundaries and hydrographic shapes are
 automatically extracted. Other information must be read by contributor
 in cadastre overlay because automatic solutions are not reliable at the
 moment

How do people know what features they can import without going through
additional consultation as a new import?


sorry this detailled here in section les differents calques 
 
wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Aspects_techniques_du_cadastre_en_ligne
 and here qu est ce qui est reutilisable
 
wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Conditions_d'utilisation
 
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-28 Per discussione Sarah Hoffmann

On Thu, Sep 27, 2012 at 10:21:38PM +0100, THEVENON Julien wrote:
  De : Sarah Hoffmann lon...@denofr.de
  I don't know which data you have been looking at, but let's ask
 Nominatim, shall we?
 
 Ok, so by example could you extract stats from Grenoble instead of whole 
 France ? I thinks this quite representative of cities where there are 
 buildings and quite a lot of details.

Grenoble (as in relation 80348) has 13199 raw buildings and 10160 other
objects indexed. So, yes, this seems to be an example where the cadastre
data was put to very good use. But the fact remains that this does not
happen in most of the rest of France. The larger part of cadastre data
is just dumped into the data base never to be touched again by any mapper.

(For reference: for the entire planet there are approx. two other objects
for each raw building. This ratio holds even for Germany.)

 Concerning discussions about separated accounts I`m sure that there is a good 
 reason behind that but it was perhaps decided for cases that do not match 
 French one. What we are trying to do here is to discuss to understand why 
 this rule has been done ( that's why we are asking for a list of issues that 
 import Guidelines Rules want to address ) and if it is possible to find a 
 solution both  satisfy the goal you have and that do not create problems for 
 good-will french mapppers that spend time to perform clean cadastre 
 integration. I`m convinced ( or at least I hope )that you don`t create this 
 rule to make French mappers crazy.

The main problem is that you are asking for an exception to the import
rules on the grounds that your imports are small and carefully manually
checked and augmented with non-cadastre data. The numbers simply don't
support your claims. In fact, they say that the cadastre import is the
largest import OSM currently has to deal with, if it is not even the
largest import OSM ever had to deal with. If the French community could
admit that it would be a big step towards resolving the conflict.

Nobody contests that the cadastre situation is special.
There is no question that you have been thinking about this import very
carefully. The amount of work you have put in the development of tools
for it is admirable and you put a lot of effort into monitoring the
progress, so it certainly is not completely dead data. Still, the amount
of data you add is more than could be possibly ever looked over and
amended by the French community. The Germans did have a bit of a head
start and so far managed to 'only' add about 13 million objects to the
database, half of what you have added in buildings.

I do think that Richard's proposal presents a fair compromise for you.
Those who only want to add a bit of data for their home town can do so
without the hassle of creating a second account but those who import the
data on a larger scale without the chance to ever check what they import
locally must adhere to the import guidlines and do so on a special 
account. The barrier of entry that creates is not necessarily a bad
thing.

 Concerning the waste of bandwidth and CPU, the nuisance for people who want 
 to use OSM data I understand the problem but I guess it will come even 
 without cadastre because due to Open Data mouvment there will certainly more 
 and more big data sources to integrate.

It it not really the amount of data that is the problem. There are ways
to handle that. Storage does get cheaper with time. The problem is that
the data, as it is today, is - excuse the hard word - garbage in the
eyes of data users. You cannot use it for search or routing, there are
no addresses or names or pois. It is rather ugly for rendering, there are
no real buildings just unspecific building parts and way too much detail
(small round edifices using up 40 nodes, what for?). You cannot do real
statistics on them, there are just unspecific building parts...
So essentially alomost every data user has to go through 25 million 
buildings just to throw them away. It is not the end of the world,
but it is mildly annoying.

cadastre could be a great resource for mappers if used responsibly.
Restrict yourself to areas where you know that mappers will add more
details immediately. If you really believe that importing the data
attracts new mappers then make sure that the data is massively
simplified before the import. You still have the source. If really
in the future somebody wants to add information that require more 
detailed building outlines, you can go back to cadastre and get
those details. If you could change your strategy in that way you
would make the data infinitly more useful for data users and you
would most likely find much less opposition in the international
community against cadastre.

Sarah

___
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-28 Per discussione Paul Norman

 Le ven. 28 sept. 2012 08:00 HAEC, Paul Norman a écrit :
 
 
 sorry this detailled here in section les differents calques
 wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Aspects_techni
 ques_du_cadastre_en_ligne
  and here qu est ce qui est reutilisable
 wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Conditions_d'u
 tilisation

I wasn't asking about legal restrictions. I was asking what can be imported
without having to go to the community to consult about a new import.


___
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

2012-09-28 Per discussione Shaun McDonald


On 28 Sep 2012, at 06:25, THEVENON Julien julien_theve...@yahoo.fr wrote:

 
 
 
 
 
 --
 Le jeu. 27 sept. 2012 20:18 HAEC, Sarah Hoffmann a écrit :
 
 This is the real problem for us.
 
 For the sake of completeness: planetwide there are currently
 152 million objects. Which means 1/6th of the planet consists of
 French buildings. Now, there is a real problem.
 
 Hi Sara,
 
 concerning problem of disk usage by french cadastre data do you have some 
 information?particulary do you know how is it stored in database?
 to be allowed to use cadastre data we have to add a source key which is long 
 about 40 characters to each way drawn thanks cadastre data due to legal 
 agreement with french office goverment providing cadastre data.
 do you know is this key is duplicatd for each building in the database or if 
 there is a smart storage? if not it would be interesting to know which part 
 of the size is for the key itself and which part is for the geometry. I think 
 that for buildings composed of one way and 4 nodes the space required by the 
 could be greater than for geometry.
 if this is the case there is perhaps a way to factorise the source key and 
 dramatically reduce disk usage.

The way to reduce the disk space for stuff imported in the future is to store 
that source once on the changeset instead.

Shaun


___
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-28 Per discussione Vladimir Vyskocil


 
  The larger part of cadastre data
 is just dumped into the data base never to be touched again by any mapper.

That's also wrong, the french community has developed some very powerful  tools 
like osmose.openstreetmap.fr which is used to automatically discover many 
errors from cadastre and others, it's used along the import process by many 
people to locate and fix many bugs, for example here is a search focused on 
some errors that we seek :

http://osmose.openstreetmap.fr/map/?zoom=12lat=45.22034lon=5.74928layers=B00FF0FFTitem=0,1040,3091level=1

Osmose is going worldwide for some analysis, so other community will benefit 
from this great tool.
There are also many go and return between data from cadastre and already in 
place data like roads and POI, the locations of each objects is used to improve 
the global accuracy (also with the help of other source : Bing,...). I 
discovered and fixed many roads and POI  with the help of the building 
footprints, in the process I try also to fix errors on cadastre that I can 
spot, some split buildings from time to time,...
Very often I can spot isolated buildings imported from cadastre and make search 
how to map the missing roads.
There are also IGN (french geomatic institute) landmarks which have been 
imported in the base, they are very accurately positioned reference physical 
points like the cross of church,... They are often used to precisely fix the 
location of the cadastre data if needed.

 
 no addresses or names or pois. It is rather ugly for rendering, there are
 no real buildings just unspecific building parts and way too much detail
 (small round edifices using up 40 nodes, what for?). You cannot do real
 statistics on them, there are just unspecific building parts...
 So essentially alomost every data user has to go through 25 million 
 buildings just to throw them away. It is not the end of the world,
 but it is mildly annoying.

I don't agree  the cadastre is ugly once rendered ! A rendered map like this 
for example, is in my opinion something more pleasant than a map with only a 
house once and there with large holes :

http://www.openstreetmap.org/?lat=43.70272lon=7.26654zoom=15layers=Q

This data is also beautifully used by the community behind 3D rendered map used 
in X-Plane flight simulator. 3D maps is something on the rise and detailed 
buildings are needed for this !

Regards,
Vlad.
___
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-28 Per discussione Richard Mann

While I would agree that the French data is huge, it _is_ pleasing to be
able to make maps where the density of building is observable, even if you
know nothing about the buildings. I'm not sure that every building in every
village is quite required, but it'll probably go that way eventually.

Is tracing better than importing for creating community and high-quality
tagged data? I'll guess we'll know after this little experiment.

I think we have perhaps discussed this long enough (translation: stop!)

Richard
___
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

2012-09-28 Per discussione Shaun McDonald

I know.

My thinking is that the source tag would be better placed on the changeset 
rather than polluting the whole db with source tags and source tags for each 
and every tag on each object which is starting to happen. You can then use the 
changeset info to synthesise the source info down to the tag and geometry.

Shaun

On 28 Sep 2012, at 08:47, Richard Mann richard.mann.westoxf...@gmail.com 
wrote:

 They're not allowed to. The licence requires them to put it on the object.
 
 On Fri, Sep 28, 2012 at 8:35 AM, Shaun McDonald sh...@shaunmcdonald.me.uk 
 wrote:
 
 On 28 Sep 2012, at 06:25, THEVENON Julien julien_theve...@yahoo.fr wrote:
 
 
 
 
 
 
  --
  Le jeu. 27 sept. 2012 20:18 HAEC, Sarah Hoffmann a écrit :
 
  This is the real problem for us.
 
  For the sake of completeness: planetwide there are currently
  152 million objects. Which means 1/6th of the planet consists of
  French buildings. Now, there is a real problem.
 
  Hi Sara,
 
  concerning problem of disk usage by french cadastre data do you have some 
  information?particulary do you know how is it stored in database?
  to be allowed to use cadastre data we have to add a source key which is 
  long about 40 characters to each way drawn thanks cadastre data due to 
  legal agreement with french office goverment providing cadastre data.
  do you know is this key is duplicatd for each building in the database or 
  if there is a smart storage? if not it would be interesting to know which 
  part of the size is for the key itself and which part is for the geometry. 
  I think that for buildings composed of one way and 4 nodes the space 
  required by the could be greater than for geometry.
  if this is the case there is perhaps a way to factorise the source key and 
  dramatically reduce disk usage.
 
 The way to reduce the disk space for stuff imported in the future is to store 
 that source once on the changeset instead.
 
 Shaun
 
 
 ___
 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


Vladimir Vyskocil wrote:

I don't agree  the cadastre is ugly once rendered ! A rendered map like this 
for example, is in my opinion something more pleasant than a map with only a 
house once and there with large holes :

http://www.openstreetmap.org/?lat=43.70272lon=7.26654zoom=15layers=Q

This data is also beautifully used by the community behind 3D rendered map used 
in X-Plane flight simulator. 3D maps is something on the rise and detailed 
buildings are needed for this !


There are some excellent examples of how mapping should be done all over the 
world. But I do hope we have shown that a large percentage of the data STILL 
needs a lot of work? At the end of the day this is more about education of 
mappers and how to get the best out of the material available. In hindsight I 
think there is some agreement that perhaps the data should not have been made 
'generally' available and that mappers were monitored a little more as to their 
use of the data? The horse has bolted now, so tools to clean up are now needed :(


In SOME areas the cadastre is ugly with several strange shaped blocks sort of 
grouped together vaguely around the location of a clean square building on the 
imagery ... that is what is irritating ...


--
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-28 Per discussione Vladimir Vyskocil


 
 There are some excellent examples of how mapping should be done all over the 
 world. But I do hope we have shown that a large percentage of the data STILL 
 needs a lot of work? At the end of the day this is more about education of 
 mappers and how to get the best out of the material available. In hindsight I 
 think there is some agreement that perhaps the data should not have been made 
 'generally' available and that mappers were monitored a little more as to 
 their use of the data? The horse has bolted now, so tools to clean up are now 
 needed :(
 
 In SOME areas the cadastre is ugly with several strange shaped blocks sort of 
 grouped together vaguely around the location of a clean square building on 
 the imagery ... that is what is irritating ...
 

Yes it's the actual situation, it is like some other big imports : TIGER, PGS 
coastline,..., it's a work in progress and the community is improving things, 
it's OpenStreetMap !
I think OSM is better with this data in than without.

Vlad.
___
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


Shaun McDonald wrote:

My thinking is that the source tag would be better placed on the changeset
rather than polluting the whole db with source tags and source tags for each and
every tag on each object which is starting to happen. You can then use the
changeset info to synthesise the source info down to the tag and geometry.


This will show my ignorance, but having tried to look at history on bits WHILE 
IN POTLATCH, I don't see how to do this? I don't think you can see who created 
an object?


I need to get back to JOSM and dig a bit deeper under the skin. I'd downloaded 
the shortcut crib sheet only to find it needs updating, but I need to spend a 
few more hours using it.


It *IS* important to identify the sourse of an object and what work has already 
been done on it, but I'm not sure what facilities are provided to do 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


Vladimir Vyskocil wrote:

There are some excellent examples of how mapping should be done all over the 
world. But I do hope we have shown that a large percentage of the data STILL 
needs a lot of work? At the end of the day this is more about education of 
mappers and how to get the best out of the material available. In hindsight I 
think there is some agreement that perhaps the data should not have been made 
'generally' available and that mappers were monitored a little more as to their 
use of the data? The horse has bolted now, so tools to clean up are now needed 
:(

In SOME areas the cadastre is ugly with several strange shaped blocks sort of 
grouped together vaguely around the location of a clean square building on the 
imagery ... that is what is irritating ...



Yes it's the actual situation, it is like some other big imports : TIGER, PGS 
coastline,..., it's a work in progress and the community is improving things, 
it's OpenStreetMap !
I think OSM is better with this data in than without.


Lessons have been learnt!
The 'Proposal for import guidelines' thread seems to have petered out?
Nothing seems to have changed :) but I get a feeling that people understand we 
are all just trying to help ... the British way is always to jump in with the 
size nine boots :(


We don't have the resources to do some of the 'big' things that need doing, so 
tools like http://osmose.openstreetmap.fr and the other checking tools are 
essential. However it's a bit like the 'apple' problem - just where do some of 
these tools work? Actually I think this is perhaps another point for the 
'layers' discussion? If there was a layer with the coverage of a tool then it 
could be used to identify where that tool is functional? Of cause I do get very 
concerned when I see 'Raw Data Editor' ... yes we have to trust people, but are 
the safeguards in place to cope with making that freely available? I work with 
XML data and I would still be nervous editing it without the right tools!


--
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-28 Per discussione Vincent Pottier


Le 28/09/2012 10:00, Lester Caine a écrit :


There are some excellent examples of how mapping should be done all 
over the world. But I do hope we have shown that a large percentage of 
the data STILL needs a lot of work? At the end of the day this is more 
about education of mappers and how to get the best out of the material 
available.

We all agree with you !
In hindsight I think there is some agreement that perhaps the data 
should not have been made 'generally' available and that mappers were 
monitored a little more as to their use of the data?

Yes, it one of the issues we are talking about on the talk-fr.

The horse has bolted now, so tools to clean up are now needed :(
Yes, at the beginning of the cadastre extraction, it has been a kind of 
fever.
And we have added warnings, explanations, tutorials, examples... (and we 
will add more)
But what is already in the database must be cleaned, and sometimes 
erased for better data.


In SOME areas the cadastre is ugly with several strange shaped blocks 
sort of grouped together vaguely around the location of a clean square 
building on the imagery ... that is what is irritating ...



Yes... we know, and are working to avoid it. Hard work !

But we are also proud of spots like
http://osm.org/go/erms5e9vS-- ( very hard to map !)
http://osm.org/go/0BImiuDol--
http://osm.org/go/0A4mSoqWJ-
--
FrViPofm

___
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

2012-09-28 Per discussione Philip Barnes

 I would prefer to keep the source tag with the object. Within a changeset I 
will often have some roads where source is GPS, have traced some buildings from 
bing, and added a few pub/shop names where source is survey

Phil
--

Sent from my Nokia N9



On 28/09/2012 8:55 Shaun McDonald wrote:

I know.


My thinking is that the source tag would be better placed on the changeset 
rather than polluting the whole db with source tags and source tags for each 
and every tag on each object which is starting to happen. You can then use the 
changeset info to synthesise the source info down to the tag and geometry.


Shaun


On 28 Sep 2012, at 08:47, Richard Mann richard.mann.westoxf...@gmail.com 
wrote:


They're not allowed to. The licence requires them to put it on the object.


On Fri, Sep 28, 2012 at 8:35 AM, Shaun McDonald sh...@shaunmcdonald.me.uk 
wrote:


On 28 Sep 2012, at 06:25, THEVENON Julien julien_theve...@yahoo.fr wrote:






 --
 Le jeu. 27 sept. 2012 20:18 HAEC, Sarah Hoffmann a écrit :

 This is the real problem for us.

 For the sake of completeness: planetwide there are currently
 152 million objects. Which means 1/6th of the planet consists of
 French buildings. Now, there is a real problem.

 Hi Sara,

 concerning problem of disk usage by french cadastre data do you have some 
 information?particulary do you know how is it stored in database?
 to be allowed to use cadastre data we have to add a source key which is long 
 about 40 characters to each way drawn thanks cadastre data due to legal 
 agreement with french office goverment providing cadastre data.
 do you know is this key is duplicatd for each building in the database or if 
 there is a smart storage? if not it would be interesting to know which part 
 of the size is for the key itself and which part is for the geometry. I think 
 that for buildings composed of one way and 4 nodes the space required by the 
 could be greater than for geometry.
 if this is the case there is perhaps a way to factorise the source key and 
 dramatically reduce disk usage.

The way to reduce the disk space for stuff imported in the future is to store 
that source once on the changeset instead.

Shaun


___
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] Réf.: Re: All you've ever wanted to know about the french cadastre

2012-09-28 Per discussione Philip Barnes

 Select way or node.
Click advanced.
Click way/node number.
Click more details.

Phil

--

Sent from my Nokia N9



On 28/09/2012 9:21 Lester Caine wrote:

Shaun McDonald wrote:
 My thinking is that the source tag would be better placed on the changeset
 rather than polluting the whole db with source tags and source tags for each 
 and
 every tag on each object which is starting to happen. You can then use the
 changeset info to synthesise the source info down to the tag and geometry.


This will show my ignorance, but having tried to look at history on bits WHILE
IN POTLATCH, I don't see how to do this? I don't think you can see who created
an object?


I need to get back to JOSM and dig a bit deeper under the skin. I'd downloaded
the shortcut crib sheet only to find it needs updating, but I need to spend a
few more hours using it.


It *IS* important to identify the sourse of an object and what work has already
been done on it, but I'm not sure what facilities are provided to do that?

--

Lester Caine - G8HFL

-

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

___

talk mailing list

talk@openstreetmap.org
http://lsces.co.uk/wiki/?page=contact



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

[OSM-talk] Tagging the source


Philip Barnes wrote:

  I would prefer to keep the source tag with the object. Within a changeset I
will often have some roads where source is GPS, have traced some buildings from
bing, and added a few pub/shop names where source is survey


I did put my hand up for a tag which is automatically applied for those of us 
who forget it ;) If I have a background layer up it automatically adds that tag 
to each object. If I'm selecting stuff from another source then that gets added. 
ALL of this could well be in one change set, and in fact I may switch between 
bing and OS layers simply to add other details, so a 'changeset' tag would not 
be suitable? But AUTOMATICALLY adding that data per object would mean that it 
does get added :)


Of cause I still object to a lot of this stuff being 'free format' ... a 
'layer_id' on these tags would be fine, and then the rest of the details are 
pulled up from 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] Réf.: Re: All you've ever wanted to know about the french cadastre

2012-09-28 Per discussione Richard Fairhurst

Philip Barnes wrote:
 Select way or node.
 Click advanced.
 Click way/node number.
 Click more details.

You don't even need the fourth step - the dialogue that appears when you
click the way/node id is the history.

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Ref-Re-All-you-ve-ever-wanted-to-know-about-the-french-cadastre-tp5727997p5728061.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] Tagging the source

2012-09-28 Per discussione Olivier Croquette


We don't have to choose between the 2 solutions (source on objects vs. source 
on change set).
It's possible to use a fall back system, something like :

For display :
If no source is available on an object, show the source of the last change set 
(if available)

For editing :
If no source is set on a change set, set it from the layers automatically.

It requires to modify the tools, but it should make every mapper happy.
 
___
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

2012-09-28 Per discussione SomeoneElse


Philip Barnes wrote:


 Select way or node.

Click advanced.

Click way/node number.

Click more details.




I think that the question was about changeset tags, in which case there 
are a couple more steps:


View History.
Choose the changeset to view information for, and click it.

Here's an example:
http://www.openstreetmap.org/browse/node/332695404

which has a source tag in this changeset:
http://www.openstreetmap.org/browse/changeset/13283634

Is there any easy way (in any editor with any plugin) of getting to this 
information - preferably a collated list of object / changeset tags?


Cheers,
Andy

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

Re: [OSM-talk] Tagging the source

2012-09-28 Per discussione Olivier Croquette

On Sep 28, 2012, at 1:56 PM, Olivier Croquette wrote:
 For display :
 If no source is available on an object, show the source of the last change 
 set (if available)

Actually that should read: show the sources of all change sets that created or 
modified the object.
The whole thing would need a better specification, but you get the idea.


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

Re: [OSM-talk] Tagging the source

2012-09-28 Per discussione Pieren

The tag 'source' on the changeset has some pros and cons:
Pros:
- size in database
- works only if the changeset comes from a single source
Cons:
- impossible to modify after changeset is closed
- attribution lost in data extracts, planet (separate file for changesets)
- doesn't allow more than one source per changeset
- rebuild one element history is not trivial (one API call per element
+ one per changeset multiplied by amount of versions)

The tag 'source' on elements:
Pros:
- support multiple sources during edit session
- attribution present in planet, extracts
- can be modified at any time
- retrieve one element history is easy (one API call)
Cons:
- size in database
- works fine only for small edit sessions (or imports)

Pieren

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

Re: [OSM-talk] Tagging the source


Pieren wrote:

- attribution lost in data extracts, planet (separate file for changesets)

ACTUALLY that is probably the killer?
Local working with truncated extracts SHOULD still report 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] Tagging the source

2012/9/28 Lester Caine les...@lsces.co.uk:
 I did put my hand up for a tag which is automatically applied for those of
 us who forget it ;) If I have a background layer up it automatically adds
 that tag to each object. If I'm selecting stuff from another source then
 that gets added. ALL of this could well be in one change set, and in fact I
 may switch between bing and OS layers simply to add other details, so a
 'changeset' tag would not be suitable? But AUTOMATICALLY adding that data
 per object would mean that it does get added :)


would you also opt for automatically removing these tags, e.g. when a
imagery layer is not activated and I move a node? Are you advocating
multivalue-source-lists if during the edit of an object the mapper
looked at several different images?

Honestly I am against a automatic mechanism to add tags, and I'd also
doubt that these tags would improve our data quality. I see a huge
overhead for really little benefit. Please think about it: what is the
benefit for other mappers to know that you traced over imagery
provider A's imagery and not that of B? Either you think it is correct
or you don't and you will improve it. In rare cases it might help you
to know whether this is based on outdated sources, but more often you
will already see this by the date of the edit. If the original source
is outdated and you know this from knowledge of the real situation you
will anyway improve the data.

You might be able to find areas which are based on outdated imagery to
resurvey. but you can find inactive areas just as well by looking at
the changes and dates of them. Even more, a comment like tracing from
bing aerial imagery doesn't even tell you which version of their
imagery you used (supposedly that around the time the edit was done,
but  you won't know in 2 years time which version or which date this
was, especially if it isn't your home region).

It mostly boils down to the simple question: does the mapper have
local knowledge or doesn't he. Did he recently survey the area?

That's not enough reason to stuff the db with mostly pointless
metadata like active imagery layers in the editor during  an edit. It
might be an idea to add this information automatically to changesets.

Btw.: does anybody on this list know if there is metadata for Bing
(for a given area) available (all based on the zoomlevel of course,
e.g. when did they survey, what was the resolution, where are the
seems of their imagery/survey, if the data is not from them, who
originally produced it, etc.)

cheers,
Martin

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

Re: [OSM-talk] Tagging the source

2012-09-28 Per discussione Richard Fairhurst

Lester Caine wrote:
 I did put my hand up for a tag which is automatically applied for those of 
 us who forget it ;) If I have a background layer up it automatically adds 
 that tag to each object.

In Potlatch you can simply press 'B' (for 'Background') to add the source=
tag for the current background imagery. It isn't added automatically, and
won't be, because it doesn't follow that you're necessarily tracing from a
background source just because it's displayed. You might be using a GPS
track, or your own local knowledge, or a vector background layer, or
whatever.

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Ref-Re-All-you-ve-ever-wanted-to-know-about-the-french-cadastre-tp5727997p5728076.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] Tagging the source

2012/9/28 Lester Caine les...@lsces.co.uk:
 Pieren wrote:

 - attribution lost in data extracts, planet (separate file for changesets)

 ACTUALLY that is probably the killer?
 Local working with truncated extracts SHOULD still report this type of data?


come on, I think you are overexxagerating this. Have a look how apple
handles attribution. They distribute a big blob and a separate (hard
to find) text file that says: contains data of a, b, c, , z, aa,
bb, cc, ..., zz, aaa, bbb, 
They don't even tell you where they use which data source. ;-)

I am not advocating to act accordingly, but saying that in every data
extract there must be full history (that is also attribution, to see
who edited the stuff), or changeset information, or source-tags , or a
source-tag on every single object might not be necessary. IMHO you
also retain attribution if you say: data from openstreetmap.org and on
openstreetmap.org you get all the necessary attribution info (e.g. in
the wiki, from the API with changeset-comments, etc.).

It was already in the past like this: someone who imports stuff with
osm2pgsql almost never retains this information (as long as he works
with the standard style file).

Cheers,
Martin

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

Re: [OSM-talk] Tagging the source

2012/9/28 Pieren pier...@gmail.com:
 The tag 'source' on elements:
 Pros:
 - support multiple sources during edit session
 - attribution present in planet, extracts
 - can be modified at any time
 - retrieve one element history is easy (one API call)
 Cons:
 - size in database
 - works fine only for small edit sessions (or imports)


there are other cons to source tags on objects:
when does the original contribution faint? This is a very difficult
question and every mapper who wants to improve an object which has a
source-tag gets the burden to care about. He might act wrong if he
doesn't retain the previous attribution (because he would be
obfuscating the source) and he might also act wrong if he keeps it
(because he would attribute an object to a source from which there is
probably few if anything left).

This makes pretty clear IMHO that source tags (in a project like osm,
where no data is stable) clearly don't belong to object, but to the
changes which create and modify those objects.

cheers,
Martin

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

Re: [OSM-talk] Tagging the source


Martin Koppenhoefer wrote:

It mostly boils down to the simple question: does the mapper have
local knowledge or doesn't he. Did he recently survey the area?
Reviewing my own 'processing', even where I have local knowledge I know I should 
be adding tags when I'm tracing, but when I'm in the flow THAT disrupts things. 
*I* would like something that flags that *I* pulled something from BING and 
something else from OS or where ever. Having to type some bloody long string 
each time means simply it does not happen :)

And yes part of the reason would be to flag a version of a data source!


That's not enough reason to stuff the db with mostly pointless
metadata like active imagery layers in the editor during  an edit. It
might be an idea to add this information automatically to changesets.
Which would not work for all the reasons already given. Only if you save on 
every change of configuration would that be accurate.


Perhaps all I am asking for is a 'default' set of tags that get added which I 
have to change manually, but the DATA certainly is important, and tags like 
'start_date' should be populated by default!


--
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] Tagging the source

2012/9/28 Lester Caine les...@lsces.co.uk:
 I have to change manually, but the DATA certainly is important, and tags
 like 'start_date' should be populated by default!


How would the editor (program)  know about the start_date? What are
you using this tag for?

cheers,
Martin

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

Re: [OSM-talk] Tagging the source


Martin Koppenhoefer wrote:

I am not advocating to act accordingly, but saying that in every data
extract there must be full history (that is also attribution, to see
who edited the stuff), or changeset information, or source-tags , or a
source-tag on every single object might not be necessary. IMHO you
also retain attribution if you say: data from openstreetmap.org and on
openstreetmap.org you get all the necessary attribution info (e.g. in
the wiki, from the API with changeset-comments, etc.).


Full history comes from the main database ... I was just advocating 'source' 
which adds to the information when one is looking at something and saying That 
is wrong! you may know straight away that it is a candidate to update.


--
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] Tagging the source

2012/9/28 Lester Caine les...@lsces.co.uk:
 Full history comes from the main database ... I was just advocating 'source'
 which adds to the information when one is looking at something and saying
 That is wrong! you may know straight away that it is a candidate to
 update.


yes, but often when something is wrong, the source-tag is as well ;-).
I have seen lots of source=PSG (coastline) where the data obviously
was far too detailed to be from PSG, it is because people hardly
remove those (meanwhile unvalid) source-tags.

cheers,
Martin

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

Re: [OSM-talk] Tagging the source

2012-09-28 Per discussione Kevin Peat

On 28 September 2012 15:13, Martin Koppenhoefer dieterdre...@gmail.com wrote:

 yes, but often when something is wrong, the source-tag is as well ;-).
 I have seen lots of source=PSG (coastline) where the data obviously
 was far too detailed to be from PSG, it is because people hardly
 remove those (meanwhile unvalid) source-tags.


Agree on that. There is lots of UK data with source=NPE or PGS that
has obviously been subsequently adjusted from Bing or elsewhere,
probably done this myself many times and forgotten to change the
source tag.

That's why I would prefer some automation. If I have Bing and an OS
based layer open and active in JOSM then I don't see a problem with
automatically adding those as sources to the changeset. Those tags
should then be visible when retrieving object history. Mappers could
still override that with source tags on the objects if required.

Kevin

___
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

2012-09-28 Per discussione Richard Fairhurst

Someoneelse wrote:
 Is there any easy way (in any editor with any plugin) of getting to 
 this information - preferably a collated list of object / changeset tags?

I've just done this in P2's history dialogue for 'comment' and 'source':

https://github.com/systemed/potlatch2/commit/f827b5368307dfd1a12f717e778ba91b46e242e3

If more changeset tags become relevant then I'll add those too.

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Ref-Re-All-you-ve-ever-wanted-to-know-about-the-french-cadastre-tp5727997p5728096.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] Remap-a-tron level 2 complete! Suggestions for level 3?

2012-09-28 Per discussione Martijn van Exel

On Thu, Sep 27, 2012 at 5:51 PM, Svavar Kjarrval sva...@kjarrval.is wrote:
 You could expand the remap-a-tron to include all areas on Earth. That
 might keep everybody busy for awhile. If it doesn't, it's a positive
 problem. :)

I would love to but I don't have the resources at this moment. Anyone
can fork / deploy the R-A-T for any region desired, of course. One
potential issue is that the R-A-T should not be used to copy data from
CC-BY-SA data to the new ODbL database. For that reason, I would
discourage folks from deploying where there's no HQ Bing data.

-- 
martijn van exel
http://oegeo.wordpress.com

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

Re: [OSM-talk] Tagging the source


Martin Koppenhoefer wrote:

I have to change manually, but the DATA certainly is important, and tags
like 'start_date' should be populated by default!


How would the editor (program)  know about the start_date? What are
you using this tag for?


Eventually a corrected date can be added ... we have sufficient historic mapping 
on line now, but NEW stuff going forward would at least be properly tagged from 
day one ... and in 10 years time you know that an object IS at least 10 years 
old ... it's just a matter of planning for the future. Again I'm just as lax at 
adding it, mainly because the editors don't present it!


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

2012-09-28 Per discussione Jukka Rahkonen

Philip Barnes phil at trigpoint.me.uk writes:

 
 
 
  I would prefer to keep the source tag with the object. Within a changeset I
will often have some roads where source is GPS, have traced some buildings from
bing, and added a few pub/shop names where source is survey

Changeset info can be obtained only from native OSM services. If someone
downloads shapefiles from Geofabrik or Cloudmade or OSM data in GML format
from my WFS server the changeset tags are a bit difficult to obtain. If 
such data contain osm_ids then it is possible to find the history of 
the objects from OSM services but I do not think it is compulsory to 
include osm_ids in WFS services or derived ODbL databases.

Users can delete or edit the object source tags but perhaps there are still
better possibilities that they remain in ODbL chain than the changeset 
source tags.

-Jukka Rahkonen-




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

[OSM-talk] About attribution to authors

2012-09-28 Per discussione Mike

Let's say, someone prepares data by recording it in the field, and then 
adds another value to data by sorting it out, fixing it and adding more 
information and details. And then he wants to include that data to 
OpenStreetMap.


What is mean of giving proper author attribution? All I can see is that 
OpenStreetMap is presented in copyright notes, not actual authors. The 
only way I found out to see author attribution is to download openstreet 
data and then search there.


I understand that making attribution to all authors at once is problem 
due to large number of involved authors, but there should be some way to 
give proper attribution to real persons who contribute to OpenStreetMap.




___
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

2012-09-28 Per discussione SomeoneElse


Richard Fairhurst wrote:

Someoneelse wrote:

Is there any easy way (in any editor with any plugin) of getting to
this information - preferably a collated list of object / changeset tags?

I've just done this in P2's history dialogue for 'comment' and 'source':

https://github.com/systemed/potlatch2/commit/f827b5368307dfd1a12f717e778ba91b46e242e3

If more changeset tags become relevant then I'll add those too.



Excellent - thanks.

Cheers,
Andy


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

Re: [OSM-talk] Tagging the source

2012-09-28 Per discussione Jérome Armau

The only real problem I see mentioned above is the overall size of the
database. It seems to me that we are somehow confusing problems caused by
the data itself with problems caused by its storage in the database.
Couldn't we simply work on a scheme that would normalize the database, so
that we'd have to store each piece of information (e.g. source value as
well as all the other tags) only once? I haven't worked much around the OSM
pgsql database schemas, so it may not be as easy as I'd hope.

Jerome

On Fri, Sep 28, 2012 at 7:39 AM, Kevin Peat k...@k3v.eu wrote:

 On 28 September 2012 15:13, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:
 
  yes, but often when something is wrong, the source-tag is as well ;-).
  I have seen lots of source=PSG (coastline) where the data obviously
  was far too detailed to be from PSG, it is because people hardly
  remove those (meanwhile unvalid) source-tags.
 

 Agree on that. There is lots of UK data with source=NPE or PGS that
 has obviously been subsequently adjusted from Bing or elsewhere,
 probably done this myself many times and forgotten to change the
 source tag.

 That's why I would prefer some automation. If I have Bing and an OS
 based layer open and active in JOSM then I don't see a problem with
 automatically adding those as sources to the changeset. Those tags
 should then be visible when retrieving object history. Mappers could
 still override that with source tags on the objects if required.

 Kevin

 ___
 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] About attribution to authors

2012-09-28 Per discussione Stephan Knauss


Hello Mike,

On 28.09.2012 18:16, Mike wrote:

What is mean of giving proper author attribution? All I can see is that
OpenStreetMap is presented in copyright notes, not actual authors. The
only way I found out to see author attribution is to download openstreet
data and then search there.


we recently switched the license from CC-BY-SA to ODbL. With this new 
license the single author no longer needs attribution.


In case you want to know the history of a single element there is no 
need to download the data set, you can query it on the web interface.

For example here for the node ID 1:

http://www.openstreetmap.org/browse/node/1/history

Stephan


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

Re: [OSM-talk] Street/POI Index from OSM data

2012-09-28 Per discussione Jukka Rahkonen

Alex Rollin alex.rollin at gmail.com writes:

 
 
 Hello,
 
 
 I am rather new to OSM data.  I've enjoyed doing edits on the map and 
now I'd
like to start learning how to arrange it on a printed page.
 
 I know there are lots and lots of tools out there.
 
 
 Could I receive a few recommendations for getting some text data out?
 
 I was thinking I might need to use Osmosis.  Some pointers would be
 very helpful.
 
 
 
 I would like to:
 
 Select a bounding box (I can produce lat/lon)
 Get a list of street names'
 Output a CSV file (or other text file)
 
 Select a bounding box (I can produce lat/lon)
 Get a list of POIs
 
 Output a CSV file (or other text file)
 
 For these I would also like to be able to get any other attributes/
keys like
description text or other things.

 Thank you to each of you for all the work you do!

Hi,

Sorry for a bit delayed answer but GDAL/OGR OSM driver developer had 
to do a couple of fixes for making this task to perform well.

So you can do all that with GDAL OSM driver and SQL query language. Output
can be despite CSV any other format that is supported by GDAL/OGR for 
writing.
http://www.gdal.org/ogr/drv_osm.html
http://www.gdal.org/ogr/ogr_formats.html

Install a very fresh GDAL development version, about rev. 24970 or higher.
For Windows you can get it from gisinternals
http://www.gisinternals.com/sdk/

You want to query streetname from osm lines and name and probably some other
attributes from osm points and from a limited area. It is possible but quite
slow to create such CSV file directly from OSM data file that can be in
osm-xml or pbf format with following command

ogr2ogr -f CSV streets.csv finland.osm.pbf -sql select distinct 
name from lines where highway is not null order by name 
-spat 24.821 60.123 25.259 60.317

However, it is faster, especially if you want to do more queries, 
to convert OSM data first into Spatialite database. Here is a quite 
optimised command to use as a template

ogr2ogr -f SQLite -dsco spatialite=yes finland.sqlite finland.osm.pbf
 --config SQLITE_SYNCHRONOUS OFF --config OSM_COMPRESS_NODES YES
 -progress

This conversion takes a few minutes with 130 MB finland.osm.pbf file. 
Then you can repeat the first streetname search and it will be pretty fast

ogr2ogr -f CSV streets.csv finland.sqlite -sql select distinct name 
from lines where highway is not null order by name 
-spat 24.821 60.123 25.259 60.317

The poi file can be created in a similar way. Let's say you want to 
get all the amenities and names for those. The command is

ogr2ogr -f CSV poi.csv finland.sqlite -sql select name, amenity 
from points where amenity is not null order by amenity
-spat 24.821 60.123 25.259 60.317

Note 1. Read the OSM driver manual page. The second command does not 
work before editing the defauld osmconf.ini file so that amenity 
is included in the points layer attributes.

Note 2. There is a little bug in ogr2ogr CSV driver that may prevent 
creating a new csv file if there is already another CSV file with an 
uncommon structure in the same directory. The one-column CSV file that 
was created in the first example has such a structure. Delete the file 
or rename it with another extension before running the second example.

Regards,

-Jukka Rahkonen-




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

Re: [OSM-talk] [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?

2012-09-28 Per discussione Nathan Oliver

A few things that I'm still encountering that might be easy to detect:
*One-way streets that aren't connected to anything at one end.
*Motorways or Trunk that are dead-ends (probably could be extended to
*-link, and maybe to Primary/Secondary, but I'm not sure how far you
can go before it becomes something that needs a survey).

On a related note, maybe implement a way to flag something as needing
a local survey and create a new bug in OpenStreetBugs or another bug
tracker? (Or is this there already and I have missed it?)

You might check some of the things KeepRight http://keepright.at/
identifies, or possibly get their error dump and work from it.



On Thu, Sep 27, 2012 at 6:29 PM, Martijn van Exel m...@rtijn.org wrote:

 Hi all,

 It looks like we're done with level 2 of the remap-a-tron!
 (lima.schaaltreinen.nl/remap)
 Thanks so much for helping out! You were so fast that I did not get a
 chance to prepare the next level so now you  get to have your say:
 what should be the next error to fix with the remap-a-tron?
 Considerations should be that 1) ideally they should be easy to spot
 on the mapnik map or by comparing mapnik and bing and 2) they should
 be easy fixes.

 Let me hear what you want to see (and ideally send a pull request ;)
 https://github.com/mvexel/remapatron)

 (stats for level 1:
 http://lima.schaaltreinen.nl/tmp/remapatron_level1.png and level 2:
 http://lima.schaaltreinen.nl/tmp/remapatron_level2.png)

 --
 martijn van exel
 http://oegeo.wordpress.com

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

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

Re: [OSM-talk] About attribution to authors

2012/9/28 Mike mike.cuttl...@gmail.com:
 I understand that making attribution to all authors at once is problem due
 to large number of involved authors, but there should be some way to give
 proper attribution to real persons who contribute to OpenStreetMap.


We had this attribution at least in one of the two official
renderings some years ago (I think it was Osmarender, but I am not
sure IIRR). In very high zoom levels the streets had a notice about
the username of the last editor. I think this was not continued
because it might have incentivated some people of doing trivial edits
just to have their name shown up.

cheers,
Martin

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

Re: [OSM-talk-nl] Hosting of rackspace gezocht voor yournavigation.org

2012-09-28 Per discussione Floris Looijesteijn

Is het ook een optie om het in het normale OSM serverpark te hangen of wil
je het graag zelf in beheer houden?

En indien dat laatste, heb je enig idee van de kosten voor een jaar hosting?
Misschien kunnen we een crowdfunding actie opzetten.

Groet,
Floris

2012/9/28 Lambertus o...@na1400.info

Voor de routing backend van yournavigation.org ben ik op zoek naar
sponsoring van hosting of rackspace.

Gezocht:
Een compleet hosting aanbod bestaande uit een dedicated server met
minimaal 16 GB ram en 10 GB traffic per maand.

Alternatief heb ik reeds een aanbieding gekregen van 2e-hands servers die
bestaat uit twee 1U of 2U servers HP DL360 G5, KVM over IP en op afstand
bedienbare PDU. Hiervoor ben ik op zoek naar rackspace sponsoring.

Ben je geintresseerd in het ondersteunen van dit unieke opensource project
neem dan contact met mij op. Over de voorwaarden van hosting of rackspace
valt uiteraard te praten.

Achtergrond:
YOURS (yournavigation.org) is een opensource routing applicatie op basis
van OpenStreetMap data. YOURS was in 2008 de eerste applicatie die
wereldwijde navigatie gebaseerd op OpenStreetMap data mogelijk maakte.

Tientallen web- en mobiele applicaties gebruiken yournavigation.org voor
routering en op dit moment worden dagelijks 80.000 tot 200.000 route
berekeningen uitgevoerd.

De website yournavigation.org zelf wordt sinds het begin gehost door
Oxilion in Enschede en dat blijft in principe ook zo. Maar de routing
backend voor yournavigation.org wordt op dit moment nog gesponsord door
een hosting bedrijf uit Amerika waarvan de zoon van de eigenaar een
afstudeerproject gedaan heeft met YOURS. Het sponsoring 'contract' van
loopt af wat de reden is dat ik op zoek ben naar een alternatief.

Meer informatie over de opensource navigatie applicatie YOURS (en de demo
site yournavigation.org) vind je hier: http://wiki.openstreetmap.org/**
wiki/YOURS http://wiki.openstreetmap.org/wiki/YOURS

__**_
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] Hosting of rackspace gezocht voor yournavigation.org

2012-09-28 Per discussione Frank Heinen

Hoi,

Kosten zijn vrij simpel te berekenen. Als je een cheap-ass hoster neemt als
OVH, die bieden hosting aan voor een leuke server voor een ~ € 1500 euro
per jaar
http://www.ovh.nl/dedicated_servers/eg_hybrid.xml of
http://www.ovh.nl/dedicated_servers/eg_ssd_max.xml

Dat draait goed, ik spreek uit ervaring.

Leaseweb colo voor 2U is 600 per jaar (
http://www.leaseweb.com/nl/colocatie/rackspace ).

Groet,

Frank

2012/9/28 Floris Looijesteijn o...@floris.nu

Is het ook een optie om het in het normale OSM serverpark te hangen of wil
je het graag zelf in beheer houden?

En indien dat laatste, heb je enig idee van de kosten voor een jaar
hosting?
Misschien kunnen we een crowdfunding actie opzetten.

Groet,
Floris

2012/9/28 Lambertus o...@na1400.info

Voor de routing backend van yournavigation.org ben ik op zoek naar
sponsoring van hosting of rackspace.

Gezocht:
Een compleet hosting aanbod bestaande uit een dedicated server met
minimaal 16 GB ram en 10 GB traffic per maand.

Ben je geintresseerd in het ondersteunen van dit unieke opensource
project neem dan contact met mij op. Over de voorwaarden van hosting of
rackspace valt uiteraard te praten.

Tientallen web- en mobiele applicaties gebruiken yournavigation.org voor
routering en op dit moment worden dagelijks 80.000 tot 200.000 route
berekeningen uitgevoerd.

Meer informatie over de opensource navigatie applicatie YOURS (en de demo
site yournavigation.org) vind je hier: http://wiki.openstreetmap.org/**
wiki/YOURS http://wiki.openstreetmap.org/wiki/YOURS

__**_
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] Hosting of rackspace gezocht voor yournavigation.org

2012-09-28 Per discussione Pander

Rackspace voor colocatie is relatief duur t.o.v. Een virtual server huren. De
meeste prijzen zijn op basis van stroomverbruik en met meerdere virtual hosts
op dezelfde (flinke) server is sat de goedkoopste oplossing. Bovendien is een
virtual image makkelijker te verhuizen.

Frank Heinen f.heinen...@gmail.com wrote:

Hoi,

Kosten zijn vrij simpel te berekenen. Als je een cheap-ass hoster neemt
als
OVH, die bieden hosting aan voor een leuke server voor een ~ € 1500
euro
per jaar
http://www.ovh.nl/dedicated_servers/eg_hybrid.xml of
http://www.ovh.nl/dedicated_servers/eg_ssd_max.xml

Dat draait goed, ik spreek uit ervaring.

Leaseweb colo voor 2U is 600 per jaar (
http://www.leaseweb.com/nl/colocatie/rackspace ).

Groet,

Frank

2012/9/28 Floris Looijesteijn o...@floris.nu

Is het ook een optie om het in het normale OSM serverpark te hangen
of wil
je het graag zelf in beheer houden?

En indien dat laatste, heb je enig idee van de kosten voor een jaar
hosting?
Misschien kunnen we een crowdfunding actie opzetten.

Groet,
Floris

2012/9/28 Lambertus o...@na1400.info

Voor de routing backend van yournavigation.org ben ik op zoek naar
sponsoring van hosting of rackspace.

Gezocht:
Een compleet hosting aanbod bestaande uit een dedicated server met
minimaal 16 GB ram en 10 GB traffic per maand.

Alternatief heb ik reeds een aanbieding gekregen van 2e-hands
servers die
bestaat uit twee 1U of 2U servers HP DL360 G5, KVM over IP en op
afstand
bedienbare PDU. Hiervoor ben ik op zoek naar rackspace sponsoring.

Ben je geintresseerd in het ondersteunen van dit unieke opensource
project neem dan contact met mij op. Over de voorwaarden van hosting
of
rackspace valt uiteraard te praten.

Achtergrond:
YOURS (yournavigation.org) is een opensource routing applicatie op
basis
van OpenStreetMap data. YOURS was in 2008 de eerste applicatie die
wereldwijde navigatie gebaseerd op OpenStreetMap data mogelijk
maakte.

Tientallen web- en mobiele applicaties gebruiken yournavigation.org
voor
routering en op dit moment worden dagelijks 80.000 tot 200.000 route
berekeningen uitgevoerd.

De website yournavigation.org zelf wordt sinds het begin gehost door
Oxilion in Enschede en dat blijft in principe ook zo. Maar de
routing
backend voor yournavigation.org wordt op dit moment nog gesponsord
door
een hosting bedrijf uit Amerika waarvan de zoon van de eigenaar een
afstudeerproject gedaan heeft met YOURS. Het sponsoring 'contract'
van
loopt af wat de reden is dat ik op zoek ben naar een alternatief.

Meer informatie over de opensource navigatie applicatie YOURS (en de
demo
site yournavigation.org) vind je hier:
http://wiki.openstreetmap.org/**
wiki/YOURS http://wiki.openstreetmap.org/wiki/YOURS

__**_
Talk-nl mailing list
Talk-nl@openstreetmap.org

http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing

2012-09-28 Per discussione Cartinus

Hallo,

Vervelend dat ondanks dit PostNL en Cendris nog steeds mensen/bedrijven
aanvallen die wat doen met de postcodes uit de BAG.

Zie de brief onderaan de volgende pagina:
http://www.postcodeatlas.nl/pages/postcodebestand.html

On 09/18/2012 05:39 PM, Martijn van Exel wrote:
 Hi talk-nl,
 
 onderstaande ontving ik als afnemer van de BAG. Misschien interessant
 voor wie wat met BAG data wil doen in het kader van OSM? (Ik heb geen
 idee of die discussie nog wordt gevoerd.)
 
 Groet,
 Martijn
 
 
 -- Forwarded message --
 From:  b...@kadaster.nl
 Date: 2012/9/18
 Subject: Gebruikersvoorwaarden BAG niet meer van toepassing
 To: b...@kadaster.nl
 
 
 Geachte heer, mevrouw,
 
 
 
 Het ministerie van IenM heeft een open databeleid. Daarom vindt het
 ministerie het belangrijk dat wij de gegevens uit de Landelijke
 Voorziening Basisregistraties Adressen en Gebouwen (BAG LV) zonder
 voorwaarden leveren aan de gebruikers. Toen u zich aanmeldde voor het
 gebruik van gegevens uit de BAG LV, hebt u bepaalde voorwaarden
 geaccepteerd. Die vervallen bij deze.
 
 
 
 Wij vertrouwen erop u hiermee voldoende te hebben geïnformeerd.
 
 
 
 Met vriendelijk groet,
 
 
 
 Kadaster.
 
 W: http://kadaster.nl/bag
 E: b...@kadaster.nl
 T: 088-1833400
 
 
 
 
 

-- 
---
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] Hosting of rackspace gezocht voor yournavigation.org

2012-09-28 Per discussione Cartinus

Crowdfunding lijkt mij inderdaad ook meer continue kopzorgen geven als
een concrete sponsor vinden. Als je er echter toch toe besluit, kijk dan
eens bij de veiling van Hetzner [1]. De goedkoopste machine met minimaal
16GB RAM is op dit moment €68,-/maand.

https://robot.your-server.de/order/market

On 09/28/2012 11:09 PM, Lambertus wrote:
 Oxilion doet al heel veel voor de Nederlandse OSM community en ik wil
 hun eigenlijk niet (direct) lastig vallen met zo'n specifieke vraag voor
 deze niet-core OSM activiteit. Vandaar dat ik alternatieven zoek. Een
 beetje rondsurfend leert dat het huren van een dedicated server met de
 benodigde specs al snel meer dan 200 Euro/maand kost. 1U of 2U rackspace
 huren (0,5 Ampere) kost ook al snel een 60 Euro per maand. Crowdfunding
 kan natuurlijk maar ik het het gevoel dat dit weinig stabiliteit bied,
 maar daar kan ik me in vergissen natuurlijk.
 
 Er lopen op dit moment een paar buitenlandse contacten waarvan de
 2e-hands server donatie momenteel de meest concrete is, vandaar dat ik
 ook rondkijk of er rackspace sponsoring mogelijk is.
 
 
 On 28-09-12 16:29, Floris Looijesteijn wrote:
 Is het ook een optie om het in het normale OSM serverpark te hangen of
 wil je het graag zelf in beheer houden?

 En indien dat laatste, heb je enig idee van de kosten voor een jaar
 hosting?
 Misschien kunnen we een crowdfunding actie opzetten.

 Groet,
 Floris

 2012/9/28 Lambertus o...@na1400.info mailto:o...@na1400.info

 Voor de routing backend van yournavigation.org
 http://yournavigation.org ben ik op zoek naar sponsoring van
 hosting of rackspace.

 Gezocht:
 Een compleet hosting aanbod bestaande uit een dedicated server met
 minimaal 16 GB ram en 10 GB traffic per maand.

 Alternatief heb ik reeds een aanbieding gekregen van 2e-hands
 servers die bestaat uit twee 1U of 2U servers HP DL360 G5, KVM
 over IP en op afstand bedienbare PDU. Hiervoor ben ik op zoek naar
 rackspace sponsoring.

 Ben je geintresseerd in het ondersteunen van dit unieke opensource
 project neem dan contact met mij op. Over de voorwaarden van
 hosting of rackspace valt uiteraard te praten.

 Achtergrond:
 YOURS (yournavigation.org http://yournavigation.org) is een
 opensource routing applicatie op basis van OpenStreetMap data.
 YOURS was in 2008 de eerste applicatie die wereldwijde navigatie
 gebaseerd op OpenStreetMap data mogelijk maakte.

 Tientallen web- en mobiele applicaties gebruiken
 yournavigation.org http://yournavigation.org voor routering en
 op dit moment worden dagelijks 80.000 tot 200.000 route
 berekeningen uitgevoerd.

 De website yournavigation.org http://yournavigation.org zelf
 wordt sinds het begin gehost door Oxilion in Enschede en dat
 blijft in principe ook zo. Maar de routing backend voor
 yournavigation.org http://yournavigation.org wordt op dit moment
 nog gesponsord door een hosting bedrijf uit Amerika waarvan de
 zoon van de eigenaar een afstudeerproject gedaan heeft met YOURS.
 Het sponsoring 'contract' van loopt af wat de reden is dat ik op
 zoek ben naar een alternatief.

 Meer informatie over de opensource navigatie applicatie YOURS (en
 de demo site yournavigation.org http://yournavigation.org) vind
 je hier: http://wiki.openstreetmap.org/wiki/YOURS


 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org mailto: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-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-nl
 

-- 
---
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] Hosting of rackspace gezocht voor yournavigation.org

2012-09-28 Per discussione Lambertus

Bij de huidige sponsoring draaide de VM eerst op een quadcore 1.6 GHz 
met 16 GB shared ram en dat het ram geshared werd was goed te merken. 
Alsof de data van een harddisk moest komen i.p.v. gebufferd uit ram. 
Niet vooruit te branden. Sinds de VM 16 GB dedicated ram heeft is de 
performance een stuk beter geworden. In zo'n configuratie is een VPS ook 
een optie. Punt is, de route calculatie hangt vooral van de snelheid en 
buffering van de route database in het geheugen af. De snelheid van de 
CPU is van secundair belang. Je kunt wel de snelste Xeon in een server 
hebben maar als die op harddisk I/O staat te wachten dan is die net zo 
snel als een Atom, bij wijze van spreken.
Veel geheugen is daarom noodzakelijk, hoe dat uiteindelijk geregeld is 
maakt me niet zoveel uit.


On 28-09-12 20:33, Pander wrote:

Rackspace voor colocatie is relatief duur t.o.v. Een virtual server huren. De 
meeste prijzen zijn op basis van stroomverbruik en met meerdere virtual hosts 
op dezelfde (flinke) server is sat de goedkoopste oplossing. Bovendien is een 
virtual image makkelijker te verhuizen.

Frank Heinen f.heinen...@gmail.com wrote:



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

[talk-au] Aus remapping task server

2012-09-28 Per discussione Chris Barham

Hi,
Has anyone got the tech smarts/resources to stand up a remap-a-tron for
Australia?  It seems to have been rather a success in the USA, and could
help us direct our remapping efforts:
demo: http://lima.schaaltreinen.nl/remap/
Source: https://github.com/mvexel/remapatron

Might be a good time to do it as the remaining rebuild jobs for Australia
seem to be nearing completion:
Brisbane: http://rebuild.poole.ch/job/29
Hobart: http://rebuild.poole.ch/job/33

So I imagine some people will be looking for more tasks soon :-)

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

Re: [talk-au] Aus remapping task server

2012-09-28 Per discussione Simon Poole


Am 28.09.2012 18:07, schrieb Chris Barham:

..

Might be a good time to do it as the remaining rebuild jobs for 
Australia seem to be nearing completion:

Brisbane: http://rebuild.poole.ch/job/29
Hobart: http://rebuild.poole.ch/job/33

So I imagine some people will be looking for more tasks soon :-)

There is no issue with adding further jobs, but I need either somebody 
to step forward and to add additional regions for AUS or at least on 
some input on where additional jobs would make sense.


Simon

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

[Talk-de] Die ueblichen Orte zum Salsatanzen

2012-09-28 Per discussione Philipp Klaus Krause

Guten Abend,

ich hatte vor das hier

amenity=bar
dance:style=salsa,bachata,merengue
dance:teaching=yes

fuer den recht haeufigen Fall einer Bar mit Tanzflaeche, in der
haupsaechlich Salsa, Bachata und Merengue getanzt wird, und es am
frueheren Abend einen ein- oder zweistuendigen Tanzkurs gibt zu
verwenden (fuer etwas gropeszere dann amenity=nightclub statt bar).
Wuerde etwas dagegen sprechen und wen ja, was sollte ich stattdessen
verwenden?

Philipp

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

Re: [Talk-de] Die ueblichen Orte zum Salsatanzen

Am 28. September 2012 09:31 schrieb Philipp Klaus Krause p...@spth.de:
 ich hatte vor das hier

 amenity=bar
 dance:style=salsa,bachata,merengue
 dance:teaching=yes

 fuer den recht haeufigen Fall einer Bar mit Tanzflaeche, in der
 haupsaechlich Salsa, Bachata und Merengue getanzt wird, und es am
 frueheren Abend einen ein- oder zweistuendigen Tanzkurs gibt zu
 verwenden (fuer etwas gropeszere dann amenity=nightclub statt bar).
 Wuerde etwas dagegen sprechen und wen ja, was sollte ich stattdessen
 verwenden?


Entspricht ungefähr dem, was das Wiki auch vorschlägt:
http://wiki.openstreetmap.org/wiki/Tag:leisure%3Ddance
Ist allerdings alles noch nicht übermäßig in Gebrauch:
http://taginfo.openstreetmap.org/search?q=dance

Wenn Werte zu einem Schlüssel eingetragen werden so ist die allgemeine
Empfehlung, das mit einem Semikolon und nicht mit einem Komma trennen,
also besser salsa;bachata;merengue
Trotzdem werden diese Multivalues sehr selten ausgewertet, wenn überhaupt.

Gruß Martin

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

Hallo Sven!

Am 27. September 2012 16:51 schrieb Sven Geggus li...@fuchsschwanzdomain.de
:

 Andreas Trawoeger atra...@kartenwerkstatt.at wrote:

 Jetzt muss ich schon mal doof fragen warum Du nicht einfach gefragt hast?

 Ich habe in meinem blog http://blog.gegg.us schon oft was über solche
 Sachen
 geschrieben, ich habe wms.openstreetmap.de eingerichtet und 2010 auf der
 FOSSGIS einen Vortrag über dieses Thema gehalten:

 http://www.fossgis.de/konferenz/2010/attachments/71_osm-datenaufbereitung-fossgis-2010.pdf

 Mich nach dem ein oder anderen zu fragen hätte Dir sicher eine Menge Arbeit
 erspart :(



Da muss ich kurz zurücklästern ;-)

Einen einzelnen Layer wie bei wms.openstreetmap.de von der lokalen
Landesprojektion und der jeweiligen Bounding Box nach Web Mercator zu
transformieren, ist keine große Hexerei. Die nicht trivialen Probleme
treten auf, sobald man einen globalen Layer generiert, bei dem Bildkacheln
Bounding Boxen haben können, die transformiert in die jeweilige
Landesprojektion zu ungültigen Werten führen. Was vor allem bei niedrigen
Zoomstufen, wo eine einzelne Bildkachel großflächige Bereiche abbildet
regelmäßig der Fall sein kann.

Zusätzlich verhalten sich die jeweiligen Landes-GIS Systeme bei solchen
Anfragen extrem unterschiedlich und liefern je nach Implementation entweder
leere Bildkacheln zurück (z.B. bei geodaten.bayern.de) oder antworten mit
WMS Exception Errors (z.B, bei data.vorarlberg.gv.at).


 Und wo wir gerade bei GK sind. Hast Du die Beta2007 Korrekturdatei
 verwendet?



Die Luftbilddaten inkl. Bayern sind derzeit deckungsgleich mit den Daten
von Geoimage.at die in Österreich die offizielle Referenz darstellen..

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

Hallo Simon!

Am 27. September 2012 19:11 schrieb Simon Poole si...@poole.ch:


 Generell ist aber die Idee nicht schlecht und ausbaufähig (es gibt nur
 schon im DACH Raum viel mehr Quellen als was du schon integriert hast).
 Allerdings sind viele davon nicht direkt für einen Webdienst allgemeiner
 Natur (also unabhängig von OSM) freigegeben, man müsste also überall
 nochmals nachfragen, dass wäre aber sicher möglich.


Das steht und fällt mit den Lizenzbedingungen unter denen die Bilddaten
verfügbar sind.

Es gibt erfreulich viele Quellen, deren Lizenzbedingungen ein Abzeichnen
durch OSM erlauben. Gleichzeitig verbieten aber sehr viele Quellen in ihren
Lizenzbedingungen eine Weitergabe  oder Caching der zur Verfügung
gestellten Bilddaten. Weshalb ich diese Datenquellen aus rechtlichen
Gründen derzeit nicht einbinden kann.

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione aighes


Hallo,
wenn ich es als Laie richtig verstehe, ist der Vorteil für mich, dass 
ich automatisch das höchstauflösende Luftbild angezeigt bekomme und 
nicht hin und her schalten muss, richtig?


Henning


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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione Sven Geggus

Andreas Trawoeger atra...@kartenwerkstatt.at wrote:

 Einen einzelnen Layer wie bei wms.openstreetmap.de von der lokalen
 Landesprojektion und der jeweiligen Bounding Box nach Web Mercator zu
 transformieren, ist keine große Hexerei. 

Na ja, das mit dem BETA2007 war so einfach nun auch wieder nicht.

 Die nicht trivialen Probleme treten auf, sobald man einen globalen Layer
 generiert, bei dem Bildkacheln Bounding Boxen haben können, die
 transformiert in die jeweilige Landesprojektion zu ungültigen Werten
 führen.

Das ist doch nur der Fall wenn man auserhalb des Abdeckungsbereiches ist
oder? Beim Mapserver kann man jedenfalls auch wenn man ihn als Proxy
verwendet eine Bounding-Box angeben für die der Layer gültig ist.

Sven

-- 
Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär,
und - dank Knut - insbesondere der Eisbär, deutlich größerer
Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/)
/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

2012-09-28 Per discussione Manuel Reimer

Stephan Wolff s.wolff at web.de writes:
 In vielen andere Fällen ist das taggen für den Renderer weit verbreitet:
 - natural=beach für Bunker auf Golfplätzen

Autsch. Ganz übel. Das da noch niemand wenigstens versucht hat, etwas
alternatives in den Mapnik-Stil zu bekommen. Wird denn natural=sand gerendert?
Also wenn sowas in meiner Nähe wäre, würde ich das gegen etwas weniger abwegiges
austauschen...

Gruß

Manuel


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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione Andreas Labres

Hallo Sven!

Das Tolle von Andreas' Umsetzung ist IMO das Vereinigen verschiedener Quellen,
das funktioniert für den Benutzer automatisch (kein URL-Raussuchen mehr...) und
das kenne ich sonst von niemandem.

(und außerdem sein Landungs-Video... ;)

/al

___
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-28 Per discussione Martin Vonwald

Am 28. September 2012 11:59 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Stephan Wolff s.wolff at web.de writes:
 In vielen andere Fällen ist das taggen für den Renderer weit verbreitet:
 - natural=beach für Bunker auf Golfplätzen
 Autsch. Ganz übel. Das da noch niemand wenigstens versucht hat, etwas
 alternatives in den Mapnik-Stil zu bekommen. Wird denn natural=sand 
 gerendert?

natural=sand wird gerendert. Das habe ich auch für Bunker verwendet,
zusammen mit golf=bunker [1]. Allerdings wäre mir der Tag
landcover=sand deutlich lieber, aber bis in der Hinsicht was
weitergeht, vergehen wohl noch Jahre ;-)

vg,
Martin

[1] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Golf_course

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione Jochen Topf

On Fri, Sep 28, 2012 at 12:06:12PM +0200, Andreas Labres wrote:
 (und außerdem sein Landungs-Video... ;)

Ja, das ist ziemlich cool! Wo kommt der Soundtrack her?

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] Etwas Ratlos -- taggen für den Renderer

Am 28. September 2012 12:09 schrieb Martin Vonwald imagic@gmail.com:
 natural=sand wird gerendert. Das habe ich auch für Bunker verwendet,
 zusammen mit golf=bunker [1]. Allerdings wäre mir der Tag
 landcover=sand deutlich lieber, aber bis in der Hinsicht was
 weitergeht, vergehen wohl noch Jahre ;-)


hast Du denn ein landcover=sand auch ergänzt? Weil, wenn niemand das
taggt, wird es auch nicht gerendert werden ;-)
natural=sand finde ich genauso AUTSCH wie natural=beach für einen
Golfplatz, als tag grundsätzlich sogar deutlich mehr, weil egal wie
man natural interpretiert (manche sagen ja, das sei für alles
Natürliche, meine eigene Interpretation ist eher geographisches
Feature (also so was wie Strand, Bucht, Quelle, Tal, Berg, Pass,
Höhle, Wüste, etc.)), sand passt da als Wert eigentlich nicht rein.
Schade, dass so was von den Renderern aktiv unterstützt wird.

Gruß Martin

___
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-28 Per discussione Martin Vonwald

Am 28. September 2012 13:32 schrieb Martin Koppenhoefer
dieterdre...@gmail.com:
 Am 28. September 2012 12:09 schrieb Martin Vonwald imagic@gmail.com:
 natural=sand wird gerendert. Das habe ich auch für Bunker verwendet,
 zusammen mit golf=bunker [1]. Allerdings wäre mir der Tag
 landcover=sand deutlich lieber, aber bis in der Hinsicht was
 weitergeht, vergehen wohl noch Jahre ;-)

 hast Du denn ein landcover=sand auch ergänzt? Weil, wenn niemand das
 taggt, wird es auch nicht gerendert werden ;-)

Nein, denn als ich den Golfplatz vor ein paar Jahren eingetragen habe,
habe ich mir über landcover noch keine Gedanken gemacht ;-) Heute
würde ich das natürlich verwenden.

 natural=sand finde ich genauso AUTSCH wie natural=beach für einen
 Golfplatz, als tag grundsätzlich sogar deutlich mehr, weil egal wie
 man natural interpretiert (manche sagen ja, das sei für alles
 Natürliche, meine eigene Interpretation ist eher geographisches
 Feature (also so was wie Strand, Bucht, Quelle, Tal, Berg, Pass,
 Höhle, Wüste, etc.)), sand passt da als Wert eigentlich nicht rein.
 Schade, dass so was von den Renderern aktiv unterstützt wird.

Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der
natural-Werte. Ist aber halt das, was dem ganzen am nächsten kommt,
daher habe ich das damals verwendet. :-/ Meine Meinung [1] zu natural
 Co glaube ich kennst du ja schon. Heute würde ich wahrscheinlich
einfach landcover=sand verwenden und darauf warten, dass es jemand
korrigiert ;-)

vg,
Martin


[1] http://wiki.openstreetmap.org/wiki/User:Imagic/landcover

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

Am 28. September 2012 10:58 schrieb aighes o...@aighes.de:


 wenn ich es als Laie richtig verstehe, ist der Vorteil für mich, dass ich
 automatisch das höchstauflösende Luftbild angezeigt bekomme und nicht hin
 und her schalten muss, richtig?


Langfristiges Ziel ist es zwei Dinge zu erreichen:
- Ein einheitlichen kombinierten Luftbild Layer anzubieten, der das
Umschalten zwischen den einzelnen Datenquellen nicht mehr notwendig macht.
- Den Layer in einer einheitlichen und korrekten Projektion anzubieten

Datenquellen wie Yahoo oder Bing Maps sind nicht immer 100%
orthoreferenziert weshalb die darauf basierenden OSM Daten gegenüber den
amtlichen Daten einen mehr oder weniger starken Versatz aufweisen.

Die Fehler sind in den meisten Fällen ziemlich minimal, können aber
Probleme machen, sobald offizell referenzierte Geodaten zur Verfügung
stehen und mit OSM Daten kombiniert werden (weil z.B. eine Mülltonne nicht
neben, sondern auf einer Straße steht).

Was wiederum die Übernahme der zunehmend von Behördenseite zur Verfügung
gestellten frei verfügbaren Geodaten nach OSM verkompliziert. Weil ein 1:1
Import in OSM ein ziemliches Chaos anrichten würde.

cu andreas
___
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 28. September 2012 13:39 schrieb Martin Vonwald imagic@gmail.com:
 Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der
 natural-Werte.


naja, das würde ich so gar nicht mal unterschreiben, die Hauptwerte
(also die auf der natural-key-Seite) passen eigentlich weit
überwiegend zur Geographie-Feature-Definition, das sind nur ganz
wenige wie mud und sand, die da aus der Reihe scheren.

 Heute würde ich wahrscheinlich
 einfach landcover=sand verwenden und darauf warten, dass es jemand
 korrigiert ;-)


ja, als Universal-tag OK, aber am besten passt natürlich (das von
Dir schon erwähnte) golf=bunker, das würde ich auf einem Golfplatz am
Wichtigsten finden.

Gruß Martin

___
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-28 Per discussione Martin Vonwald

Am 28. September 2012 14:50 schrieb Martin Koppenhoefer
dieterdre...@gmail.com:
 Am 28. September 2012 13:39 schrieb Martin Vonwald imagic@gmail.com:
 Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der
 natural-Werte.
 naja, das würde ich so gar nicht mal unterschreiben, die Hauptwerte
 (also die auf der natural-key-Seite) passen eigentlich weit
 überwiegend zur Geographie-Feature-Definition, das sind nur ganz
 wenige wie mud und sand, die da aus der Reihe scheren.

Ein Key sollte eine gewisse Grundidee haben. Die erkenne ich bei
natural definitiv nicht: used to describe a selection of geological
and landcover features.


 Heute würde ich wahrscheinlich
 einfach landcover=sand verwenden und darauf warten, dass es jemand
 korrigiert ;-)
 ja, als Universal-tag OK, aber am besten passt natürlich (das von
 Dir schon erwähnte) golf=bunker, das würde ich auf einem Golfplatz am
 Wichtigsten finden.

So war es auch gemeint.

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

Am 28. September 2012 11:22 schrieb Sven Geggus li...@fuchsschwanzdomain.de
:

 Andreas Trawoeger atra...@kartenwerkstatt.at wrote:

  Einen einzelnen Layer wie bei wms.openstreetmap.de von der lokalen
  Landesprojektion und der jeweiligen Bounding Box nach Web Mercator zu
  transformieren, ist keine große Hexerei.

 Na ja, das mit dem BETA2007 war so einfach nun auch wieder nicht.


Das glaube ich dir sofort, ich habe nur ein wenig zurück lästern müssen ;-))


  Die nicht trivialen Probleme treten auf, sobald man einen globalen Layer
  generiert, bei dem Bildkacheln Bounding Boxen haben können, die
  transformiert in die jeweilige Landesprojektion zu ungültigen Werten
  führen.

 Das ist doch nur der Fall wenn man auserhalb des Abdeckungsbereiches ist
 oder? Beim Mapserver kann man jedenfalls auch wenn man ihn als Proxy
 verwendet eine Bounding-Box angeben für die der Layer gültig ist.


Die Schwierigkeit sind die Zoomstufen 0-5.

Für eine korrekte 256x256 Pixel WebMercator Bildkachel mit Zoomstufe 0
müsste ich für alle verwendeten Layer eine Bildkachel mit der ] berechnen
und diese miteinander kombinieren.

Eine WebMercator Bildkachel in der Zoomstufe 0 hat eine Bounding-Box von
[-180.0,-85.084,180.0,85.084] und umfasst mehr oder weniger den kompletten
Globus und alle für die einzelnen Layer definierten Abdeckungsbereiche.

Eine Abfrage mit dieser Bounding-Box an z.B. geodaten.bayern.de führt aber
zu einer komplett leeren Bildkachel, weil die Bounding-Box außerhalb des
Bereiches liegt für den das lokale Projektionssystem definiert ist.

Ein ähnliches Problem tritt auch auf, wenn man versucht sich auf
openstreetmap.org die Amundsen–Scott South Pole Station anzeigen zu
lassen (das Gebiet rund um die Pole lassen sich in Web Mercator nicht
abbilden, was zu entsprechenden Phänomenen führt).

Die einfachste Lösung für das Problem ist es, die lokalen Layer erst ab
einer gewissen Zoomstufen einzublenden (was derzeit auf OpenGeoServer der
Fall ist). Wobei die eleganteste Lösung jedoch ist, den Layer einmal in
hoher Auflösung abzufragen und die Bildkachelpyramiden für Web Mercator
selbst zu berechnen.


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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

Am 28. September 2012 12:13 schrieb Jochen Topf joc...@remote.org:

 On Fri, Sep 28, 2012 at 12:06:12PM +0200, Andreas Labres wrote:
  (und außerdem sein Landungs-Video... ;)

 Ja, das ist ziemlich cool! Wo kommt der Soundtrack her?


Curiosity has landed: https://www.youtube.com/watch?v=N9hXqzkH7YA

Wobei ich bin der 15 jährigen Clara Ma [0] für den Namen Curiosity sehr
dankbar bin, wenn der Rover noch immer MSL hieße wäre der Track nur der
halbe Spaß.

cu andreas


[0] http://www.space.com/13735-nasa-mars-rover-curiosity-clara-ma.html
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione Kolossos

Ich mag das Projekt und würde den kombinierten Layer gerne in die
OSM-Karte der Wikipedia einbinden.

Eine Testversion gibt es schon :
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Donaulayers=0B0F
Die Luftbilder lassen sich darin mit WIWOSM, hillshading und OSM-Labels
kombinieren.

Andreas, sag bitte bescheidt, wenn deine Server den Anfangsansturm
überstanden haben oder du dahingehend keine Bedenken hast.

Achso, könnstest du den Winter-marbel auf der Nordhalbkugel bitte gegen
den Sommer-marbel austauschen?

Grüße Tim alias Kolossos

Am 28.09.2012 14:32, schrieb Andreas Trawoeger:

Am 28. September 2012 10:58 schrieb aighes o...@aighes.de:

wenn ich es als Laie richtig verstehe, ist der Vorteil für mich, dass ich
automatisch das höchstauflösende Luftbild angezeigt bekomme und nicht hin
und her schalten muss, richtig?

Langfristiges Ziel ist es zwei Dinge zu erreichen:
- Ein einheitlichen kombinierten Luftbild Layer anzubieten, der das
Umschalten zwischen den einzelnen Datenquellen nicht mehr notwendig macht.
- Den Layer in einer einheitlichen und korrekten Projektion anzubieten

Datenquellen wie Yahoo oder Bing Maps sind nicht immer 100%
orthoreferenziert weshalb die darauf basierenden OSM Daten gegenüber den
amtlichen Daten einen mehr oder weniger starken Versatz aufweisen.

Die Fehler sind in den meisten Fällen ziemlich minimal, können aber
Probleme machen, sobald offizell referenzierte Geodaten zur Verfügung
stehen und mit OSM Daten kombiniert werden (weil z.B. eine Mülltonne nicht
neben, sondern auf einer Straße steht).

Was wiederum die Übernahme der zunehmend von Behördenseite zur Verfügung
gestellten frei verfügbaren Geodaten nach OSM verkompliziert. Weil ein 1:1
Import in OSM ein ziemliches Chaos anrichten würde.

cu andreas

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

Re: [Talk-de] Luftbilder via OpenGeoServer.at

2012-09-28 Per discussione Sven Geggus

Andreas Trawoeger atra...@kartenwerkstatt.at wrote:

 Die Schwierigkeit sind die Zoomstufen 0-5.

Ah jetzt verstehe ich.

Du meinst wenn die Kacheln einen Bereich haben der außerhalb des WMS extent
leigt (wie in meienr Skizze).
Wäre einen Versuch Wert mal einen Mapserver mit manuell definiertem
Extent dazwischenzuschalten. Könnte mir gut vorstellen, dass der Mapserver
das dann trotzdem korrekt weiterschickt (also nur den Extent) abfrägt.

+---Kachel---+
||
|  +--+  |
|  |WMS   |  |
|  |Extend|  |
|  +--+  |
||
++

Gruss

Sven

P.S.: Melde Dich einfach mal per Private mail wenn Du denkst das könnte Dir
helfen.

-- 
linux is evolution, not intelligent design
(Linus Torvalds)

/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] Luftbilder via OpenGeoServer.at

Hallo Tim!

Am 28. September 2012 16:52 schrieb Kolossos tim.al...@s2002.tu-chemnitz.de
:

 Ich mag das Projekt und würde den kombinierten Layer gerne in die
 OSM-Karte der Wikipedia einbinden.

 Eine Testversion gibt es schon :
 http://toolserver.org/~**kolossos/openlayers/kml-on-ol-**
 json3.php?lang=detitle=Donau**layers=0B0Fhttp://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Donaulayers=0B0F
 Die Luftbilder lassen sich darin mit WIWOSM, hillshading und OSM-Labels
 kombinieren.

 Andreas, sag bitte bescheidt, wenn deine Server den Anfangsansturm
 überstanden haben oder du dahingehend keine Bedenken hast.


Rein von den Web Zugriffen her ist dem Server derzeit ziemlich langweilig,
was aber noch ca. 1-2 Wochen dauern wird ist den Tile-Cache mit mehr
Zoomlevel aufzufüllen ohne die Source WMS-Server komplett zu überlasten.

Achso, könnstest du den Winter-marbel auf der Nordhalbkugel bitte gegen den
 Sommer-marbel austauschen?


Kann ich machen.


cu andreas
___
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-28 Per discussione Tobias Knerr

Am 28.09.2012 13:39, schrieb Martin Vonwald:
 Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der
 natural-Werte. Ist aber halt das, was dem ganzen am nächsten kommt,
 daher habe ich das damals verwendet. :-/

Ist nicht das etablierte Tag, das einem landcover=sand am nächsten
kommt, eher surface=sand? Ein Tagging wie golf=bunker + surface=sand für
einen Sandbunker passt doch gut.

Das würde dort, wo ich Kontrolle darüber habe - Mapnik gehört natürlich
nicht dazu -, auch gerendert. ;)

Gruß,
Tobias

___
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-28 Per discussione Stephan Wolff


Am 28.09.2012 21:41, schrieb Tobias Knerr:

Am 28.09.2012 13:39, schrieb Martin Vonwald:

Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der
natural-Werte. Ist aber halt das, was dem ganzen am nächsten kommt,
daher habe ich das damals verwendet. :-/


Ist nicht das etablierte Tag, das einem landcover=sand am nächsten
kommt, eher surface=sand? Ein Tagging wie golf=bunker + surface=sand für
einen Sandbunker passt doch gut.


Da im Golf jeder Bunker aus Sand besteht, kann man surface=sand auch 
weglassen. Ein Programm, das golf=bunker nicht auswertet, kann auch 
die Eigenschaft surface=sand nicht nutzen bzw. darstellen.


Viele Grüße
Stephan



___
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 29. September 2012 00:11 schrieb Stephan Wolff s.wo...@web.de:
 Da im Golf jeder Bunker aus Sand besteht, kann man surface=sand auch
 weglassen. Ein Programm, das golf=bunker nicht auswertet, kann auch die
 Eigenschaft surface=sand nicht nutzen bzw. darstellen.


Wieso? Das Programm muss von Golf keine Ahnung haben, um Sand z.B.
gelb zu rendern, unabhängig davon, wo der sich befindet.

Gruß Martin

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

Re: [Talk-it] Tag place ridondanti

2012-09-28 Per discussione Alberto

Simone ha ragione, Vercelli sembra corretto. Ma cercate Casale Monferrato o
Brusson: di ciascuno ne trova due e non capisco perché invece con Vercelli
non succede. A Vercelli forse il tag is_in centra qualcosa? Oppure il fatto
che il nodo centrale di Vercelli fa parte di relazioni boundary?
Tra l'altro per Brusson, sul perimetro tempo fa io avevo messo sia il tag
place=village che landuse=residential. Qui potrebbe aver senso perché in
questi piccoli paesi la zona è quasi tutta residenziale. Che dite lascio
così o tolgo landuse=residential come abbiamo detto?
Alberto (Viking81)


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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione emmexx

Il 09/28/2012 07:54 AM, Davide Ferri scrisse:
   Sto seguendo con altri il tpl a Torino e la soluzione che abbiamo
 adottato e che funziona permettamente anche con i router stradali è di
 spezzare la rotonda ma lasciare il tag junction roundabout sui vari
 tratti della rotonda e togliere il oneway che diventa superfluo. Se
 prendi la maggior parte delle rotonde a Torino vedrai che sono fatte
 così. Il ragionamento è analogo a quando spezzi la way di un viale
 perché, per esempio, cambiano il numero di lanes.

Il ragionamento mi sembra logico, basta che renderers, router e altri
software funzionino...
Il wiki [1] pero' si riferisce sempre a way chiuse:
Start by drawing a circular shape...
There exist two ways to draw a circle in JOSM:...
In Potlatch 2, draw a closed way

E poi:
 Proposed relation for splitted roundabouts

There exists a proposal that suggests putting the individual segments
of a splitted roundabout into a relation, so that data consumers can
determine the full extent of a roundabout more easily.

 Per il tuo caso se sei sicuro che la circolazione sia rotatoria (quindi
 che devi dare precedenza a sinistra) per entrare nella piazza, secondo
 me puoi sostituire oneway con junction roundabout, tuttavia il fatto che
 un viale la tagli in mezzo mi lascia qualche dubbio che possa essere una
 rotonda, a Torino ci sono 2-3 casi analoghi ma in mezzo passa un tram e
 non una strada

E' una rotonda per il codice della strada. C'e' l'apposito segnale di
rotatoria prima di ogni ingresso:
http://www.emmexx.it/varie/dsc01993.jpg
Non ho capito quello che hai scritto a proposito del dare precedenza a
sinistra. Nelle vecchie rotatorie, come questa, era chi stava in
rotatoria a dover dare precedenza. Le vecchie rotatorie non vanno
taggate con junction=roundabout?

grazie
maxx

[1] http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione Maurizio Daniele

Il 28 settembre 2012 08:56, emmexx emm...@tiscalinet.it ha scritto:

 Il ragionamento mi sembra logico, basta che renderers, router e altri
 software funzionino...
 Il wiki [1] pero' si riferisce sempre a way chiuse:
 Start by drawing a circular shape...
 There exist two ways to draw a circle in JOSM:...
 In Potlatch 2, draw a closed way

Questo perché una rotatoria viene sempre creata come un cerchio chiuso
(è più pratico e più preciso grazie alle funzionalità di cui sopra),
ciò non toglie che la si può spezzare all'occorrenza, e il caso di una
route che passa solo su un pezzo di rotonda è una di quelle
occorrenze.

 E poi:
  Proposed relation for splitted roundabouts

In questo caso la relazione sarebbe solo utile a stabilire quanto è
lunga una rotonda, non al routing o altre funzioni che al momento
pare funzionino perfettamente anche nel caso (molto diffuso) di
rotonda spezzata.


-- 
Maurizio Daniele - maurizio.daniele (a) gmail.com

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012/9/28 Martin Koppenhoefer dieterdre...@gmail.com:
 comunque essere una rotatoria se si comparta come una?


comporta intendo...

M

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

Re: [Talk-it] R: R: via privata non accessibile

2012-09-28 Per discussione Federico Cozzi

2012/9/27 Martin Koppenhoefer dieterdre...@gmail.com:
 -1, credo anch'io che non sia supportato, però che c'entra? Si
 potrebbe sempre implementare.

si potrebbe sperare che i programmatori dei router lo supportino.
Però per il momento non sono supportati neanche concetti più diffusi,
come ad esempio access=destination...

 2. l'aggiunta di oneway:bicycle=permissive su quella way non sarebbe
 una mappatura di quello specifico tratto di strada, ma discenderebbe
 da una regola più generale: in bicicletta, se devo scegliere X metri
 di strada trafficata, o Y metri di strada non trafficata e contromano,
 preferisco la seconda quando Y/X è minore di una soglia.
 non sono sicuro. Al meno a vista globale sarebbe una proprietà
 specifica di questa strada, dedotta dalla connoscenza locale del
 mappatore. Se fai una cosa del genere a Stoccarda (andare contro mano
 in bici dove non è consentito) e ti vede la polizia puoi essere sicuro
 che ti multano (quindi non è permissive), mentre a Roma puoi essere
 sicuro che ne anche ti notano, figuriamoci a Napoli ;-)

Rimango del parere che dovrebbe essere uno switch del router:
ciclista berlinese rispetta tutti i divieti; ciclista romano
ignora i divieti di accesso ecc.

Ciao,
Federico

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione Davio

Se tutte le strade che confluiscono nell'incrocio rotatorio devono dare la
precedenza a coloro che sono all'interno dell'anello rotatorio, allor si può
assumere tale incrocio come una rotatoria, in caso contrario no. 

Davide



--
View this message in context: 
http://gis.19327.n5.nabble.com/rotonda-e-gestione-linee-autobus-tram-tp5727975p5728060.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione Simone Saviolo

Il giorno 28 settembre 2012 08:56, emmexx emm...@tiscalinet.it ha scritto:

 Il 09/28/2012 07:54 AM, Davide Ferri scrisse:
  Per il tuo caso se sei sicuro che la circolazione sia rotatoria (quindi
  che devi dare precedenza a sinistra) per entrare nella piazza, secondo
  me puoi sostituire oneway con junction roundabout, tuttavia il fatto che
  un viale la tagli in mezzo mi lascia qualche dubbio che possa essere una
  rotonda, a Torino ci sono 2-3 casi analoghi ma in mezzo passa un tram e
  non una strada

 E' una rotonda per il codice della strada. C'e' l'apposito segnale di
 rotatoria prima di ogni ingresso:
 http://www.emmexx.it/varie/dsc01993.jpg
 Non ho capito quello che hai scritto a proposito del dare precedenza a
 sinistra. Nelle vecchie rotatorie, come questa, era chi stava in
 rotatoria a dover dare precedenza. Le vecchie rotatorie non vanno
 taggate con junction=roundabout?


Un tempo si usava il cartello solo per indicare che bisognava percorrere
l'incrocio in maniera rotatoria, cioè lasciando il centro dell'incrocio
alla propria sinistra invece che alla propria destra come accade
normalmente. Negli ultimi quindici/vent'anni si è insistito di più anche
sull'aspetto della precedenza a sinistra. In casi di rotonde grosse come
queste (mi vengono in mente anche i rotondoni sui viali di Torino), di
solito ci sono dei semafori in mezzo a regolare il traffico. È probabile
che, a semaforo spento, vigendo la segnaletica verticale si debba dare
precedenza a sinistra.

Io indicherei comunque junction=roundabout: è questo quello che si rileva
sul luogo senza ombra di dubbio (c'è il cartello). Se il cartello è
sbagliato (cioè non coincide con le intenzioni del legislatore), cavoli del
legislatore. L'automobilista vede il cartello e si comporta come in una
rotonda. In più ci sono i semafori, che vanno mappati, e che hanno
precedenza rispetto alla segnaletica verticale (che indica la rotonda).

Ciao,

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione emmexx

Il 09/28/2012 10:27 AM, Martin Koppenhoefer scrisse:

 Se c'è questo cartello:
 http://www.daringtodo.com/wp-content/uploads/2008/07/rotonda-1.jpg ti
 togli ogni dubbio. Invece se manca il cartello, secondo voi, potrebbe
 comunque essere una rotatoria se si comparta come una?

Il 09/28/2012 01:53 PM, Davio scrisse:
 Se tutte le strade che confluiscono nell'incrocio rotatorio devono dare la
 precedenza a coloro che sono all'interno dell'anello rotatorio, allor si può
 assumere tale incrocio come una rotatoria, in caso contrario no. 

Se poteste mettervi d'accordo sarei piu' contento! :-)

grazie
maxx

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

Re: [Talk-it] rotonda e gestione linee autobus/tram

2012-09-28 Per discussione Federico Cozzi

2012/9/28 Simone Saviolo simone.savi...@gmail.com:
 Io indicherei comunque junction=roundabout: è questo quello che si rileva
 sul luogo senza ombra di dubbio (c'è il cartello).

Aggiungo anche che, in presenza del tag junction=roundabout, un router
ben fatto dice alla rotonda prendi la seconda uscita; in sua
assenza, dice prosegui a destra ... svolta a destra

Ciao,
Federico

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

Re: [Talk-it] R: R: via privata non accessibile

2012/9/28 Federico Cozzi f.co...@gmail.com:
 2012/9/27 Martin Koppenhoefer dieterdre...@gmail.com:
 -1, credo anch'io che non sia supportato, però che c'entra? Si
 potrebbe sempre implementare.

 si potrebbe sperare che i programmatori dei router lo supportino.
 Però per il momento non sono supportati neanche concetti più diffusi,
 come ad esempio access=destination...


perchè è molto più complicato capire se access=destination vale per te
o meno, rispetto ad un senso unico che non vale mai per te in bici...

ciao,
Martin

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

Re: [Talk-it] R: R: via privata non accessibile