Re: [OSM-talk] West African mangrove forests and PGS coastlines
On Thu, Jan 29, 2009 at 12:41 PM, Erik Johansson wrote: > Landsat also produces images outside of the visibile light spectrum, > perhaps looking at these others could help? (How to access these, and > if it really works I don't know). > I downloaded Landsat images of Banjul from ftp://ftp.glcf.umiacs.umd.edu/glcf/Landsat/WRS2/p205/r051/p205r051_7x20001106.ETM-EarthSat-Orthorectified/and started playing around a bit. The result ended up looking like this: http://www.foseid.no/gustav/gallery/main.php?g2_itemId=1073&g2_imageViewsIndex=1 Compare with how this looks in OpenStreetMap today and in OpenAerialMap (iCube Landsat): http://www.openstreetmap.org/?lat=13.394&lon=-16.358&zoom=11&layers=B000FTF http://www.openaerialmap.org/?lat=13.42284&lon=-16.56708&zoom=11&layers=BF I have not tested the same settings at other places, but it does at least indicate that automated tracing from selected Landsat data could be possible. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] RFC - Scope for access tags
http://wiki.openstreetmap.org/wiki/Proposed_features/Scope_for_access_tags Intention: solve some tagging problems related to restrictions (restrictions on wet roads, restrictions only for some vehicle types, direction-dependent restrictions). Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Licensing Working Group report, 2009/01/22
Johann H. Addicks wrote: > I consider evolving licenses as evil blank cheques. They are a necessary evil. And a necessary blankness. > Even if there is preamble saying "all future versions will be in the same > faith like this" a lot of contributors will feel that they are forced to > trust somebody they do not know so far as beginners. This might be repelling. It hasn't repelled enough people to stop GNU or Wikipedia succeeding. > Think about organisations that you ask for data and you show them a OSM- > license that says "license will change in the future without notice" Think about organizations that show you no licence. > Then even a PD-release would be easier, because then everybody knows that > there is nothing more coming you can ask for. This solves the problem by causing it immediately. ;-) - Rob. signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] outside data sources?
On Wed, 2009-01-28 at 22:14 +0100, andrzej zaborowski wrote: > 2009/1/28 Claudius Henrichs : > > Am 28.01.2009 17:00, andrzej zaborowski: > >> 2009/1/19 Claudius Henrichs: > >>> Am 19.01.2009 17:01, andrzej zaborowski: > Slightly off-topic, the recently added low-zoom country map display > (mapnik) apparently pulls data from outside OSM database. I spotted a > typo (or what I think is a typo) and wanted to correct it and found > that the name with a typo was nowhere in the database. I think the > renderer should only pull data from sources that we can fix. Where > does the data come from? > >>> That's not the case. I'd be rather that someone spotted and fixed the > >>> typo reight before you. > >> > >> It would have rerendered the names about three times by now. Also, > >> what will explain that the names are correct with zoom levels 6 and > >> up, while 1-5 display the non-existent names? Where does the data > >> come from? > > > > the low-zoom levels are not re-rendered that frequently. I guess that's > > the reason why. Which name exactly are you referring to btw? > > Those indicated in > http://lists.openstreetmap.org/pipermail/talk/2009-January/033278.html > > Cheers > These come from the "places" style/layer in the osm.xml. This renders data from an old vmap0 shapefile and only appear on zoom 4 & 5. Maybe we should remove this shapefile? Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Licensing Working Group report, 2009/01/22
> That's a good summation of the reasoning for an evolving license.
I consider evolving licenses as evil blank cheques.
("i agree to this version of licence and any future version relased by
$FOUNDATION")
Even if there is preamble saying "all future versions will be in the same
faith like this" a lot of contributors will feel that they are forced to
trust somebody they do not know so far as beginners. This might be repelling.
Think about organisations that you ask for data and you show them a OSM-
license that says "license will change in the future without notice"
Then even a PD-release would be easier, because then everybody knows that
there is nothing more coming you can ask for.
-jha-
___
legal-talk mailing list
legal-t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] 23rd Dec board meeting
> Thanks for the explanations and clarifications. One question remains > from me: what steps are being taken to avoid OSM users committing > unnecessary wilful trademark infringement at this time? The very plane question for me is: Can i still offer OSM-stickers and T-shirts on a public website for sale? Or will i be faced with $WHATSOEVER in the near future? -jha- ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Tagging covered reservoirs
Hello all How should covered reservoirs be tagged? I noticed man_made=reservoir_covered is in the JOSM presets and map features, though a page doesn't exist for it. I see here: http://tagwatch.stoecker.eu/Great_britain/En/tags.html that 47 examples exist in GB. I found no discussion of this tag on the lists pages - perhaps it just emerged through usage. But this page: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir ...says landuse=reservoir can be covered or uncovered. Mapnik renders reservoirs blue, which could be intuitively misleading for covered reservoirs. It also seems odd to have one type in man_made and the other in landuse. Any thoughts? Or should I stop worrying and create a page for man_made=reservoir_covered ? cheers, LT ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "avoid-obstacles" algorithm
On Thu, Jan 29, 2009 at 11:53 AM, Ivan Garcia wrote: > we would like to implement for disabled persons that will help them to find > the route by avoiding obstacles or undesired areas in the map. > > An example of this is http://seamster.cs.umd.edu:8090/map/index.html , where > you can add dinamically obstacles that you will not like to pass by. > > That means that we are looking for some open source software(or library) > that allows us to do that. Another approach could be giving a high WEIGHT to > some paths so that way the route algorithm will avoid passing by there. There's existing routing software available which does transport-based routing, i.e. different routes for motorvehicles, bicycles and foot traffic: http://wiki.openstreetmap.org/wiki/Routing You could look at those and see how easy they'd be to alter to understand the tagging scheme you plan on using for marking accessibility for the disabled. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: data release statement
On Thu, 2009-01-29 at 14:59 +0100, Stefan Baebler wrote: > Hi! > > Since legal-talk@ list is busy discussing new licensing options I'd > like to hear your opinion about importing a dataset into OSM. > > Namely I'm interested in: > - what legal precausions (if any) should be taken when importing data into > OSM? > - how was this dealt with previously donated data? (AND etc) > > Read my monologue (so far) bellow (in chronological order). > thanks /Stefan > > On Wed, Jan 21, 2009 at 8:31 PM, Stefan Baebler > wrote: > > Hi! > > > > We, the OSM community in Slovenia are in talks with a local company > > GlobalVision [1] that is willing to donate some of their data (mostly > > POIs) to the OSM project. And we have some legal questions for you. > > > > If we do accept their data, how can we be sure that they have all the > > rights to donate it (as they are claiming and probably also is the > > case). We would like to avoid any chance of legal troubles to come > > haunting us after some time. Questionable data could easily be removed > > (source tag, dedicated import user), but old planets are being mirrored > > and distributed so the data would be out there in the wild and cannot be > > erased. > > > > In hypothetical worst case scenario, that the true owner is someone else > > and comes up to us with this issue we'd need some way to turn them (and > > their pack of lawyers) to our source, not us (we'd probably still just > > remove the questionable data to avoid further distribution). > > > > Some kind of a statement from the donor could help, but we're not sure > > what exactly should it contain. > > > > "The company X is hereby donating the dataset of Y map_features to the > > OpenStreetMap project, to be published under CC-BY-SA licence with > > attribution to "X" (in source tag of the data). The company X owns the > > dataset and has all the rights to make this donation." > > (Same in Slovenian and in English) > > > > How was this handled in cases of other such imports (eg. AND data could > > be derived from TeleAtlas or an unlicensed paper map). Is there any > > legal safety net needed? > > > > Data was checked by several most active members of local OSM community > > and we approve the quality. This legal question is the only one bugging > > us. Maybe we are just too paranoid and too strictly following the > > guidelines[2]? Technical part of the import isn't an issue. > > > > Any thoughts? > > Stefan > > > > [1] http://www.globalvision.si > > [2] http://wiki.openstreetmap.org/wiki/Import/Guidelines > > > > -- Forwarded message -- > From: Stefan Baebler > Date: Fri, Jan 23, 2009 at 2:56 PM > Subject: Re: data release statement > To: legal-t...@openstreetmap.org > > > Hi again! > > Further investigation shows, that they are already publishing same > data (and more) > - with freely (as in beer) downloadable localized (Slovenian) version > of mapyx [1] > - in (payable) Slovenian map packs for mapyx in their store [2] > > They want to include OSM support in mapyx (in localized version at > least) so that they could bundle better maps for free with it. > > Would it make any legal difference if they perform the actual import > (with our precise instructions and preparing the .osm file) to avoid > all the paperwork? > > Is any paperwork required and how was this handled in other, similar > situations. > > If so, seeing rather high activity towards ODbL relicensing, would it > make sense to specifically mention that one in the donation paper? > > Any opinions, hidden dangers...? > Stefan Dear Stefan, Congratulations on your work with this data donor. It sounds like you have everything that you need for the import. Previous imports have had either the donor import the data with OSM community help, or the community importing directly. Your suggested agreement text seems complete. I think that your suggestion of mentioning ODbL is a very good idea, as it mirrors our work in the Canadian data discussion. ;-) Best regards and good luck, Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fwd: data release statement
Hi! Since legal-talk@ list is busy discussing new licensing options I'd like to hear your opinion about importing a dataset into OSM. Namely I'm interested in: - what legal precausions (if any) should be taken when importing data into OSM? - how was this dealt with previously donated data? (AND etc) Read my monologue (so far) bellow (in chronological order). thanks /Stefan On Wed, Jan 21, 2009 at 8:31 PM, Stefan Baebler wrote: > Hi! > > We, the OSM community in Slovenia are in talks with a local company > GlobalVision [1] that is willing to donate some of their data (mostly > POIs) to the OSM project. And we have some legal questions for you. > > If we do accept their data, how can we be sure that they have all the > rights to donate it (as they are claiming and probably also is the > case). We would like to avoid any chance of legal troubles to come > haunting us after some time. Questionable data could easily be removed > (source tag, dedicated import user), but old planets are being mirrored > and distributed so the data would be out there in the wild and cannot be > erased. > > In hypothetical worst case scenario, that the true owner is someone else > and comes up to us with this issue we'd need some way to turn them (and > their pack of lawyers) to our source, not us (we'd probably still just > remove the questionable data to avoid further distribution). > > Some kind of a statement from the donor could help, but we're not sure > what exactly should it contain. > > "The company X is hereby donating the dataset of Y map_features to the > OpenStreetMap project, to be published under CC-BY-SA licence with > attribution to "X" (in source tag of the data). The company X owns the > dataset and has all the rights to make this donation." > (Same in Slovenian and in English) > > How was this handled in cases of other such imports (eg. AND data could > be derived from TeleAtlas or an unlicensed paper map). Is there any > legal safety net needed? > > Data was checked by several most active members of local OSM community > and we approve the quality. This legal question is the only one bugging > us. Maybe we are just too paranoid and too strictly following the > guidelines[2]? Technical part of the import isn't an issue. > > Any thoughts? > Stefan > > [1] http://www.globalvision.si > [2] http://wiki.openstreetmap.org/wiki/Import/Guidelines > -- Forwarded message -- From: Stefan Baebler Date: Fri, Jan 23, 2009 at 2:56 PM Subject: Re: data release statement To: legal-t...@openstreetmap.org Hi again! Further investigation shows, that they are already publishing same data (and more) - with freely (as in beer) downloadable localized (Slovenian) version of mapyx [1] - in (payable) Slovenian map packs for mapyx in their store [2] They want to include OSM support in mapyx (in localized version at least) so that they could bundle better maps for free with it. Would it make any legal difference if they perform the actual import (with our precise instructions and preparing the .osm file) to avoid all the paperwork? Is any paperwork required and how was this handled in other, similar situations. If so, seeing rather high activity towards ODbL relicensing, would it make sense to specifically mention that one in the donation paper? Any opinions, hidden dangers...? Stefan [1] http://www.mapyx.com/ / http://www.kje.si/ [2] http://www.mapyx.com/index.asp?tn=shop2&c=227 / http://www.kje.si/index.asp?tn=shop2&c=217 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] "avoid-obstacles" algorithm
Hi everybody we would like to implement for disabled persons that will help them to find the route by avoiding obstacles or undesired areas in the map. An example of this is http://seamster.cs.umd.edu:8090/map/index.html , where you can add dinamically obstacles that you will not like to pass by. That means that we are looking for some open source software(or library) that allows us to do that. Another approach could be giving a high WEIGHT to some paths so that way the route algorithm will avoid passing by there. Thanks in advance. Iván ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] West African mangrove forests and PGS coastlines
On Wed, Jan 28, 2009 at 9:43 PM, Gustav Foseid wrote: > In West Africa, I have noticed that mangrove forests are often tagged as sea > by PGS. Some examples are found at: > Landsat also produces images outside of the visibile light spectrum, perhaps looking at these others could help? (How to access these, and if it really works I don't know). -- /emj ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tag-Proposal] Freifunk/Mesh nodes + links
From: Sven Rautenberg To: talk@openstreetmap.org Sent: Thursday, 29 January, 2009 10:34:03 Subject: Re: [OSM-talk] [Tag-Proposal] Freifunk/Mesh nodes + links >Linus Lüssing schrieb: >> In my opinion Freifunk and OpenStreetMap are both very good and valuable >> public services run by eager indivuals. However, I'm wondering, if these >> public services shouldn't be interconnected with each other a bit more. > >While I am not against working together, I doubt it would be useful to >dump your database into OSM. I'm with Sven on this as far as the OSM database is concerned - a potentially fast-changing set of data such as a set of wireless nodes wouldn't be good fit in the OSM database itself. However, OSM is more than just a database, it's also a set of tools to do interesting things with that data and a community surrounding it. I'm very keen to see the OSM data used to create custom maps for all sorts of applications, and a Freifunk network map would be a good example of this. You could take a copy of OSM data, merge it with Freifunk data from a separate database and use Mapnik (or osmanrender, or anything else) to generate a custom map. This is absolutely what OSM is about, and I think you'd find the OSM community very supportive of such an effort. Just my tuppence worth.. Donald ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tag-Proposal] Freifunk/Mesh nodes + links
Linus Lüssing schrieb: > In my opinion Freifunk and OpenStreetMap are both very good and valuable > public services run by eager indivuals. However, I'm wondering, if these > public services shouldn't be interconnected with each other a bit more. While I am not against working together, I doubt it would be useful to dump your database into OSM. > So far, most Freifunk-communities are mostly using Google for > visualising the nodes and connections between these nodes on a map, > which does not really suite the Freifunk ideology in my opinion. Then you are free to use OSM as an alternative background layer for your visualisations. That's fine - if you can accept the usual hiccups of the OSM servers. OSM is not Google, it cannot deliver 24/7 service, although we would all like it to be so. > Therefore I propose the following new tags for a mesh-node in general > and the connections between mesh-nodes in OSM. We had an import of "Fon" nodes about a year ago, which resulted in a discussion about the usefulness of such data in OSM. The import itself was questioned because of a unclear database license at the source (so it should not have happened in the first place), but also the usability was questioned because OSM data is rather static, and the availability of WLAN nodes is quite dynamic. In the end it turned out that nobody felt responsible for the data, neither for keeping them current and correct them nor for removing them from the OSM database again. In my opinion OSM should stick to map physical objects which can be seen by humans, not try to integrate the more obscure world of radio waves. That is not to tell you your data is useless, but to distinguish between your special interest group and the public. What is good for the public in terms of map rendering might not be good for you, and vice versa. Currently we see the development of several special-interest-maps which highlight certain parts of the OSM data (such as the cycle map, the hiking map, the public transport map, as well as some validator maps to spot data problems). I can imagine that there will be some kind of "general background map", which can be used together with a separate map layer that contains special interest data from a different source, e.g. Freifunk node locations. One comment on your proposal: > Tags for connections between nodes: > highway - "data" > type - "wireless" > oneway - "yes", "no" (omitting this tag implies "no") No! "highway" is for mapping roads - patches of earth surface used by vehicles for ground transport. "highway=data" is an abuse. > PPS: So far, the idea is, that every person who is running a node and > wants to publish this will have to do this manually in OSM first. But I > could also imagine an implementation in the firmwares themselves for > adding parts of the details automatically. The connections between the > nodes could be probed, measured and uploaded to OSM in certain periods > of time. (Transmitting the link details every hour wouldn't harm the > database, would it? The big advantage of this would also be, to be able > to visualise the growth of a mesh-network over time.) I think OSM is the wrong place for your ideas. Yes, they are nice and sound good, but I think you'd be better off if you use a separate database for stuff like this. Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Error in Google-Maps
I'd go for the irrigation canals too. To me the grid looks like some kind of giant chinese character. Somebody can read chinese? Jose On Thu, Jan 29, 2009 at 9:03 AM, Gert Gremmen wrote: > Could it be irrigation canals ? > > > > Gert Gremmen > > - > > Openstreetmap.nl (alias: cetest) > > P Before printing, think about the environment. > > > > > > Van: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] > Namens D Tucny > Verzonden: Thursday, January 29, 2009 2:29 AM > Aan: Adam Schreiber > CC: Jürgen Reimann; talk@openstreetmap.org > Onderwerp: Re: [OSM-talk] Error in Google-Maps > > > > 2009/1/29 Adam Schreiber > > On Wed, Jan 28, 2009 at 7:27 PM, D Tucny wrote: >> Of course, OSM isn't perfect... >> >> http://sautter.com/map/?zoom=11&lat=29.60689&lon=112.12921&layers=B000FTFF >> >> I'm pretty sure there's no grid of motorways there... :/ >> >> There might be a grid of roads though, so seems like a new mapper >> potentially needs some prodding towards the documentation... I'll go do >> that... > > If you switch to the Google sattelite imagery, they are still pretty > big roads at zoom 14 which is the lowest google has imagery for. They > may not be motorways as we think of them, but they're something big. > > They probably are reasonably big access roads for a future development... a > 3 lane each direction dual carriageway with nice wide garden filled central > reservation with trees and/or other plants to each side seperating the wider > than a normal lane cycle ways on each side from the main carriageway > wouldn't be unusual for a slightly out of the way development (e.g. > http://maps.google.com/?ie=UTF8&ll=30.183743,120.206845&spn=0.003269,0.006866&t=h&z=18)... > And they aren't much smaller in city centers when new roads are built, or in > some cases, where existing roads are upgraded, which, with all the > demolishing of buildings that accompanies it, probably makes it a lot more > expensive than just making massive roads in the first place when they can, > leading us back to the probable logic behind building roads wider than two > motorways for access to and within a small development... > > d > > ___ > 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] Error in Google-Maps
Could it be irrigation canals ? Gert Gremmen - Openstreetmap.nl (alias: cetest) P Before printing, think about the environment. Van: talk-boun...@openstreetmap.org [mailto:talk-boun...@openstreetmap.org] Namens D Tucny Verzonden: Thursday, January 29, 2009 2:29 AM Aan: Adam Schreiber CC: Jürgen Reimann; talk@openstreetmap.org Onderwerp: Re: [OSM-talk] Error in Google-Maps 2009/1/29 Adam Schreiber On Wed, Jan 28, 2009 at 7:27 PM, D Tucny wrote: > Of course, OSM isn't perfect... > > http://sautter.com/map/?zoom=11&lat=29.60689&lon=112.12921&layers=B000FTFF > > I'm pretty sure there's no grid of motorways there... :/ > > There might be a grid of roads though, so seems like a new mapper > potentially needs some prodding towards the documentation... I'll go do > that... If you switch to the Google sattelite imagery, they are still pretty big roads at zoom 14 which is the lowest google has imagery for. They may not be motorways as we think of them, but they're something big. They probably are reasonably big access roads for a future development... a 3 lane each direction dual carriageway with nice wide garden filled central reservation with trees and/or other plants to each side seperating the wider than a normal lane cycle ways on each side from the main carriageway wouldn't be unusual for a slightly out of the way development (e.g. http://maps.google.com/?ie=UTF8&ll=30.183743,120.206845&spn=0.003269,0.006866&t=h&z=18)... And they aren't much smaller in city centers when new roads are built, or in some cases, where existing roads are upgraded, which, with all the demolishing of buildings that accompanies it, probably makes it a lot more expensive than just making massive roads in the first place when they can, leading us back to the probable logic behind building roads wider than two motorways for access to and within a small development... d <>___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
