Re: [OSM-dev] shp2osm.pl
Hi, Anthony wrote: In the longer term, I'd like to merge nodes throughout the entire file when they are duplicated in more than one polygon. Simply stuff every node you create into a hash the key of which is lat|lon, then retrieve the existing negative ID from that hash for new nodes if one is already present - done. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
Hi, Ian Dees wrote: I've been hoping someone would strike up a conversation with me on a good algorithm to find and relation-ize overlapping boundary ways. I would love to implement this... I have recently explained how I'm currently doing this with PostGIS but nothing keeps you from using the GEOS library and write a C or C++ program that does the same! But, someone recently wrote that polyshp2osm already supports multipolygon border relations so maybe give that a try? Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] osm2pgsql questions
Hello list, I am a new osm2pgsql user and I want to set up a WMS server with osm data. So I loaded the planet.osm into my Postgis database and am applying the daily diffs since the creation date of the planet.osm. Applying a daily diff takes several hours to complete (5~7) and one of my questions is if this is in the standard processing time or still ok. My server is an ubuntu 8.04 amd64 machine with 6GB RAM and two harddrives, one serves the diff files and the database is on the other. Processor is an AMD64 5600+ Dualcore. I ask this question mainly because I found some oddities when examining the diff process by osm2pgsql. Postgresql and Postgis are tuned according to the oms wiki and Postgresql manual ... First is a number of postgresql processes which are idle in transaction, this usually means that there has been a transaction started with BEGIN but not commited. Right now I have 5 processes of this kind and nobody else except osm2pgsql is using the database right now. Maybe it is a flaw/problem in osm2pgsql? At the start of the diff process I get errors in my postgresql log naming that some _tmp tables do not exist and cannot be dropped: 2009-09-30 08:44:16 CEST ERROR: table planet_osm_point_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_point_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_line_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_line_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_polygon_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_polygon_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_roads_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_roads_tmp; I suppose this is probably a leftover of an older version of osm2pgsql and it can be ignored but I am not so sure ... osm2pgsql puts out some messages during import and I wonder what storage efficiency: 11.34%, hit rate: 29.09% mean. Maybe someone can shed some light onto this for me Many thanks Frank -- Frank Broniewski Metrico s.àr.l. ( http://www.metrico.lu ) 36, rue des Romains L-5433 Niederdonven Luxembourg Fon: +352 26 74 94 28 Fax: +352 26 74 94 99 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Thanks for yor help again. I've just downloaded the latest mapnik from mapnik.org and re-installed it with scons. Unfortunately this has not fixed the issue though. In addition I searched the postgresql log for missing columns which returned nothing. [postg...@maps data]$ cat logfile | grep -i missing [postg...@maps data]$ cat logfile | grep -i column The only errors I could find were: ERROR: relation planet_osm_line does not exist at character 85 ERROR: relation planet_osm_polygon does not exist at character 159 ERROR: relation planet_osm_line does not exist at character 199 ERROR: relation planet_osm_line does not exist at character 199 ERROR: relation planet_osm_line does not exist at character 343 ERROR: relation planet_osm_line does not exist at character 386 ERROR: relation planet_osm_line does not exist at character 89 ERROR: relation planet_osm_roads does not exist at character 209 ... ... ect.. 2009/9/29 Lennard l...@xs4all.nl Richard Ive wrote: Thanks for you help. I assume, as I have to re-install osm2pgsql, I will have to re-import the planet.osm? Only if your black roads are actually caused by missing columns in your db. Check your postgresql logs. If it is caused by your mapnik being too old, and unable to handle the multiline SQL currently in osm.xml, you don't have to reimport the planet, but just update mapnik to release 0.6.1 or newer (svn). Newer mapnik versions are also more vocal about problems in the stylesheet, so I would recommend building from svn. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Richard Ive wrote: I've just downloaded the latest mapnik from mapnik.org http://mapnik.org and re-installed it with scons. By that, you mean you downloaded the 0.6.1. source tarball and compiled it, I presume? Another thing you could try is to check out the mapnik source tree by svn, and work with that. Unfortunately this has not fixed the issue though. In addition I searched the postgresql log for missing columns which returned nothing. Ah, too bad. This has been one of the common issues in the past, of a mispairing between mapnik and osm.xml. [postg...@maps data]$ cat logfile | grep -i missing [postg...@maps data]$ cat logfile | grep -i column Missing columns show up like this: ERROR: column aeroway does not exist at character 38 The only errors I could find were: ERROR: relation planet_osm_line does not exist at character 85 ERROR: relation planet_osm_polygon does not exist at character 159 Nothing else which gives more of a clue in the log file than this? What's just before/after these messages? For instance, which layer in osm.xml causes these error messages? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
I did: $svn co http://svn.mapnik.org/trunk mapnik .. $python scons/scons.py $su $python scons/scons.py install This is the method they suggest for CentOS. Nothing else which gives more of a clue in the log file than this? What's just before/after these messages? For instance, which layer in osm.xml causes these error messages? No, the only other errors that appear are: ERROR: table planet_osm_polygon_tmp does not exist ERROR: table planet_osm_roads_tmp does not exist ERROR: table planet_osm_point_tmp does not exist ERROR: table planet_osm_line_tmp does not exist ERROR: table planet_osm_polygon_tmp does not exist This is bizarre. 2009/9/30 Lennard l...@xs4all.nl Richard Ive wrote: I've just downloaded the latest mapnik from mapnik.org http://mapnik.org and re-installed it with scons. By that, you mean you downloaded the 0.6.1. source tarball and compiled it, I presume? Another thing you could try is to check out the mapnik source tree by svn, and work with that. Unfortunately this has not fixed the issue though. In addition I searched the postgresql log for missing columns which returned nothing. Ah, too bad. This has been one of the common issues in the past, of a mispairing between mapnik and osm.xml. [postg...@maps data]$ cat logfile | grep -i missing [postg...@maps data]$ cat logfile | grep -i column Missing columns show up like this: ERROR: column aeroway does not exist at character 38 The only errors I could find were: ERROR: relation planet_osm_line does not exist at character 85 ERROR: relation planet_osm_polygon does not exist at character 159 Nothing else which gives more of a clue in the log file than this? What's just before/after these messages? For instance, which layer in osm.xml causes these error messages? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Richard Ive wrote: This is the method they suggest for CentOS. That's okay. Did you uninstall the earlier package and all other instances of previous mapnik installations, before you compiled/installed it by hand? No, the only other errors that appear are: ERROR: table planet_osm_polygon_tmp does not exist Those are normal. At the start of an osm2pgsql run, it tries to clean up any of these remnants of a possibly aborted earlier run. I'm out of ideas actually. By the way, is every trunk bridge black in your renders, or only that particular one? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
I probable didn't uninstall it properly thinking about it, actaully. All the related libs have been updated from looking at the time stamp, but i'll look into that now just to make sure. This is the only one i've seen as it near where i work. Do you know of any others that are the same? 2009/9/30 Lennard l...@xs4all.nl Richard Ive wrote: This is the method they suggest for CentOS. That's okay. Did you uninstall the earlier package and all other instances of previous mapnik installations, before you compiled/installed it by hand? No, the only other errors that appear are: ERROR: table planet_osm_polygon_tmp does not exist Those are normal. At the start of an osm2pgsql run, it tries to clean up any of these remnants of a possibly aborted earlier run. I'm out of ideas actually. By the way, is every trunk bridge black in your renders, or only that particular one? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Default scale / meters per unit ?
When importing openstreetmap with osm2pgsql and default settings (900913) - how many meters is a unit? /Jonas ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
2009/9/30 Frederik Ramm frede...@remote.org Hi, Ian Dees wrote: I've been hoping someone would strike up a conversation with me on a good algorithm to find and relation-ize overlapping boundary ways. I would love to implement this... I have recently explained how I'm currently doing this with PostGIS but nothing keeps you from using the GEOS library and write a C or C++ program that does the same! But, someone recently wrote that polyshp2osm already supports multipolygon border relations so maybe give that a try? Unfortunately not, it supports multipolygons relations. Someone posted a perl script to do it. I think it was posted on Perl. It would be possible to do something like this based on Postgis. My way of doing it in Postgis is very similar to yours. Anyway, I am planning at some point to have a look at the perl code and add it to polyshp2osm in python. It would make life easier in the end to have a completely integrated script. Emilie Laffray ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
On Wednesday 30 September 2009 13:14:08 Jonas Donovan Hansen wrote: When importing openstreetmap with osm2pgsql and default settings (900913) - how many meters is a unit? /Jonas Whatever a unit is, that is totally dependent on scale and your renderer. The data in postgresql is vector data and has no scale. The coordinates of the reference system 900913 are metric, so you can calculate with them. The values of your bounding box are in meters, so you can calculate the current scale of your data with the corner values of the bounding box. Frank ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
On 30/09/09 12:14, Jonas Donovan Hansen wrote: When importing openstreetmap with osm2pgsql and default settings (900913) – how many meters is a unit? The units are meters, but meters on the projected map not great circle meters on the surface of the earth. What osm2pgsql does when you import in that mode is to project the data onto a giant flat sheet - effectively it unrolls the globe and stretches it until it is flat. The resulting coordinates are in meters but meters on that imaginary projected surface. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Just re-downloaded the mapnil stuff from the OSM svn, re-created the osm.xml and it's working! Thanks a lot for your help! 2009/9/30 Richard Ive rich...@xanox.net I probable didn't uninstall it properly thinking about it, actaully. All the related libs have been updated from looking at the time stamp, but i'll look into that now just to make sure. This is the only one i've seen as it near where i work. Do you know of any others that are the same? 2009/9/30 Lennard l...@xs4all.nl Richard Ive wrote: This is the method they suggest for CentOS. That's okay. Did you uninstall the earlier package and all other instances of previous mapnik installations, before you compiled/installed it by hand? No, the only other errors that appear are: ERROR: table planet_osm_polygon_tmp does not exist Those are normal. At the start of an osm2pgsql run, it tries to clean up any of these remnants of a possibly aborted earlier run. I'm out of ideas actually. By the way, is every trunk bridge black in your renders, or only that particular one? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
Tom Hughes wrote: Sent: 30 September 2009 12:55 PM To: Jonas Donovan Hansen Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] Default scale / meters per unit ? On 30/09/09 12:14, Jonas Donovan Hansen wrote: When importing openstreetmap with osm2pgsql and default settings (900913) - how many meters is a unit? The units are meters, but meters on the projected map not great circle meters on the surface of the earth. What osm2pgsql does when you import in that mode is to project the data onto a giant flat sheet - effectively it unrolls the globe and stretches it until it is flat. The resulting coordinates are in meters but meters on that imaginary projected surface. Does this mean that when you have in the past pulled way length totals from the pgsql db that the values will not be true to life? Cheers Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
On 30/09/09 13:30, Andy Robinson (blackadder-lists) wrote: Tom Hughes wrote: The units are meters, but meters on the projected map not great circle meters on the surface of the earth. What osm2pgsql does when you import in that mode is to project the data onto a giant flat sheet - effectively it unrolls the globe and stretches it until it is flat. The resulting coordinates are in meters but meters on that imaginary projected surface. Does this mean that when you have in the past pulled way length totals from the pgsql db that the values will not be true to life? I believe I have explained that when providing such numbers in the past... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
Andy Robinson (blackadder-lists) wrote: Does this mean that when you have in the past pulled way length totals from the pgsql db that the values will not be true to life? That is very likely a correct assumption, depending on the function used. ST_Length() gives projected meters for the default 900913 osm2pgsql db. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Sasha Maps on the iPhone
Hi all, I've recently finished implementing iPhone support for my maps library. You can check out the iPhone demo at http://www.maryanovsky.com/sasha/maps/iphonedemo/ (open on an iPhone or iPod Touch). It works as smoothly as Google Lattitude, and some things are even nicer (for example, it slides smoothly into the integer zoom when you pinch instead of snapping to it). Gestures: * Drag to drag (no inertia though). * Double-tap to zoom in and recenter. * Two-finger tap to zoom out. * Pinch to zoom in/out. You can also drag the smiley around. The main page is at http://www.maryanovsky.com/sasha/maps/ Enjoy :-), Alexander (aka Sasha) Maryanovsky ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] export mapnik
Hi! I just noticed, that if you try to download an exported image from the export-tab on the osm-webpage, you get a python-script. I suppose, this is wrong ;) Please fix! greetings, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Plepelits, | | Technische Universität Wien -Studien Informatik Raumplanung | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | sk...@xover.htu.tuwien.ac.at - My Blog: http://plepe.at | `-' ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
2009/9/30 Andy Robinson (blackadder-lists) ajrli...@googlemail.com Does this mean that when you have in the past pulled way length totals from the pgsql db that the values will not be true to life? If you want to obtain length in meters, you need a database that supports geodesic models. Postgis only supports with ST_Distance_Sphere or ST_Distance_Spheroid and only between two points. Geodesic support is quite difficult to get. Then again, you can probably use an UTM projection in part of the world to get a distance in that part of the world that would more or less accurate. Emilie Laffray ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql questions
On Wed, Sep 30, 2009 at 11:27 AM, Frank Broniewski b...@metrico.lu wrote: I ask this question mainly because I found some oddities when examining the diff process by osm2pgsql. Postgresql and Postgis are tuned according to the oms wiki and Postgresql manual ... First is a number of postgresql processes which are idle in transaction, this usually means that there has been a transaction started with BEGIN but not commited. Right now I have 5 processes of this kind and nobody else except osm2pgsql is using the database right now. Maybe it is a flaw/problem in osm2pgsql? osm2pgsql has several copies running at once and unfortunatly you can only run one copy at a time per connection. So osm2pgsql opens a number of connections. As so yes, you get idle in transaction messages. This is normal. At the start of the diff process I get errors in my postgresql log naming that some _tmp tables do not exist and cannot be dropped: 2009-09-30 08:44:16 CEST ERROR: table planet_osm_point_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_point_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_line_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_line_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_polygon_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_polygon_tmp; 2009-09-30 08:44:16 CEST ERROR: table planet_osm_roads_tmp does not exist 2009-09-30 08:44:16 CEST STATEMENT: DROP TABLE planet_osm_roads_tmp; Hmm, I forget the reason for those osm2pgsql puts out some messages during import and I wonder what storage efficiency: 11.34%, hit rate: 29.09% mean. Maybe someone can shed some light onto this for me For efficiency osm2pgsql keeps a cache of nodes. Unfortunatly, this take more memory than most people have. What this means is that, in your cache, about 11% of the nodes fit in the cache, and that was good for 29% of node lookups. Bigger cache = higher hit rate = faster import. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] likenesses
I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. I'm not a socialist moral relativist when it comes to cultural comparisons, but forcing the entire world to tag their largest class of vehicular infrastructure as highway=motorway isn't super efficient either maybe. It would be nice to allow people to tag things as motorway, freeway, autobahn or whatever makes sense. Then, if your renderer or routing software knows about them, great. If not, then there should be something that tells them what they're roughly like. So I think step one is to have an XML file which points out these equivalences. It will be rough. It won't know that an autobahn has no speed limit or a freeway is usually 55mph or a motorway is usually 70mph. The first step is just a hand wavy... I don't know what a autobahn is, but it's roughly like a motorway, ah ok. Then it will free us up to start to do much more specific country rendering and routing. Later, we can evolve it to be an API or know all sorts of things, but I want to put together version 0.1 and have people like Jon Burgess and Steve Chilton care about it because of rendering and Frederik and Richard care because of editing. I would want it to be required by all editors and routers and renderers in future, if it was to be useful. Therefore, here's my straw man to start it off !-- this is a straw man and might not even parse as XML. C'est la vie -- likenesses version=0.1 likeness object=way key=highway likeness value=motorway / likeness value=freeway / likeness value=autobahn / /likeness likeness object=node key=amenity likeness value=atm / likeness value=bankautomat / likeness value=geldautomat / /likeness /likenesses If you want to hack on this, it's at http://svn.openstreetmap.org/misc/likenesses/likeness.xml The point here is that if you're a routing engine and you know about motorways you treat autobahns and freeways as roughly the same, or identical if you like. If you want to then go on and figure out more details, please do! If you're a renderer and you know what an icon for amenity=atm is, then you know you can use this for amenity=bakautomat. The next step is that osm2pgsql uses this to convert things it doesn't know about, or the big mapnik xml files do, or whatever. There are glaring problems like maybe we don't want people to use highway but whatever makes sense for them - that is we want the keys *and* values to be mutable. But, let's take step one first. Thoughts? Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 SteveC st...@asklater.com: Thoughts? JOSM sort of allows this already, it allows you to load a custom set of presets and then converts them into typical OSM values. Having more flexability in the editors makes more sense to me then trying to go the other way and have the renderer or other software figure out what was intended. One of the big reasons to have a smaller set of keys is because mistakes are more likely to be found and fixed, even if you don't understand the language used to create it, your editor can convert it into a language you are used to so you can fix it. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
Inasmuch as the underlying concepts are identical (more or less), I don't like the idea that we can use different key name or values to represent those concepts. Sure anyone can tag oneway/one_way=yes/true/1/si/hai/oui/jå and write out all the equivalences in a likeness XML file, but this complicates use of the data for little benefit. I think of some OSM tags as similar to the keywords of a programming language. Sure you can translate keywords like print and open into the native language of the programmer and then do pre-processing of the code or use a specialized compiler, but what for? (Take note that even programming languages that were invented by non-native English speakers use English keywords for consistency. Japan's Ruby comes into mind.) So allowing amenity=bankautomat as a synonym for amenity=atm even if they represent identical concepts is not really good. Push for i18n on the user interfaces, not on the non-name data. On Thu, Oct 1, 2009 at 10:25 AM, SteveC st...@asklater.com wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. I'm not a socialist moral relativist when it comes to cultural comparisons, but forcing the entire world to tag their largest class of vehicular infrastructure as highway=motorway isn't super efficient either maybe. It would be nice to allow people to tag things as motorway, freeway, autobahn or whatever makes sense. Then, if your renderer or routing software knows about them, great. If not, then there should be something that tells them what they're roughly like. So I think step one is to have an XML file which points out these equivalences. It will be rough. It won't know that an autobahn has no speed limit or a freeway is usually 55mph or a motorway is usually 70mph. The first step is just a hand wavy... I don't know what a autobahn is, but it's roughly like a motorway, ah ok. Then it will free us up to start to do much more specific country rendering and routing. Later, we can evolve it to be an API or know all sorts of things, but I want to put together version 0.1 and have people like Jon Burgess and Steve Chilton care about it because of rendering and Frederik and Richard care because of editing. I would want it to be required by all editors and routers and renderers in future, if it was to be useful. Therefore, here's my straw man to start it off !-- this is a straw man and might not even parse as XML. C'est la vie -- likenesses version=0.1 likeness object=way key=highway likeness value=motorway / likeness value=freeway / likeness value=autobahn / /likeness likeness object=node key=amenity likeness value=atm / likeness value=bankautomat / likeness value=geldautomat / /likeness /likenesses If you want to hack on this, it's at http://svn.openstreetmap.org/misc/likenesses/likeness.xml The point here is that if you're a routing engine and you know about motorways you treat autobahns and freeways as roughly the same, or identical if you like. If you want to then go on and figure out more details, please do! If you're a renderer and you know what an icon for amenity=atm is, then you know you can use this for amenity=bakautomat. The next step is that osm2pgsql uses this to convert things it doesn't know about, or the big mapnik xml files do, or whatever. There are glaring problems like maybe we don't want people to use highway but whatever makes sense for them - that is we want the keys *and* values to be mutable. But, let's take step one first. Thoughts? Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
Ray Foulkes schrieb: If I use an svn client to download to a directory then point Eclipse to construct a java project itself, there are hundreds of Java errors which I have not fully investigated but look nasty. Not surprising since the build scripts I don't think are being used in that case. The Eclipse relevant part of JOSM is the core directory. Check-out the path you mentioned outside of Eclipse and then add the core directory as Project with external sources into Eclipse. This should work for JOSM itself. Plugins are a different matter. Jan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
