Re: [OSM-talk] Can we ditch the publication copyright issues with the Haiti map?
2010/1/15 Stefan de Konink : > As subject. > > Can we just grant anyone that want to report news, help on site, to use > vector and bitmap data without creative commons madness? > > I think it is very ethical to say yes to the above. > > Where is that CC madness you are talking about? As far as I know CC-BY-SA just requires to publish CHANGED DATA by same license. I really doubt anyone in this situation wouldn't like to share changes because every update helps. And I really doubt anyone using it for relief or publishing even touch territory of license. They can do whatever they want, just keep attribution in a bottom of the screen (or somewhere near the map). Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Tagging for Haiti: Humanitarian Data Models in support of OSM tagging for Haiti EQ
Micha Ruh wrote: > 2010/1/16 Jean-Marc Liotier mailto:j...@liotier.org>> > > I tried to > replace "building=collapsed" with "earthquake:damage=collapsed_building" > > Please don't, it's useless, if not harmful. > > Why do you want to replace a simple, understandable, well established, > broadly supported tag with something THAT complicated? > > It's ok, that another tag with the same meaning exists due to imports, > but please DO NOT change well known and used tags with another one > coming from an import. > > Especially not when the new tag is 35 chars long. Try editing that in > potlatch. Take a look at tagstats : tag value usesnodeway buildingcollapsed 1,045 747 298 earthquake:damage collapsed_building 1,473 1,465 8 We have two tags to describe the same thing. One is apparently more widespread, more conformant to published standards and semantically superior. What do others think ? Is tag length such an issue ? Doesnt autocompletion solve the problem of tag length ? Is it desirable to standardize ? Isn't it harmful to have two tags to describe the same thing ? Is the value of harmonization inferior to the value of not disturbing habits taken in the last few days ? Do we have past experience or a policy for such things ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: > Am 15.01.2010 23:02, schrieb Carsten Moeller: >> yes, osm relations are one possible solution. But from the view of a >> pgRouter it is a very stony way to collect that data back into a routing >> table. You are right, that there should be a tag like "terminal" or >> "ramp" or even simpler "link". > > Seems there's at least no "difference in principle" that this would be > useful :-) > > We already have the established amenity=ferry_terminal and an > amenity=motorail_terminal wouldn't be very different in functionality - > no need to develop a complete new name IMHO. > > As you certainly want to have a different rendering for these two, it > might not be a good idea to have just a single tag like amenity=terminal > for this. > >> From the perspective of a "street map" a pickapack railway or ferry has >> the same quality as e.g. highway=pedestrian. > > Sorry, i don't get your point here. On highway=pedestrian I'm not > allowed to drive (except maybe for un-/loading at specific times) - > which is completely different IMHO. > >> So I'd prefer sth. like highway=railway, highway=ferry, >> highway=railway_link and highway=ferry_link. >> This info is enough for pgRouting to create a topology. >> Additional properties can be assigned to "amenity" or "railway" of course. > > For a ferry (if all is tagged well), this can already be achieved. > You'll travel: > > highway=service > amenity=ferry_terminal (if it allows cargo=vehicle) > ferry route (as tagged and displayed already on the maps) > amenity=ferry_terminal (again with cargo=vehicle) > highway=service > > The same principle applies for a railway as well: > > highway=service > amenity=motorail_terminal > motorail route (see below) > amenity=motorail_terminal > highway=service > > The exception for the railway - compared with ferries - is, that the > "railway grid" will physically connect a lot of places. There's > certainly a physical railway connection from the sylt shuttle mainland > station to italy. But the railway company just won't offer you that > service :-) > > Now you can invent a special tag (as you intended) for the short > distance or "point to point" connections, like sylt shuttle, channel > tunnel and alike applies for several short distance tunnel services in > the alps. > > Then you'll need *another* mechanism for the long distance travel from > hamburg to vienna (Deutsche Bahn is offering about roughly 20 such > dedicated routes - not more) with just exactly the same problem: Travel > with your car pickapack on a train from A to B. That's why I was > thinking about relations. > > > However, as you may want to display on a map only short distance but not > long distance pickapack, it even makes sense IMO to have two different > ways to tag this. One to tag "point to point" connections as you'd > suggested and one for "long distance connection grid" connections using > relations. > > > May I suggest to just keep existing stuff for ferries and use > amenity=motorail_terminal and highway=motorail (which seems to be the > right translation for german Autoverladung/Autoreisezug) for the short > distance ways? > > Regards, ULFL > > P.S: Next time, using the tagging mailing list seems more natural for > these or similar discussions ;-) Yes, I do agree. We should have tags describing short and long distances. The latter is possibly best expressed by using relations. Yes, there are already tags for our problem: highway=service amenity=ferry_terminal (if it allows cargo=vehicle) ferry route (as tagged and displayed already on the maps) amenity=ferry_terminal (again with cargo=vehicle) highway=service But this kind of tagging is hardly parsable. In case of routing, I don't want to collect all highway=service in the topo. For route=ferry or rail=railway I can distinguish if they are subtagged by motorcar=true or not. As a consequence the highway=service then should be subtagged with sth. like "ferry-link". But this guides me to my first approach again. In my opinion, it should be as simple as possible. I'm afraid, only few people will follow this tagging pattern and we'll end up in a forest. Once again, the main problem is the parsing itself. In case of the upper example you will have to analyze relations in a second step. If you tagged them directly It's just a one shot parsing. Another problem, as I've already mentioned before, are the connections (even same nodes) between railroads and streets. This is a annoying and kills the ability for OSM to route satisfyingly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Florist apologises: A florist says changing competitors' details on Google Maps 'became an addiction'.
2010/1/16 John Smith : > Wonder if the police would bother pursuing the matter if people were > caught for the same offence on OSM? I don't think it would be an offense, when you join OSM you're not agreeing to provide true information, only that you produced it. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Florist apologises: A florist says changing competitors' details on Google Maps 'became an addiction'.
2010/1/16 andrzej zaborowski : > 2010/1/16 John Smith : >> Wonder if the police would bother pursuing the matter if people were >> caught for the same offence on OSM? > > I don't think it would be an offense, when you join OSM you're not > agreeing to provide true information, only that you produced it. She was charged with criminal offense, not a civial breach of terms... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Florist apologises: A florist says changing competitors' details on Google Maps 'became an addiction'.
Hi. andrzej zaborowski wrote: >> Wonder if the police would bother pursuing the matter if people were >> caught for the same offence on OSM? > > I don't think it would be an offense, when you join OSM you're not > agreeing to provide true information, only that you produced it. Probably in most jurisdictions the intent will come into the equation. If I make a random change in OSM data just for laughs, then it will be hard to make a case against me, but if I change a road to lead over a cliff, knowing full well that my enemy #1 is going to download the data into his satnav that night and then blindly trust it then I might be facing trouble, no matter whether OSM had a big red "this is all just for laughs" message when you sign on or not. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Arbeitsmatrix für Haiti
2010/1/15 Jean-Marc Liotier : > Hi, since yesterday evening I'm trying to contact the author of > http://osm.m0nty.de/ which would be perfect to coordinate work in Haiti. > Does anybody know if that tool is open source and where we can get the > source code ? Does anyone have the author's e-mail address ? People who > can customize the tool and then deploy it are standing ready. it might be a good idea to work on something like this that could be used in a more general purpose way. -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle route won't render
On Sat, Jan 16, 2010 at 11:27 AM, Cartinus wrote: > If renderer XYZ renders amenity=llibrary with a library icon (to catch > a "common" typo), then we could document that somewhere on a page about > renderer XYX. However we definitely should not document this as a valid tag > on the amenity page. I'm sick of stupid flamewars, so I'll just say, "I disagree, all information about a tag is relevant, in the absence of a central authority", and leave it that. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle route won't render
On Sat, Jan 16, 2010 at 11:38 AM, Felix Hartmann wrote: > Network=mtb makes not much sense in my eye (and was never discussed, > approved, proposed...) as we can't differentiate then anymore between > local and regional mtb routes. > The question therefore is, what values do we want to use for network? > > Should we use ncn/rcn/lcn (because this is already quite commonly used > for route=mtb and the differentitation to cycle routes can be done > because we use route=mtb and not route=bicycle) or maybe nmn/rmn/lmn > (this would go in accoradance with "ncn" Cycle Network and "nwn" Walking > Network), or maybe go without accronyms and use "network=regional_mtb", > "network=local_mtb" . How many places have local/regional/national mountain biking networks? How would you tag routes that are both hiking and mountain biking? Would a "local mtb network" be something like a set of trails that link to each other at a ski resort or dedicated mountain bike park? Or perhaps even towns that are lucky enough to have mtb trails used as a form of transport... The general idea that mountain biking routes should be route=mtb, not route=bicycle, does seem sound to me; the needs of mountain bikers and normal cyclists are quite different and don't overlap much. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle route won't render
On Saturday 16 January 2010 13:59:44 Steve Bennett wrote: > I'm sick of stupid flamewars, so I'll just say, "I disagree, all > information about a tag is relevant, in the absence of a central > authority", and leave it that. If you are sick of what you call stupid flamewars, then you should think more and write less. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] CommonMap association is now proceeding to incorporation
Hi, I just wanted to let everybody know that the CommonMap association is now authorised to incorporate. We have 8 members in total. Both "special resolutions" on http://commonmap.info/w/index.php/Association/Incorporation/Agenda were carried. According to http://www.fairtrading.qld.gov.au/incorporating-an-association.htm we now proceed to "lodge Association Incorporation Form 1". More details to come but we'll probably post them on http://commonmap.info/ Thanks, Brendan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle route won't render
On Sun, Jan 17, 2010 at 12:58 AM, Cartinus wrote: > If you are sick of what you call stupid flamewars, then you should think more > and write less. Yes, this is very much the approach I intend to take. We could probably all heed the advice. A moderator on the list probably wouldn't go astray either. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle route won't render
On 16.01.2010 14:04, Steve Bennett wrote: > On Sat, Jan 16, 2010 at 11:38 AM, Felix Hartmann > wrote: > >> Network=mtb makes not much sense in my eye (and was never discussed, >> approved, proposed...) as we can't differentiate then anymore between >> local and regional mtb routes. >> The question therefore is, what values do we want to use for network? >> >> Should we use ncn/rcn/lcn (because this is already quite commonly used >> for route=mtb and the differentitation to cycle routes can be done >> because we use route=mtb and not route=bicycle) or maybe nmn/rmn/lmn >> (this would go in accoradance with "ncn" Cycle Network and "nwn" Walking >> Network), or maybe go without accronyms and use "network=regional_mtb", >> "network=local_mtb" . >> > How many places have local/regional/national mountain biking networks? > How would you tag routes that are both hiking and mountain biking? > Would a "local mtb network" be something like a set of trails that > link to each other at a ski resort or dedicated mountain bike park? Or > perhaps even towns that are lucky enough to have mtb trails used as a > form of transport... > > The general idea that mountain biking routes should be route=mtb, not > route=bicycle, does seem sound to me; the needs of mountain bikers and > normal cyclists are quite different and don't overlap much. > > Steve > Well I think route=mtb is more or less a consensus. Differentiation to route=bicycle is in 99% of all routes clear. It's more on the route=bicycle side where "they" have to think about differentiations on trekking routes, commuter routes (routes for tourists vs commuters have completely different objectives), routes for race cyclists,. What we have to think about are inofficial routes. OSM would really profit if nice and popular Transalp routes are included into the database (we are free mtbikers, we don't need no stinking signs to tell us that we are using a mtb route). However I do think we could should have some differentiation between mtb routes that are "flagged" out (be it only in official tourist brochures, be it on signs,...) and mtb routes that are not made by official authorities but by users (e.g. my friday afternoon workout route, my favourite transalp route). Often official routes are lame anyhow because they have to be 100% legal. This is especially true for Germany and Austria, stringent in parts of Italy (you not only face hefty fines, but the chance to be fined is also big) and less of a problem in France or Switzerland where laws related to mtbiking are much friendlier and not dictated by the green dwarf and his Jeep. Then we need a differentiation between oneday roundtrip routes (local) from A to B to A, and routes spanning multiple days (usually regional) from A to B to C. Just to answer how many regional routes I know, I do know a lot of regional and even official multiple days routes in the European Alps. And there is no problem of all if several routes use the same way, I think by now it has become clear to most that routes will have to be using relations, because otherwise we get into trouble with multiple values for unique keys. I think the network key would be good to be used for differentiation of the different routes. We simply have to think about unified tagging so that renderers know what kind of route they are analyzing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extended GeoEye imagery now available for use on OSM
Hi, The torrent file does not work for me. It says "got bad file info". F. On Sat, Jan 16, 2010 at 6:50 AM, Ævar Arnfjörð Bjarmason wrote: > On Sat, Jan 16, 2010 at 03:13, Ævar Arnfjörð Bjarmason > wrote: > > On Fri, Jan 15, 2010 at 21:35, Ævar Arnfjörð Bjarmason > wrote: > >> We just got permission from GeoEye to use some new imagery which > >> covers a lot more area than what we currently have, this shows the > >> extent: > >> > >>http://v.nix.is/~avar/geoeye-extent.png > >> > >> The imagery is 23 TIFF files which I'm mirroring here: > >> > >>http://cassini.toolserver.org/haitiearthquake-geoeye-tiffs/ > >> > >> The Google server is very slow so please don't hammer it more. I'll > >> see about setting up a torrent or something when we've got it all. > >> > >> These are "orthorectified 8-bit compresed GeoTiffs", who can help with > >> turning these into something usable for OSM editors? I have no idea > >> how the TIFF -> WMS|Tiles process goes. > > > > Google just split up all their tar files (their webserver couldn't > > handle >2GB files). They're trickling into Cassini at the same URL. > > There's also a .torrent: > > http://cassini.toolserver.org/haitiearthquake-geoeye-tiffs/geoeye_00156730.torrent > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Boundaries in Haiti
Hi, Based on the data here : https://www.geoint-online.net/community/haitiearthquake/default.aspx of the US Census Bureau, I extracted the city and town borders for Haiti. The tags I used are : is_in="name of the district" name=* boundary=administrative admin_level=8 source=US Census Bureau population=* id_commune="ID given in the source file" The file is here : http://fredericbonifas.free.fr/haiti_boundaries.osm Does it seem ok to you before uploading ? Is there an easy to remove these boundaries if we get better ones later ? Frédéric ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundaries in Haiti
Hi, Am 16.01.2010 um 16:43 schrieb Frédéric Bonifas: > Hi, > > Based on the data here : > https://www.geoint-online.net/community/haitiearthquake/default.aspx > of the US Census Bureau, I extracted the city and town borders for > Haiti. > The tags I used are : > > is_in="name of the district" > name=* > boundary=administrative > admin_level=8 > source=US Census Bureau > population=* > id_commune="ID given in the source file" > > The file is here : http://fredericbonifas.free.fr/haiti_boundaries.osm > > Does it seem ok to you before uploading ? > Is there an easy to remove these boundaries if we get better ones later ? Please create a special import account for this. The data should be easily removable as long as the source tag is unique and is not deleted. I would suggest to use "source=US Census Bureau, boundary import, 16/01/2010" Please also add information about the import to the Haiti wiki page. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Boundaries in Haiti
Hi all, > Based on the data here : > https://www.geoint-online.net/community/haitiearthquake/default.aspx > of the US Census Bureau, I extracted the city and town borders for > Haiti. > The tags I used are : > > is_in="name of the district" > name=* > boundary=administrative > admin_level=8 > source=US Census Bureau > population=* > id_commune="ID given in the source file" > > The file is here : http://fredericbonifas.free.fr/haiti_boundaries.osm > > Does it seem ok to you before uploading? Looks good enough. One could of course reuse the ways with relations and stuff but it is a good start. > Is there an easy to remove these boundaries if we get better ones later ? Removal is easy enough. Merging with better data would be hard. Patrick "Petschge" Kilian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fwd: Boundaries in Haiti
2010/1/16 Frédéric Bonifas : > Hi, > > Based on the data here : > https://www.geoint-online.net/community/haitiearthquake/default.aspx > of the US Census Bureau, I extracted the city and town borders for > Haiti. > The tags I used are : > > is_in="name of the district" > name=* > boundary=administrative > admin_level=8 > source=US Census Bureau > population=* > id_commune="ID given in the source file" > > The file is here : http://fredericbonifas.free.fr/haiti_boundaries.osm > > Does it seem ok to you before uploading ? I would prefer to upload the complete borders of haiti with departements, arrondissements, citys and suburbs. Instead of your method of on way per city, we should use relations. > Is there an easy to remove these boundaries if we get better ones later ? You could easily remove all admin_level=8 ways in certain bbox. If we want to use this borders, I will create an import file. Ciao André ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Call to map : Help Albania with the flooding of Skoder!
http://www.openstreetmap.org/user/h4ck3rm1k3/diary/9264 There has been a massive flooding in Albania, Floods have devastated a region of about 10,000 hectares. More than 2,400 homes were flooded. We should help build a map for the relief effort like the Haiti! mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Boundaries in Haiti
moin On 16.01.2010, at 17:16, André Riedel wrote: > 2010/1/16 Frédéric Bonifas : >> Hi, >> >> Based on the data here : >> https://www.geoint-online.net/community/haitiearthquake/default.aspx >> of the US Census Bureau, I extracted the city and town borders for >> Haiti. >> The tags I used are : >> >> is_in="name of the district" >> name=* >> boundary=administrative >> admin_level=8 >> source=US Census Bureau >> population=* >> id_commune="ID given in the source file" >> >> The file is here : http://fredericbonifas.free.fr/haiti_boundaries.osm >> >> Does it seem ok to you before uploading ? > I would prefer to upload the complete borders of haiti with > departements, arrondissements, citys and suburbs. Instead of your > method of on way per city, we should use relations. > >> Is there an easy to remove these boundaries if we get better ones later ? > You could easily remove all admin_level=8 ways in certain bbox. > > If we want to use this borders, I will create an import file. from what I can see at the moment that is a huge list of dots! Some are costline, some are streets, some are rivers evn if I like the idea of getting a huge list of points, they should really be checked before importing them. I mean the coastline is already mapped for example. and the points there are very irritating. cu assetburned ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Haiti - data import & edits based on reporting: dissemination of MINUSTAH data to everyone
Hi there A resource to monitor and asseess extremeley closely for future data imports and edits based on reports: MINUSTAH - the UN peace keeping operation in Haiti - has the best data of the country Licenses issues are being discussed Best N -- Forwarded message -- From: Jeffrey Johnson Date: Sat, Jan 16, 2010 at 6:04 PM Subject: Re: [CrisisMappers] IMPORTANT: dissemination of MINUSTAH data to everyone To: crisismapp...@googlegroups.com What format is the 'Data' in? ftp://157.150.195.135/Data/ Jeff On Sat, Jan 16, 2010 at 8:57 AM, Patrick Meier (CrisisMappers) wrote: > > To: Philip Chinnici/OCHA/g...@ocha, Lauren Paletta/OCHA/g...@ocha, Kirsten > Gelsdorf/OCHA/n...@ocha, Andrew Alspach/OCHA/g...@ocha, Dan > DeLorenzo/OCHA/n...@ocha, Jeffrey Villaveces/OCHA/f...@ocha > From: Akiko Harayama/OCHA/NY > Date: 01/16/2010 10:28AM > Subject: dissemination of MINUSTAH data to everyone > > Good news, we can now share the MINUSTAH data with everyone!!! > > If you are using ftp client you can access the ftp as follows: > > IP: 157.150.195.135 > Username: haiti > Password: Rkjpb7uef > > If you are using browser you can access the ftp as follows: > > ftp://haiti:rkjpb7...@157150.195.135 > __ > Save the forest by printing less! > > Ms. Akiko HARAYAMA > ReliefWeb Cartographer > Communications and Information Services Branch (CISB)/OCHA/United Nations > haray...@un.org > Tel. (+1) 917 367 24 26 > 380 Madison Avenue, 7th floor, Office M-07034, New York > http://www.reliefweb.int > > > > -- > International Network of Crisis Mappers > http://www.CrisisMappers.net > -- International Network of Crisis Mappers http://www.CrisisMappers.net -- Nicolas Chavent Humanitarian OpenStreetMap Team http://wiki.openstreetmap.org/wiki/WikiProject_Haiti Mobile (FRA): +33 6 75 14 29 70 Email: nicolas.chav...@gmail.com Skype: c_nicolas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Am 16.01.2010 10:16, schrieb Carsten Moeller: > Yes, I do agree. We should have tags describing short and long > distances. The latter is possibly best expressed by using relations. > Yes, there are already tags for our problem: > > highway=service > amenity=ferry_terminal (if it allows cargo=vehicle) > ferry route (as tagged and displayed already on the maps) > amenity=ferry_terminal (again with cargo=vehicle) > highway=service > > But this kind of tagging is hardly parsable. In case of routing, I don't > want to collect all highway=service in the topo. Sorry to say, if you don't take highway=service ways into account, your whole routing program gets very certainly a lot less useful to a lot of end users anyway. > For route=ferry or > rail=railway I can distinguish if they are subtagged by motorcar=true or > not. As a consequence the highway=service then should be subtagged with > sth. like "ferry-link". But this guides me to my first approach again. > In my opinion, it should be as simple as possible. That's true. But it should be as simple as possible for the mappers (as long as it's somehow usable for routers) :-) If you say "the mappers have to improve tagging, otherwise I won't be able to write a router" I'd say "write a better router". It's not because I don't like you, it's because I know that half of the mappers won't do it anyway and you'll just end up with a router not working in a lot of situations. > I'm afraid, only few > people will follow this tagging pattern and we'll end up in a forest. That's no news, regardless of what we'll discuss here ;-) > Once again, the main problem is the parsing itself. In case of the upper > example you will have to analyze relations in a second step. If you > tagged them directly It's just a one shot parsing. If you don't want to analyze relations, you will also miss other required stuff (e.g. turn restrictions). A router not analyzing relations has no future IMHO. > Another problem, as I've already mentioned before, are the connections > (even same nodes) between railroads and streets. This is a annoying and > kills the ability for OSM to route satisfyingly. No, it doesn't ;-) Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Boundaries in Haiti
Upload is now complete. If there is a better method, then the only thing to do is to revert the changeset 3632884 : http://www.openstreetmap.org/browse/changeset/3632884 Frédéric ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extended GeoEye imagery now available for use on OSM
On Sat, Jan 16, 2010 at 15:37, François Van Der Biest wrote: > The torrent file does not work for me. > It says "got bad file info". It works for me at a remote site and one other user who's getting it. The description for the torrent includes a double quote but that's supported in the torrent file format, both of the clients that are getting it are libtorrent based (rtorrent). Perhaps your torrent program has a bug? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Boundaries in Haiti
Hi, Frédéric Bonifas wrote: > If there is a better method, then the only thing to do is to revert > the changeset 3632884 : > http://www.openstreetmap.org/browse/changeset/3632884 This import does not meet normal OSM import quality standards and under normal circumstances I would probably revert it until someone has the time & diligence to do it properly. (The boundaries do not re-use the existing coastline but instead duplicate it in a rough form; where tho administrative areas meet, ways are not re-used either but duplicated.) Usually, while we apply the rule "better crappy data than no data at all" for anything surveyed by humans, we are more strict with imports, and we ask people to either do it right or leave it for someone who can. But of course this is an exceptional situation in that many people seem to be using the map data *now* rather than some time later when we had the time to polish it, so it was probably good to import the data, buggy as it is. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Boundaries in Haiti
Am 16.01.2010 um 20:06 schrieb Frederik Ramm: > Hi, > > Frédéric Bonifas wrote: >> If there is a better method, then the only thing to do is to revert >> the changeset 3632884 : >> http://www.openstreetmap.org/browse/changeset/3632884 > > This import does not meet normal OSM import quality standards and under > normal circumstances I would probably revert it until someone has the > time & diligence to do it properly. (The boundaries do not re-use the > existing coastline but instead duplicate it in a rough form; where tho > administrative areas meet, ways are not re-used either but duplicated.) > > Usually, while we apply the rule "better crappy data than no data at > all" for anything surveyed by humans, we are more strict with imports, > and we ask people to either do it right or leave it for someone who can. > > But of course this is an exceptional situation in that many people seem > to be using the map data *now* rather than some time later when we had > the time to polish it, so it was probably good to import the data, buggy > as it is. I agree. If you can provide a better import, why not just do it (may take some time of course) and revert the old import then? Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Potlatch 1.3d: Impoved Haiti crisis support
I've commited Potlatch 1.3d, this release adds better support for mapping in Haiti: * Adding DigitalGlobe layer to presets * Now with 2 GeoEye layers: GravityStorm's and the NYPL extended coverage * Pressing B with GeoEye/DigitalGlobe (and NearMap) layers now adds the correct source=* tag to elements * Added GeoEye and digitalglobe to source=* tag autocompletion (See http://trac.openstreetmap.org/changeset/19544 for the commit) It's just in SVN now, I have no idea when it'll be on http://openstreetmap.org/edit ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: > Am 16.01.2010 10:16, schrieb Carsten Moeller: >> Yes, I do agree. We should have tags describing short and long >> distances. The latter is possibly best expressed by using relations. >> Yes, there are already tags for our problem: >> >> highway=service >> amenity=ferry_terminal (if it allows cargo=vehicle) >> ferry route (as tagged and displayed already on the maps) >> amenity=ferry_terminal (again with cargo=vehicle) >> highway=service >> >> But this kind of tagging is hardly parsable. In case of routing, I don't >> want to collect all highway=service in the topo. > > Sorry to say, if you don't take highway=service ways into account, your > whole routing program gets very certainly a lot less useful to a lot of > end users anyway. > >> For route=ferry or >> rail=railway I can distinguish if they are subtagged by motorcar=true or >> not. As a consequence the highway=service then should be subtagged with >> sth. like "ferry-link". But this guides me to my first approach again. >> In my opinion, it should be as simple as possible. > > That's true. But it should be as simple as possible for the mappers (as > long as it's somehow usable for routers) :-) > > If you say "the mappers have to improve tagging, otherwise I won't be > able to write a router" I'd say "write a better router". It's not > because I don't like you, it's because I know that half of the mappers > won't do it anyway and you'll just end up with a router not working in a > lot of situations. > >> I'm afraid, only few >> people will follow this tagging pattern and we'll end up in a forest. > > That's no news, regardless of what we'll discuss here ;-) > >> Once again, the main problem is the parsing itself. In case of the upper >> example you will have to analyze relations in a second step. If you >> tagged them directly It's just a one shot parsing. > > If you don't want to analyze relations, you will also miss other > required stuff (e.g. turn restrictions). A router not analyzing > relations has no future IMHO. > >> Another problem, as I've already mentioned before, are the connections >> (even same nodes) between railroads and streets. This is a annoying and >> kills the ability for OSM to route satisfyingly. > > No, it doesn't ;-) > > Regards, ULFL Oh dear, don't remind me of the turning restrictions ~~~ This is another non fitting pair of shoes ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extended GeoEye imagery now available for use on OSM
On Fri, Jan 15, 2010 at 8:23 PM, Schuyler Erle wrote: > * On 15-Jan-2010 at 6:32PM EST, Ævar Arnfjörð Bjarmason said: > > > > I just meant to mirror them to something faster than the Google > > server (the OSM cluster should get ~30MB/s from cassini). > > > > It would be better if someone else could set up the actual tile/wms > serving. > > I'm working on that now, hope to have something up by morning! > > Do we still need tile cutting CPU? I have a box donated for the next couple days if there is a need. If not, I will give it back. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
I think the main part that has to be done here is that ferries, or motorails however as well aerialways get connected to the main road network using lines (routing over polygons is so complicated that no router will soon master it in a useful way). How they are connected should be dependant on the transport mode to use. Image huge ferries with different, but consistent places to enter. We could have highway=footway & pier=yes (or similar)for pedestrians entering the ferry (this is actually one of the rare cases I like to see footway and not path), highway=service & motorcycle=yes & foot=no & bicycle=yes highway=service & access=no & motorcar=yes & hgv=yes And the ferry route should connect all three. Another example would be a cable_car. We should have highway=footway (or another key) to connect the street network to the cable_car. If there are steps inside the building, well then lets add a section highway=steps.. The principle should be no matter what kind of line there is that can be used somehow, it should be interconnected with all other transport usable lines. This means that we should also connect railways to roads, because otherwise no autorouter can calculate routes using busses and trains (with walking from one to another) for example. Only airports I would rather just connect by having a relation list to which other airports you can get from airport XY. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Call to map : Help Albania with the flooding of Skoder!
On Sat, 16 Jan 2010 17:57:04 +0100, jamesmikedup...@googlemail.com wrote: > We should help build a map for the relief effort like the Haiti! I'll be glad to help, are you getting some high-res satellite images? Are there people who could get high-res images of Albania? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Using editors to indicate license preference.
Currently there is a lot of debate over licenses, some people want to change from cc-by-sa to odbl and yet others keep pushing for things to go to public domain. I was chatting with one such person in favour of PD on the phone yesterday about this, one thought that occurred to me was to have data tagged with license information, editors could potentially go about this in a number of ways, explicitly tagging nodes, ways and relations with the license chosen by the user, eg data:license=public_domain, and warning PD advocates if they edit CC-BY-SA/ODBL information and that the changes won't be public domain. When a person explicitly wants ODBL/CC-BY-SA the license could be updated or stripped if it matches the OSM default. Alternatively the changeset could be tagged, but this would be a lot more difficult for editors to "know" what is PD and what isn't if the changeset contains a mix of both. While I personally favour a share alike type license, some don't and this might be a way to make the majority of people happier. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Haiti Field requirement: Haiti OSM maps in PDF
Hi there. Below a post on the topic getting Haiti OSM maps in PDF for direct use in the field and circulation in fora such as relief web. It has just been highlighted as a strong Haiti requirements from GIS responders working in Haiti "Top 1 Fied Requirement: ready to print maps ArchD size (24" x 36")" Best N -- Forwarded message -- From: Mikel Maron Date: Sun, Jan 17, 2010 at 1:49 AM Subject: Re: Haiti OSM map To: Jochen Plumeyer , nicolas chavent < nicolas.chav...@gmail.com>, Andrew Turner , Jonas Krückel Nicolas, Andrew, Jonas Can one of you pass along Jochen's request below ... nice PDFs and non-paved roads. One of the outputs we eventually want to have for HOT are nice PDFs for distribution through reliefweb, etc. Perhaps someone in the OSM or crisismapping community can pick up these threads Thanks Mikel -- *From:* Jochen Plumeyer *To:* Mikel Maron *Sent:* Sat, January 16, 2010 6:37:33 PM *Subject:* Re: Haiti OSM map > Anything in particular we can do on the mapping side? A super non-geek approved product would be a size-optimized PDF of the complete zone between border (including Jimaní and Pedernales) and the zone until Jacmel in the south, including all street names. I tried to produce that with osmarender, but it takes hours to calculate, seems it is not the right render tool. But the size ratio with osmarender is very good, with my tests with smaller *.osm files the ratio was about PDF size = OSM size / 8 Which means, that you can use as well low-RAM smartphones, older webpads etc. to display that map, without the need of connectivity. And any other device which can display PDF. The OCHA site has some PDF a bit like this, but not with every street name. And to give it a double oscar, having an optional coordinate grid would me great, or displaying the current mouse coordinate with JavaScript or something in the PDF viewer (Adobe includes JS, Flash AFAIK). I am no render guru, perhaps I used the wrong tool. The other thing is tracing of alternative streets to get into the city without traffic-jams. So, it would be good to have "possible 4x4 roads", without using the two bridges, I don't know if that is feasible, it should be coordinated together with the helpers here, perhaps I could do something about it. Cheers for now, take care! Jochen -- Nicolas Chavent Humanitarian OpenStreetMap Team http://wiki.openstreetmap.org/wiki/WikiProject_Haiti Mobile (FRA): +33 6 75 14 29 70 Email: nicolas.chav...@gmail.com Skype: c_nicolas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Haiti Field requirement: Haiti OSM maps in PDF
Hi, nicolas chavent wrote: > Below a post on the topic getting Haiti OSM maps in PDF for direct use > in the field and circulation in fora such as relief web. It has just > been highlighted as a strong Haiti requirements from GIS responders > working in Haiti > "Top 1 Fied Requirement: ready to print maps ArchD size (24" x 36")" PNGs suitable for large (!) printouts are already at http://labs.geofabrik.de/haiti/large-png-maps/. I have also e-mailed Jochen Plumeyer separately asking for specific PDF requirements. He seems to desire small and simple PDFs and this is something neither Osmarender nor Mapnik are very good at - you tend to get giant PDFs that take ages to render even on a proper PDF viewer. If someone has time on their hands they could try to create a really simplistic map style for either Mapnik or Osmarender taht would only show the bare minimum required on the ground (e.g. no road casings etc) - it might be possible to create simple PDFs with that then. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Haiti Field requirement: Haiti OSM maps in PDF
Walking papers make easy (regular paper sized prints) and its a quick PDF. The png file can be saved as a PDF, but ya, its a big file. I have a link to it on the wiki i did yesterday (needs updating) Sam On 1/16/10, Frederik Ramm wrote: > Hi, > > nicolas chavent wrote: >> Below a post on the topic getting Haiti OSM maps in PDF for direct use >> in the field and circulation in fora such as relief web. It has just >> been highlighted as a strong Haiti requirements from GIS responders >> working in Haiti >> "Top 1 Fied Requirement: ready to print maps ArchD size (24" x 36")" > > PNGs suitable for large (!) printouts are already at > http://labs.geofabrik.de/haiti/large-png-maps/. I have also e-mailed > Jochen Plumeyer separately asking for specific PDF requirements. > > He seems to desire small and simple PDFs and this is something neither > Osmarender nor Mapnik are very good at - you tend to get giant PDFs that > take ages to render even on a proper PDF viewer. If someone has time on > their hands they could try to create a really simplistic map style for > either Mapnik or Osmarender taht would only show the bare minimum > required on the ground (e.g. no road casings etc) - it might be possible > to create simple PDFs with that then. > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
