Re: [OSM-talk] place=country/nation/state
Robin Paulson wrote: > i was looking for a tag to name new zealand, and it appears there are > no tags for places at this high level, at least in potlatch, or here: > > http://wiki.openstreetmap.org/index.php/Key:place > > is there any consensus on this? > > has anyone made any attempt to distinguish between nation, state, > country, etc. in the context of osm? > > wp has some info, but that left me somewhat bewildered > > http://en.wikipedia.org/wiki/Country > > would this be a better place to start? > > http://en.wikipedia.org/wiki/List_of_sovereign_states > > i think the 'place' key will need some expanding, or am i missing > something obvious? http://wiki.openstreetmap.org/index.php/Key:is_in But this is just as uncontrolled as place :( We *NEED* a proper hierarchy for the boundary structures! A simple UNIQUE way to identify where the we are in the world ;) So North Island and South Island - is_in New Zealand and Auckland and Wellington is_in North Island ( And perhaps New Zealand is_in South Pacific ? ) I've been glancing at a few of the recent links on the list and then having no idea where I am looking :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions
Alex Mauer wrote: > I've added a decision tree to the physical section of the page, as well > as removed the "boulevard" designation (since it didn't really add much) > > I'd like to have some more comments from the UK and german end, as to > whether or not A and B roads (and others?) fit into the highway:admin > scheme. > > Again, the proposal location is: > http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions :admin is appropriate for the UK - but not laid out as it is at present. Motorways may be under different administration to the 'Highways Agency' and the 'Highways Agency' is also responsible for other main roads, but private companies will actually be responsible for managing those roads. Basically WHO admins a road is a bit of a lottery, so trying to create a simple list as currently proposed is wrong for the UK :( :admin SHOULD be the company responsible for maintaining the road. :physical simply adds complications without actually fixing anything. Trying to add _almost and _twolane does not provide ANY useful information, and a UK dual_carriageway is unlikely to have shoulders. Infact HAVING hard shoulders is part of the definition that makes it a motorway, and may result in it being A...(M) - OK a motorway_almost except that the A1(M) has three lanes in areas. So it does not fit the decision tree and if it does not have two lanes why is it a (motorway_twolane) ? it's motorway_singlelane but then it would probably not be a motorway ) Yes I know I should put this on the talk page - but I can't get in at the moment :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] New Lakewalker JOSM plugin release
A new version of the lakewalker plugin is now available. This release features a substantial change to the original plugin that Brent Easton put together to interface with Daryl Shpak's python script, in that the actual work of the plugin has been ported to Java and included within the plugin. This means that the Python script is no longer required, and should allow easier use. The native Java version also runs substantially faster, and doesn't get stuck in loops as often as the Python version did. The python script can still be used (via a second menu item) if you already have it installed however. There is one setting change that must be made to use the Java only version, in that the threshold value must be increased (around 90-110 seems to be suitable) due to differences between what Java and Python report the intensity of grey being. You can download the updated plugin via the interface in JOSM, or directly from http://svn.openstreetmap.org/applications/editors/josm/dist/Lakewalker.jar - Jason Reid Web Technical Administrator Faculty of Social Sciences University of Calgary Social Sciences 515 403-220-7903 - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos on Linux
On Mon, 2008-02-18 at 12:52 +0100, Igor Brejc wrote: > Hello Frederik, > > I used the Linux image from the Mono site which has all of the mono > components already included, so I'm not exactly sure what components > are needed. Do you have the latest version of Mono (1.2.6)? > The exception thrown looks like indicating that ToolTip:Hide isn't > implemented in Mono. I can perhaps comment out the code for > showing/hiding tool tips so that you can test it. Unfortunately this > will have to wait, because I have some problems with my home machine > hard disk and will probably have to reinstall Windows before > continuing any developing (the penalty of not doing regular system > drive backup, I suppose). > If you manage to solve this some other way, please send me a note. Hardy with Mono 1.2.6 is fine, except that's it's pretty ugly (windows forms aren't going to look good) and very slow. -- Bruce Cowan <[EMAIL PROTECTED]> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] place=country/nation/state
El Lunes, 18 de Febrero de 2008, Martin Trautmann escribió: > NUTS is ok for certain statistical classification - but it may add on > one hand levels just by population which will cause splits which are not > known within the country itself. OK, let's skip those extra levels altogether. For example: here in Spain, the NUTS1 level is an artificial classification. Nobody in spain would use that. > On the other hand the split of NUTS may follow the same structures which are > given within the country - but they will add abbreviations which are still > not known within the country. I'm not talking about using NUTS for naming - my point is, we could use the NUTS levels to define a consistent territorial division tagging scheme. [...] > That's why the [[OpenGeoDB]] has three approaches here: > > first: a basic static classification system by levels which may be > filled more or less completely: > DEAT CH > country en:Germanyen:Austria en:Switzerland > de:Deutschlandde:Österreich de:Schweiz > state BundeslandBundesland Kanton > gov. regionRegierungsbezirk - - > district Landkreis Bezirk Bezirk > officesAmt > municipality Gemeinde Gemeinde Gemeinde So, why not drop "country/state/district/office" altogether and use an abstract denomination? (That doesn't mean that local classification levels couldn't be used: something like "admin=es:provincia" would equal "admin=abstract_level_3") Cheers, -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> Proudly running Debian Linux with 2.6.24-1-amd64 kernel, KDE 3.5.8, and PHP 5.2.5-2 generating this signature. Uptime: 01:51:52 up 4 days, 13:27, 2 users, load average: 0.97, 0.84, 0.69 signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Rendering Quarries
On Feb 18, 2008 7:39 PM, Karl Eichwalder <[EMAIL PROTECTED]> wrote: > landuse=quarry > >|- -| >|- -| >|- -| >|- -| >|- -| I would like those "saw tooth" lines to signify a steep cliff as well, would be nice to be able to paint cliffs on walking maps. -- /emj ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Move tagging RfCs/voting to extra list?
[EMAIL PROTECTED] wrote: What topics would be useful? Is [tagging] in the Subject: header what's wanted just now? [RFC], [voting]? -- Było mi bardzo miło. Czwarta pospolita klęska, [...] >Łukasz< Już nie katolicka lecz złodziejska. (c)PP -- Myslisz, ze nie ma sniegu? Sprawd� gdzie mozesz poszusowac na nartach >>> http://link.interia.pl/f1cfb begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
Tom Hughes wrote: In message <[EMAIL PROTECTED]> Lukasz Stelmach <[EMAIL PROTECTED]> wrote: Tom Hughes wrote: Indeed. I think the problem is that he is reading a page that documents the HTTP API and expecting it to tell him the format of a JOSM change file. No, I was reading the page about HTTP API *and* OSM format which reads For each of the above-mentioned object types, the API supports these CRUD operations (replace by one of node, way, relation; ***replace by the id of the object in question***): And I ask: what is the value of the `id' attribute of the object in question when the ID hasn't been assigned yet? Today I know the answer but I am afraid anyone who seeks the answer to that question will focus on this paragraph trying to figure out where to get a new ID from. The DTD saing `id' is required makes this desire even stronger while giving no hint at all. The row of the table that covers creation of new objects (the first row) does not have an marker to replace, so the question does not arise. But the DTDs on the page require `id'. You are trying to extend the meaning of that paragraph, which covers the RESTful URLs to the OSM file format as use by JOSM which is not something that page describes. But the JOSM file format is just an extension of the format described on the page. When I mentioned sniffing JOSM I meant sniffing the transmiton over the wire which uses the format described on the page. All that page describes is the URLs you should call and the XML you should pass to them and/or expect to get back from them. Let me repeat onece more: * the DTDs say IDs are *required* * no paragraph or a single sentence says what values to put in the XML for objects we are creating. -- Było mi bardzo miło. Czwarta pospolita klęska, [...] >Łukasz< Już nie katolicka lecz złodziejska. (c)PP -- Masz ostatnia szanse ! Sprawdz >>> http://link.interia.pl/f1d02 begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] updated RFC: Highway administrative and physical descriptions
I've added a decision tree to the physical section of the page, as well as removed the "boulevard" designation (since it didn't really add much) I'd like to have some more comments from the UK and german end, as to whether or not A and B roads (and others?) fit into the highway:admin scheme. Again, the proposal location is: http://wiki.openstreetmap.org/index.php/Proposed_features/Highway_administrative_and_physical_descriptions ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
On 19/02/2008, Christoph Eckert <[EMAIL PROTECTED]> wrote: > Hi, > > > Sadly, it seems to be frozen in a proposal state forever and is therefore > > not rendered on the two main maps yet. > > so why not open it for voting? I've mapped some and would vote for it :) . for consistency, this would be better moved into the 'building' proposal, another tag which has sat for far too long maybe as an interim we could add shelter as a separate tag, and then make it obsolete later if the building tag ever gets completed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Osmosis and Bounding Boxes
On Feb 18, 2008 1:47 PM, Stuart Poulton <[EMAIL PROTECTED]> wrote: > Hi, > > No problems with the usage of multiple bounding boxes, infact in this case > 14 of them. Each one output to a single file. > Looks like the simplest solution may be to have a 15th polygon and output > this to a final file. > > Cheers > > Stuart > > > On 18 Feb 2008, at 21:42, Gregory wrote: > > I've heard you can only do one bounding box and nothing clever. > > On 18/02/2008, Stuart Poulton <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > > > Can anyone advise. > > > > If I'm extracting a series of bounding boxes to seperate files, can I > > also extract the entire area to one file at the same time ? > > > > I'm currently using. > > > > ../osmosis-0.24/bin/osmosis --read-xml file="../planet-080102.osm.bz2" \ > > --tee 3 \ > > --bounding-box top="60.85" bottom="58.70" left="-3.50" right="-0.75" \ > > --bounding-box top="58.70" bottom="55.50" left="-8.00" right="-5.00" \ > > --bounding-box top="58.70" bottom="55.50" left="-5.00" right="-1.50" \ > > --write-xml file="Grid0.osm" \ > > --write-xml file="Grid1.osm" \ > > --write-xml file="Grid2.osm" \ > > > If your goal is to have the results of all three bounding boxes in one file, you could tee the output of each bounding box, write one to a file, then pass the other to a merge task, then write out that merged set. It would be a complex command line but it should be possible. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
Hi, > Sadly, it seems to be frozen in a proposal state forever and is therefore > not rendered on the two main maps yet. so why not open it for voting? I've mapped some and would vote for it :) . Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Durham Mapping Party
I've set a date for a Durham mapping party. 7&8th June. http://www.livingwithdragons.com/2008/02/mapping-party-for-durham http://wiki.openstreetmap.org/index.php/Durham_mapping_party I seem to remember a few people wanting an excuse to come up to this beautiful city in the North of England (World Heritage Site, lots of sun & countryside, cobbled streets, dragonville, cathedral, castle, etc. etc.). If your scared that it's too far North from the watford gap, don't worry due to the uni most people are southerners and it shouldn't be so cold by June. I've put a request on http://wiki.openstreetmap.org/index.php/GPS_Units_for_Loan but may need a lot of help getting them up here if they're far away (confined to public transport, student budget, and lecture timetable). -- Gregory [EMAIL PROTECTED] http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
Am Montag, 18. Februar 2008 17:18:37 schrieb Andy Allan: > Ask and ye shall, eventually, receive. The OSM cycle map now displays > contours. > > http://www.gravitystorm.co.uk/shine/archives/2008/02/18/one-leg-longer-than >-the-other/ > http://www.gravitystorm.co.uk/osm/?zoom=13&lat=6746094.87258&lon=-372688.39 >9&layers=B00 > > etc. > > Contours appear progressively from z9+, and go all spangly and > multicoloured at z12+. Happy to discuss them if people are interested > in how it's done. > > Many thanks to Dave (randomjunk) for helping with this, and for > putting up with me making the map take just under 10 times longer to > render now than it did last week! > > Cheers, > Andy Absolutely great! The cycle map is my favorite OSM map at the moment and I'm actively tagging our regional cycle network now - I don't think I would do that consequently if there wasn't a map that renders it properly. :-) What do you think about rendering amenity:shelter on the highest zoom level(z13)? I thinnkthis could be useful on a cycle map and there are already many of these features in OSM. Sadly, it seems to be frozen in a proposal state forever and is therefore not rendered on the two main maps yet. -Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Osmosis and Bounding Boxes
Hi, No problems with the usage of multiple bounding boxes, infact in this case 14 of them. Each one output to a single file. Looks like the simplest solution may be to have a 15th polygon and output this to a final file. Cheers Stuart On 18 Feb 2008, at 21:42, Gregory wrote: I've heard you can only do one bounding box and nothing clever. On 18/02/2008, Stuart Poulton <[EMAIL PROTECTED]> wrote: Hi All, Can anyone advise. If I'm extracting a series of bounding boxes to seperate files, can I also extract the entire area to one file at the same time ? I'm currently using. ../osmosis-0.24/bin/osmosis --read-xml file="../ planet-080102.osm.bz2" \ --tee 3 \ --bounding-box top="60.85" bottom="58.70" left="-3.50" right="-0.75" \ --bounding-box top="58.70" bottom="55.50" left="-8.00" right="-5.00" \ --bounding-box top="58.70" bottom="55.50" left="-5.00" right="-1.50" \ --write-xml file="Grid0.osm" \ --write-xml file="Grid1.osm" \ --write-xml file="Grid2.osm" \ Cheers Stuart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk -- Gregory [EMAIL PROTECTED] http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Slippy map - clickable POI
Ah silly me, I should of known about googlemail/gmail. Thanks. On 18/02/2008, Andy Robinson (blackadder) <[EMAIL PROTECTED]> wrote: > > Gregory wrote: > >Sent: 18 February 2008 8:01 PM > >To: talk@openstreetmap.org > >Subject: [OSM-talk] Slippy map - clickable POI > > > >I tried posting this to dev but I get told I'm not a member (despite > >getting dev messages, and when subscribing to dev I get told I'm already > a > >member). Feel free to forward to dev... > >- > > I had this problem because I was using gmail.com when I had in fact > subscribed with googlemail.com > > The lists don't treat these as the same email address, but google does > > Cheers > > Andy > > -- Gregory [EMAIL PROTECTED] http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Osmosis and Bounding Boxes
I've heard you can only do one bounding box and nothing clever. On 18/02/2008, Stuart Poulton <[EMAIL PROTECTED]> wrote: > > Hi All, > > Can anyone advise. > > If I'm extracting a series of bounding boxes to seperate files, can I also > extract the entire area to one file at the same time ? > > I'm currently using. > > ../osmosis-0.24/bin/osmosis --read-xml file="../planet-080102.osm.bz2" \ > --tee 3 \ > --bounding-box top="60.85" bottom="58.70" left="-3.50" right="-0.75" \ > --bounding-box top="58.70" bottom="55.50" left="-8.00" right="-5.00" \ > --bounding-box top="58.70" bottom="55.50" left="-5.00" right="-1.50" \ > --write-xml file="Grid0.osm" \ > --write-xml file="Grid1.osm" \ > --write-xml file="Grid2.osm" \ > > > > > Cheers > > Stuart > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > -- Gregory [EMAIL PROTECTED] http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
In message <[EMAIL PROTECTED]> Lukasz Stelmach <[EMAIL PROTECTED]> wrote: > Tom Hughes wrote: > > > Indeed. I think the problem is that he is reading a page that > > documents the HTTP API and expecting it to tell him the format > > of a JOSM change file. > > No, I was reading the page about HTTP API *and* OSM format which reads > > For each of the above-mentioned object types, the API supports > these CRUD operations (replace by one of node, way, > relation; ***replace by the id of the object in > question***): > > And I ask: what is the value of the `id' attribute of the object in > question when the ID hasn't been assigned yet? Today I know the > answer but I am afraid anyone who seeks the answer to that question > will focus on this paragraph trying to figure out where to get a new > ID from. The DTD saing `id' is required makes this desire even > stronger while giving no hint at all. The row of the table that covers creation of new objects (the first row) does not have an marker to replace, so the question does not arise. You are trying to extend the meaning of that paragraph, which covers the RESTful URLs to the OSM file format as use by JOSM which is not something that page describes. All that page describes is the URLs you should call and the XML you should pass to them and/or expect to get back from them. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] User umehlig and some really nasty edits
Tom Hughes wrote: In message <[EMAIL PROTECTED]> Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: On Feb 10, 2008 10:51 PM, Lukasz Stelmach <[EMAIL PROTECTED]> wrote: All right I confess. I have done something like that to the node 300 a while ago. But while you are considering some solutions to this problem allow me to explain myself. I tried to find out how to create and upload osm file by hand (i like vi that myuch ;) But there is no single word written here http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5 on how to obtain or create new id. It is described how to create an object but not how to choose an id for it. As far as I can tell it says it right here: http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5#Basic_Methods_for_Object_Access_and_Manipulation To create you use PUT and it returns an ID. Indeed. I think the problem is that he is reading a page that documents the HTTP API and expecting it to tell him the format of a JOSM change file. No, I was reading the page about HTTP API *and* OSM format which reads For each of the above-mentioned object types, the API supports these CRUD operations (replace by one of node, way, relation; ***replace by the id of the object in question***): And I ask: what is the value of the `id' attribute of the object in question when the ID hasn't been assigned yet? Today I know the answer but I am afraid anyone who seeks the answer to that question will focus on this paragraph trying to figure out where to get a new ID from. The DTD saing `id' is required makes this desire even stronger while giving no hint at all. -- By?o mi bardzo mi?o. Czwarta pospolita kle;ska, [...] >?ukasz< Juz. nie katolicka lecz z?odziejska. (c)PP -- Masz ostatnia szanse ! Sprawdz >>> http://link.interia.pl/f1d02 begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Slippy map - clickable POI
Gregory wrote: >Sent: 18 February 2008 8:01 PM >To: talk@openstreetmap.org >Subject: [OSM-talk] Slippy map - clickable POI > >I tried posting this to dev but I get told I'm not a member (despite >getting dev messages, and when subscribing to dev I get told I'm already a >member). Feel free to forward to dev... >- I had this problem because I was using gmail.com when I had in fact subscribed with googlemail.com The lists don't treat these as the same email address, but google does Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] [tagging] RFC - new key - historic=wreck
Greetings all, I proposed a new feature historic=wreck a while back but I forgot to send it out on the mailing list. http://wiki.openstreetmap.org/index.php/Proposed_features/wreck Please leave your comments on the wiki page. Regards, Tim (TimSC) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Osmosis and Bounding Boxes
Hi All, Can anyone advise. If I'm extracting a series of bounding boxes to seperate files, can I also extract the entire area to one file at the same time ? I'm currently using. ../osmosis-0.24/bin/osmosis --read-xml file="../planet-080102.osm.bz2" \ --tee 3 \ --bounding-box top="60.85" bottom="58.70" left="-3.50" right="-0.75" \ --bounding-box top="58.70" bottom="55.50" left="-8.00" right="-5.00" \ --bounding-box top="58.70" bottom="55.50" left="-5.00" right="-1.50" \ --write-xml file="Grid0.osm" \ --write-xml file="Grid1.osm" \ --write-xml file="Grid2.osm" \ Cheers Stuart___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] place=country/nation/state
Iván Sánchez Ortega wrote: > I really like the NUTS system, as it is politically neutral, and balanced > between different countries. IMHO, OSM should have a similar classification > system. NUTS is ok for certain statistical classification - but it may add on one hand levels just by population which will cause splits which are not known within the country itself. On the other hand the split of NUTS may follow the same structures which are given within the country - but they will add abbreviations which are still not known within the country. This does conflict with existing levels within the country. Take e.g. Germany and Austria. They use hierarchical number systems, such as 01 Schleswig-Holstein (a federal state in Germany, two digits, 16 states) 01001 Flensburg (a district / Landkreis, here the northmost in Germany, five digits) 01001000 Flensburg (the community / Gemeinde - here the same as the town) The German system is called "Amtlicher Gemeindeschlüssel", the Austrian is "Gemeindeschlüssel". Switzerland and Belgium use different, hierarchical level number systems and levels. > The downside of NUTS is that it is only well-defined for the EU. For the rest > of the world countries, a parallel classification would be needed. > > Anybody care to draft something for a feature proposal? There are both for language and country the proper ISO standards. For levels below I suppose that you have to adopt each national system. That's why the [[OpenGeoDB]] has three approaches here: first: a basic static classification system by levels which may be filled more or less completely: DEAT CH country en:Germanyen:Austria en:Switzerland de:Deutschlandde:Österreich de:Schweiz state BundeslandBundesland Kanton gov. regionRegierungsbezirk - - district Landkreis Bezirk Bezirk officesAmt municipality Gemeinde Gemeinde Gemeinde ... second: the (optional) type name, such as "Amt", "Verwaltungsgemeinschaft", "Stadt", ... third: a "part of" relation, what is part of what - Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] place=country/nation/state
Robin Paulson wrote: > i was looking for a tag to name new zealand, and it appears there are > no tags for places at this high level, at least in potlatch, or here: > > http://wiki.openstreetmap.org/index.php/Key:place > > is there any consensus on this? What makes a city does differ from country to country. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Slippy map - clickable POI
I tried posting this to dev but I get told I'm not a member (despite getting dev messages, and when subscribing to dev I get told I'm already a member). Feel free to forward to dev... - Hi all, I've been trying to work on using OSM in cool/new ways, but only been able to dip into it now and then due to other commitments. I've created an openlayers slippy map here (the tiles are via kosmos): http://www.livingwithdragons.com/maps/slippytest.php And if you click on any of the pub symbols, you get a pop up (well text displaying at the side on the page would be nicer, but I rekon I can figure that out). Thing is if you look at the code(line 70+) you'll see I'm manually entering in the lat/lon box where each symbol appears. Not ideal, especially when the POI are in the map data. Is there already an existing easy way to do what I'm attempting? It probably helps that: -I expect only to be rendering the map on command -To render it I use JOSM and create a durham.osm file of the area, so not the whole planet. -- Gregory [EMAIL PROTECTED] http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Rendering Quarries
On 19/02/2008, Karl Eichwalder <[EMAIL PROTECTED]> wrote: > I'd really like you to render quarries. In mapnik, some kind of orange with > an outer line with stingers pointing inwards would be fine. landuse=quarry > is listed on the feature map: > > >+-+ >| ||| | >|- -| >|- -| >|- -| >|- -| >|- -| >+-| > + || | > +---+ > > I hope, you get the idea :-) If that's too complicate anything without > the stingers is fine. this has gone through several discussions under different tags - currently it's being debated under the surface mine tag proposal. if you'd like to add your opinion, please do: http://wiki.openstreetmap.org/index.php/Proposed_features/surface_mine ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
On 19/02/2008, Andy Allan <[EMAIL PROTECTED]> wrote: > Ask and ye shall, eventually, receive. The OSM cycle map now displays > contours. > > http://www.gravitystorm.co.uk/shine/archives/2008/02/18/one-leg-longer-than-the-other/ > http://www.gravitystorm.co.uk/osm/?zoom=13&lat=6746094.87258&lon=-372688.399&layers=B00 > > etc. > > Contours appear progressively from z9+, and go all spangly and > multicoloured at z12+. Happy to discuss them if people are interested > in how it's done. > > Many thanks to Dave (randomjunk) for helping with this, and for > putting up with me making the map take just under 10 times longer to > render now than it did last week! great stuff, looks stunning are there any profiling tools anywhere, for giving a cross-section through the map along the path taken, showing climb over distance? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Rendering Quarries
I'd really like you to render quarries. In mapnik, some kind of orange with an outer line with stingers pointing inwards would be fine. landuse=quarry is listed on the feature map: +-+ | ||| | |- -| |- -| |- -| |- -| |- -| +-| + || | +---+ I hope, you get the idea :-) If that's too complicate anything without the stingers is fine. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On 19/02/2008, Andy Allan <[EMAIL PROTECTED]> wrote: > Gaaarrgggh! > > Deliberately tagging things incorrectly is bad practice. There are so > many renderers out there that if what you do works for more than one > of them that's just coincidence. And when bad practices like this > become entrenched it becomes a complete mess when the renderer > eventually gets improved, as they always do. a good point. didn't microsoft force this kind of practice in the 90s, with a non-compliant web browser? we're still paying for that mess now now if only there was a w3c equivalent for osm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
On 18/02/2008, Andy Allan <[EMAIL PROTECTED]> wrote: > Ask and ye shall, eventually, receive. The OSM cycle map now displays > contours. Fantastic work. Thank you Andy :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
On Mon, 2008-02-18 at 16:18 +, Andy Allan wrote: > Ask and ye shall, eventually, receive. The OSM cycle map now displays > contours. > > http://www.gravitystorm.co.uk/shine/archives/2008/02/18/one-leg-longer-than-the-other/ > http://www.gravitystorm.co.uk/osm/?zoom=13&lat=6746094.87258&lon=-372688.399&layers=B00 > > etc. > > Contours appear progressively from z9+, and go all spangly and > multicoloured at z12+. Happy to discuss them if people are interested > in how it's done. > > Many thanks to Dave (randomjunk) for helping with this, and for > putting up with me making the map take just under 10 times longer to > render now than it did last week! This is great! Any chance of a write up on how you did this? Thanks, Keith. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On Monday, 18 February 2008 16:01:46 +, 80n <[EMAIL PROTECTED]> writes: > It's definitely wrong to adjust the layer just to make the rendered output > look better. If a renderer has deficiencies use render-specific tags to solve them ... until the renderer is fixed to make these tags obsolete. > The layer tag should represent the true relative position of roads. > > Incidentally, if a ramp connects two roads at different levels then should > it be layer=0 at one end and layer=1 at the other, with the split somewhere > in the middle? I don't see how else you can correctly represent a ramp. IMHO: No, the ramp does not need a split to tag different layer values, only the crossing ways needs tags with different layer value. On the other hand: a ramp can be subclassified as "exit ramp" or "entrance ramp" of a road. If a ramp is both because it connects two motorways etc., you can split the ramp into an exit ramp part and an entrance ramp part. Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
On 18 Feb 2008, at 16:18, Andy Allan wrote: > Ask and ye shall, eventually, receive. The OSM cycle map now > displays contours. > > http://www.gravitystorm.co.uk/shine/archives/2008/02/18/one-leg- > longer-than-the-other/ > http://www.gravitystorm.co.uk/osm/? > zoom=13&lat=6746094.87258&lon=-372688.399&layers=B00 > > etc. > > Contours appear progressively from z9+, and go all spangly and > multicoloured at z12+. Happy to discuss them if people are interested > in how it's done. > > Many thanks to Dave (randomjunk) for helping with this, and for > putting up with me making the map take just under 10 times longer to > render now than it did last week! Very nice! Very useful addition to cycle maps. Congrats, Andy and Dave! > > Cheers, > Andy > Artem > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Contours on the Cycle Map
Andy Allan wrote: >Sent: 18 February 2008 4:19 PM >To: OSM Talk >Subject: [OSM-talk] Contours on the Cycle Map > >Ask and ye shall, eventually, receive. The OSM cycle map now displays >contours. > Mega awesome of awsomeness Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Contours on the Cycle Map
Ask and ye shall, eventually, receive. The OSM cycle map now displays contours. http://www.gravitystorm.co.uk/shine/archives/2008/02/18/one-leg-longer-than-the-other/ http://www.gravitystorm.co.uk/osm/?zoom=13&lat=6746094.87258&lon=-372688.399&layers=B00 etc. Contours appear progressively from z9+, and go all spangly and multicoloured at z12+. Happy to discuss them if people are interested in how it's done. Many thanks to Dave (randomjunk) for helping with this, and for putting up with me making the map take just under 10 times longer to render now than it did last week! Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On Mon, Feb 18, 2008 at 11:51:38AM +, Steve Chilton wrote: > > What a professional road atlas would do here is very likely to exaggerate > > the junction so that it makes sense given the width using to render the > > roads. Doing this algorithmically is hard, but probably not impossible. > that sounds very bad, ugly and wrong on many levels. > whether it's mapped as 'exaggerated' or algorithmically altered later, > i can't see the point. if there's room in reality for the roads to > exist without overlapping, then there's no reason the map can't > reflect that Sure there is a reason : the legibility of small features. Assume a standard motorway map with scale 1cm:2km. A road that is 20m wide would show up as 1/100cm = 0.1mm. No one would be able to see that without a magnifying glass. That is why useable maps done by proper cartographers nearly always exaggerate features. What has happened here is that this exagerration has gong too far for zoom layer 16. Merkaartor usese a hybrid approach pixel_width_on_map = fixed_pixel_width + scale*estimated_real_width_in_m On higher zoom levels, the second component dominates, on lower zoom levels, the first component is the most important. And even than, you cannot have one set of values that works for the entire range of scales. cu bart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On Feb 18, 2008 2:50 PM, Dermot McNally <[EMAIL PROTECTED]> wrote: > On 18/02/2008, Jeremy Adams <[EMAIL PROTECTED]> wrote: > > My "fix" for the situation you linked to was to set motorway_links to > > layer=-1. This puts them underneath the main roads and makes the map look > > much nicer IMO. > > By co-incidence, I was in contact with another mapper who's been doing > something like this to make low zoom osmarender rendering a bit > prettier. What's everybody's opinion of this kind of practice? Gaaarrgggh! :-) If someone wants to monkey around with the rendering, they should use renderer-specific tags, such as mapnik-motorway=up_a_bit. We used to do something similar when osmarender was having big problems with getting the text the right way round and mapnik was coping fine - we had an osmarender-specific tag. But for most things it turns out that fixing the rendering problem is easier than getting it to recognise new tags, and so everything works out fine and things are done properly. Deliberately tagging things incorrectly is bad practice. There are so many renderers out there that if what you do works for more than one of them that's just coincidence. And when bad practices like this become entrenched it becomes a complete mess when the renderer eventually gets improved, as they always do. Cheers, Andy > Is it > not an example of compromising the data (which we want to endure) to > work around a temporary deficiency in one particular renderer? > > Dermot > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
It's definitely wrong to adjust the layer just to make the rendered output look better. The layer tag should represent the true relative position of roads. Incidentally, if a ramp connects two roads at different levels then should it be layer=0 at one end and layer=1 at the other, with the split somewhere in the middle? I don't see how else you can correctly represent a ramp. 80n On Feb 18, 2008 3:21 PM, Dermot McNally <[EMAIL PROTECTED]> wrote: > On 18/02/2008, Tom Hughes <[EMAIL PROTECTED]> wrote: > > > If the slip roads are not really underneath the other roads then > > yes it is definitely wrong (IMHO). The layer tag is meant to describe > > the physical ordering of the roads on the ground. > > > > If something isn't rendering right the solution is to fix the > > rendering not to deliberately misdescribe the data to try and > > make the rendering look prettier. > > This was very much my own view too. However, there's the basis for an > argument here. The deck of a bridge (layer=1) that spans a motorway is > probably on the same "level" as the roadways connected to it (layer=0, > usually implicit). > > The other mapper I was discussing this with is doing something that, > IMO, isn't as drastic as tagging slip roads at layer=-1. He likes to > tag the mainline of the motorway to layer=-1 for a buffer zone either > side of a bridge that spans it. You _could_ argue that it's no worse > than the bridge deck and its connections to the non-bridge roadways. > > But to me, this is all just unnecessary editing and rendering sugar > doesn't belong in the data set. The ideal thing would be if the > rendering quirks could be ironed out so that people wouldn't feel > motivated to spend their time on workarounds. Does any rendering > wizard agree? (because I wouldn't know where to start...) > > Dermot > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On 18/02/2008, Tom Hughes <[EMAIL PROTECTED]> wrote: > If the slip roads are not really underneath the other roads then > yes it is definitely wrong (IMHO). The layer tag is meant to describe > the physical ordering of the roads on the ground. > > If something isn't rendering right the solution is to fix the > rendering not to deliberately misdescribe the data to try and > make the rendering look prettier. This was very much my own view too. However, there's the basis for an argument here. The deck of a bridge (layer=1) that spans a motorway is probably on the same "level" as the roadways connected to it (layer=0, usually implicit). The other mapper I was discussing this with is doing something that, IMO, isn't as drastic as tagging slip roads at layer=-1. He likes to tag the mainline of the motorway to layer=-1 for a buffer zone either side of a bridge that spans it. You _could_ argue that it's no worse than the bridge deck and its connections to the non-bridge roadways. But to me, this is all just unnecessary editing and rendering sugar doesn't belong in the data set. The ideal thing would be if the rendering quirks could be ironed out so that people wouldn't feel motivated to spend their time on workarounds. Does any rendering wizard agree? (because I wouldn't know where to start...) Dermot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
In message <[EMAIL PROTECTED]> Dermot McNally <[EMAIL PROTECTED]> wrote: > On 18/02/2008, Jeremy Adams <[EMAIL PROTECTED]> wrote: > > > My "fix" for the situation you linked to was to set motorway_links > > to layer=-1. This puts them underneath the main roads and makes > > the map look much nicer IMO. > > By co-incidence, I was in contact with another mapper who's been doing > something like this to make low zoom osmarender rendering a bit > prettier. What's everybody's opinion of this kind of practice? Is it > not an example of compromising the data (which we want to endure) to > work around a temporary deficiency in one particular renderer? If the slip roads are not really underneath the other roads then yes it is definitely wrong (IMHO). The layer tag is meant to describe the physical ordering of the roads on the ground. If something isn't rendering right the solution is to fix the rendering not to deliberately misdescribe the data to try and make the rendering look prettier. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On 18/02/2008, Jeremy Adams <[EMAIL PROTECTED]> wrote: > My "fix" for the situation you linked to was to set motorway_links to > layer=-1. This puts them underneath the main roads and makes the map look > much nicer IMO. By co-incidence, I was in contact with another mapper who's been doing something like this to make low zoom osmarender rendering a bit prettier. What's everybody's opinion of this kind of practice? Is it not an example of compromising the data (which we want to endure) to work around a temporary deficiency in one particular renderer? Dermot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Caption competition
OJ W wrote: > The OSM cartoon has apparently become CC now: > > http://wiki.openstreetmap.org/index.php/Image:Openstreetmap_cartoon.jpg > > - would anyone like to write a caption, for use as the easter-week featured > image? > "Oh Ye'll tak the High Road, & I'll tak the Low Road, & I'll have mapped Scotland afooore ye..." Mark ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
My "fix" for the situation you linked to was to set motorway_links to layer=-1. This puts them underneath the main roads and makes the map look much nicer IMO. See here for a similar example in my area: http://openstreetmap.org/?lat=-36.97273&lon=174.81833&zoom=16&layers=B0FT -Jeremy Original Message --- i realise this isn't strictly an osm issue, concerning more the renderers, but anyway... why are roads displayed so thickly? I was looking at osm data overlaid on oam, and realised that for a lot of roads, at some zoom scales, the line is probably twice the width of the actual road. this causes problems at even simple motorway junctions, as the whole thing becomes a big blue mess. could i request this be looked into? http://openstreetmap.org/?lat=-36.97273&lon=174.81833&zoom=16&layers=B0FT is a good example, which is a very simple junction i appreciate that some motorways are two lanes each direction, and some 6; it would be nice to settle on some sort of default width (it appears to be closer to 6 at the moment) which is commonly used do any of the renderers pay attention to the number of lanes for each road and render accordingly? thanks ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] place=country/nation/state
El Lunes, 18 de Febrero de 2008, Robin Paulson escribió: > i was looking for a tag to name new zealand, and it appears there are > no tags for places at this high level, at least in potlatch, or here: > > http://wiki.openstreetmap.org/index.php/Key:place > > is there any consensus on this? > > has anyone made any attempt to distinguish between nation, state, > country, etc. in the context of osm? Yes, but with no conslusive results. We still have hamlets in the map features list. > http://en.wikipedia.org/wiki/Country > > would this be a better place to start? No. *This* is the place: http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics or http://ec.europa.eu/comm/eurostat/ramon/nuts/introannex_regions_en.html I really like the NUTS system, as it is politically neutral, and balanced between different countries. IMHO, OSM should have a similar classification system. The downside of NUTS is that it is only well-defined for the EU. For the rest of the world countries, a parallel classification would be needed. Anybody care to draft something for a feature proposal? There is also this list: http://en.wikipedia.org/wiki/Table_of_administrative_country_subdivisions_by_country Which can suggest a correlation between countries. Cheers, -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> MSN:[EMAIL PROTECTED] Jabber:[EMAIL PROTECTED] ; [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [SOLVED] Error installing OpenStreetMap
Listas escribió: > Hello, I am trying to install my own test server but when I am doing this: > > rake db:migrate VERSION=10 > > I have this error: > > (in /usr/local/osm/svn.openstreetmap.org/sites/rails_port) > ** Invoke db:migrate (first_time) > ** Invoke environment (first_time) > ** Execute environment > rake aborted! > uninitialized constant CGI::Session::SqlSessionStore > /var/lib/gems/1.8/gems/activesupport-2.0.1/lib/active_support/dependencies.rb:478:in > > `const_missing' > /var/lib/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/session_management.rb:24:in > > `const_get' > /var/lib/gems/1.8/gems/actionpack-2.0.1/lib/action_controller/session_management.rb:24:in > > `session_store=' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:328:in `send' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:328:in > `initialize_framework_settings' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:327:in `each' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:327:in > `initialize_framework_settings' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:324:in `each' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:324:in > `initialize_framework_settings' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:101:in `process' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:49:in `send' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/initializer.rb:49:in `run' > /usr/local/osm/svn.openstreetmap.org/sites/rails_port/config/environment.rb:24 > /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' > /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require' > /var/lib/gems/1.8/gems/rails-2.0.1/lib/tasks/misc.rake:3 > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `call' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `execute' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `each' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in > `invoke_with_call_chain' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in > `invoke_with_call_chain' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:518:in `invoke_prerequisites' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `send' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:515:in `invoke_prerequisites' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:507:in > `invoke_with_call_chain' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in > `invoke_with_call_chain' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in `invoke_task' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `each' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in > `standard_exception_handling' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:in `top_level' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in `run' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in > `standard_exception_handling' > /var/lib/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in `run' > /var/lib/gems/1.8/gems/rake-0.8.1/bin/rake:31 > /usr/bin/rake:19: > > Know you this error ?? > > Thank you! > I forget some instructions about SQL_session_stored. Now I have a test server installed on my systems. > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
snip: > What a professional road atlas would do here is very likely to exaggerate > the junction so that it makes sense given the width using to render the > roads. Doing this algorithmically is hard, but probably not impossible. that sounds very bad, ugly and wrong on many levels. whether it's mapped as 'exaggerated' or algorithmically altered later, i can't see the point. if there's room in reality for the roads to exist without overlapping, then there's no reason the map can't reflect that Robin That is a very naïve view of the ability of any map (unless at a scale of exactly 1:1) to show the real world in anything like it's correct geo-locations and at correct scale. All mapping is a compromise to some degree or other. Features are exaggerated according to their importance in the scheme of things. This is particularly true of roads, which are by their nature are often stacked up in close proximity to other roads, cycleways, footways, bridges, buildings, boundaries, etc. For some background - a quick Google search came up with the following, which is a piece on the Land Registry and the problems it has in interpreting features represented at various scales on the excellent Ordnance Survey maps. http://www.boundary-problems.co.uk/mapaccuracy.htm Having said that I do agree that at some of the mid-zooms in the mapnik layer the motorways are tending to coalesce at present. I will find time soon to have a look at experimenting with adjusting the widths (possibly seperating motorway_link out to separate (and thinner) styles - which they aren't at the moment). But eventually the way forward is some intelligence to allow the local and specific exaggeration/generalisation that would be done in "traditional cartography" where it is necessary. Cheers STEVE Steve Chilton, Learning Support Fellow Learning and Technical Support Unit Manager School of Health and Social Sciences Middlesex University phone/fax: 020 8411 5355 email: [EMAIL PROTECTED] http://www.mdx.ac.uk/schools/hssc/staff/profiles/technical/chiltons.asp Chair of the Society of Cartographers: http://www.soc.org.uk/ SoC conference 2008: http://www.abdn.ac.uk/cartographers08/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: 18 February 2008 10:16 To: talk@openstreetmap.org Subject: Re: [OSM-talk] displayed width of roads On 18/02/2008, Abigail Brady <[EMAIL PROTECTED]> wrote: > > line is probably twice the width of the actual road. this causes > > problems at even simple motorway junctions, as the whole thing becomes > > a big blue mess. could i request this be looked into? > > > > Well, if this isn't done, then roads quickly become hairlines at lower > zooms. There's not really much to look into. If you want to see the roads > they have to be wider than they really are. yes, they will. but i was talking about close-in zoom - the example i gave was at zoom 16. they don't have to be wider at that level, maybe at zoom 4 they do, but i wouldn't care about details like this at that zoom level anyway as i understand it, the tiles are rendered separately for each zoom level, so what we see at one zoom level is different to what we see at another ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos on Linux
Hello Frederik, I used the Linux image from the Mono site which has all of the mono components already included, so I'm not exactly sure what components are needed. Do you have the latest version of Mono (1.2.6)? The exception thrown looks like indicating that ToolTip:Hide isn't implemented in Mono. I can perhaps comment out the code for showing/hiding tool tips so that you can test it. Unfortunately this will have to wait, because I have some problems with my home machine hard disk and will probably have to reinstall Windows before continuing any developing (the penalty of not doing regular system drive backup, I suppose). If you manage to solve this some other way, please send me a note. Regards, Igor On Mon, Feb 18, 2008 at 11:30 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi Igor, > >thanks for building a Linux version! > > On my machine (Ubuntu Gutsy) it starts up, but when I open a project, > after displaying "Loading..." for a while, the program quits with the > following message: > > ** (Kosmos.Gui.exe:29424): WARNING **: Missing method > System.Windows.Forms.ToolTip::Hide(IWin32Window) in assembly > > /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll, > referenced in assembly /tmp/Kosmos/Kosmos.Gui.exe > > I have the libmono-winforms2.0-cil package installed. Anything else I > need? > > Bye > Frederik > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Kosmos on Linux
Hi Igor, thanks for building a Linux version! On my machine (Ubuntu Gutsy) it starts up, but when I open a project, after displaying "Loading..." for a while, the program quits with the following message: ** (Kosmos.Gui.exe:29424): WARNING **: Missing method System.Windows.Forms.ToolTip::Hide(IWin32Window) in assembly /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll, referenced in assembly /tmp/Kosmos/Kosmos.Gui.exe I have the libmono-winforms2.0-cil package installed. Anything else I need? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On 18/02/2008, Abigail Brady <[EMAIL PROTECTED]> wrote: > > line is probably twice the width of the actual road. this causes > > problems at even simple motorway junctions, as the whole thing becomes > > a big blue mess. could i request this be looked into? > > > > Well, if this isn't done, then roads quickly become hairlines at lower > zooms. There's not really much to look into. If you want to see the roads > they have to be wider than they really are. yes, they will. but i was talking about close-in zoom - the example i gave was at zoom 16. they don't have to be wider at that level, maybe at zoom 4 they do, but i wouldn't care about details like this at that zoom level anyway as i understand it, the tiles are rendered separately for each zoom level, so what we see at one zoom level is different to what we see at another > What a professional road atlas would do here is very likely to exaggerate > the junction so that it makes sense given the width using to render the > roads. Doing this algorithmically is hard, but probably not impossible. that sounds very bad, ugly and wrong on many levels. whether it's mapped as 'exaggerated' or algorithmically altered later, i can't see the point. if there's room in reality for the roads to exist without overlapping, then there's no reason the map can't reflect that ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On Feb 17, 2008 10:42 PM, Robin Paulson <[EMAIL PROTECTED]> wrote: > http://openstreetmap.org/?lat=-36.97273&lon=174.81833&zoom=16&layers=B0FT > > is a good example, which is a very simple junction I didn't check this particular case, but the on/off ramps should be motorway_link which (IIRC) are rendered thinner than the main motorway... But it's hard to get right, cartography is a very difficult topic. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] displayed width of roads
On Feb 17, 2008 9:42 PM, Robin Paulson <[EMAIL PROTECTED]> wrote: > why are roads displayed so thickly? I was looking at osm data overlaid > on oam, and realised that for a lot of roads, at some zoom scales, the > line is probably twice the width of the actual road. this causes > problems at even simple motorway junctions, as the whole thing becomes > a big blue mess. could i request this be looked into? > Well, if this isn't done, then roads quickly become hairlines at lower zooms. There's not really much to look into. If you want to see the roads they have to be wider than they really are. > http://openstreetmap.org/?lat=-36.97273&lon=174.81833&zoom=16&layers=B0FT > > is a good example, which is a very simple junction > What a professional road atlas would do here is very likely to exaggerate the junction so that it makes sense given the width using to render the roads. Doing this algorithmically is hard, but probably not impossible. -- Abi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
