Re: [OSM-dev] Status of the Mapnik stylesheets
On 13-11-2012 15:48, Simon Legner wrote: I'd like to find out what the current status of the Mapnik stylesheets for www.osm.org is. The most recent changes are from June 2012 [1], and the number of open tickets in TRAC is 400 [2]. Currently it's in a bit of a holding pattern. Personally, I'm waiting for an update of the server, which should bring a newer version of the mapnik render software. The other regular maintainer is on Windows, and would need a Windows build of that mapnik to come back to developing the style. Who is responsible for incorporating changes? Is some help needed? How are those changes applied to the main rendering server? The changes are committed to svn. This is then retrieved on the OSM rendering server and rendering is restarted with the new style. I'd like to see some accepted tagging systems like the public transport schema [3] be handled by the stylesheet. This requires a reload of the database to at least get public_transport=* in. Handling role values, like stop, is not supported yet. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On 13-11-2012 15:58, Paweł Paprota wrote: I'd say the priority should be bringing the main style onto the pretty side... If you take a look at the amount of open tickets, pretty clashes heavily with I want $feature rendered, where $feature ranges from 'yes, probably, sounds sane enough' to 'argh, what are you thinking'. :) -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] making osm2pgsql import relations?
On 7-11-2012 21:34, Ákos Maróy wrote: But, I can't seem to be able to have osm2pgsql import my relations - after the import, the content of the planet_osm_rels table is empty. I was looking at the osm2pgsql documentation, but couldn't find an obvious way to have the relations imported as well. planet_osm_rels is used for the slim mode import, ie. the ability to later apply diffs. If you didn't use osm2pgsql --slim (or -s), there won't be any data in planet_osm_rels. Imported relations that pass the k/v criteria (in default.style) and give a valid geometry, can be found in planet_osm_line and planet_osm_polygon. Where they end up depends on whether they result in a line or area respectively. The osm_id for these features is the negated relation id. So relation 1000 will have an osm_id of -1000 in the tables. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem compiling mod_tile
On 20-3-2012 22:25, yvecai wrote: I just suppress a few thing in the attached file until it works, but it may be safer to wait for a real fix by somebody understanding cpp and modtile better than me. It's fixed now. https://trac.openstreetmap.org/changeset/28134 -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql patch for nested relations
On 1-3-2012 15:28, Sven Geggus wrote: Quite in contrast to multipolygon relations, there is almost no computation in route relations, their member ways are just added to the planet_osm_lines table, they are not even concatenated. They are concatenated, up to a maximum length. Still, that's still a lot less work than multipolygon calculations. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] generate_xml.py problem with fonts
On 2-2-2012 23:41, Alexandre Busquets wrote: I downloaded the code from http://svn.openstreetmap.org/applications/rendering/mapnik/ ... libmapnik0.7 from package Try: svn co -r27279 http://svn.openstreetmap.org/applications/rendering/mapnik/ -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastline shapefiles
On 30-1-2012 6:09, Paul Norman wrote: I have been experimenting with generating the coastline shapefiles locally using http://svn.openstreetmap.org/applications/utils/coastcheck/ and ended up with a few questions 1. Is this the same code that is currently used to generate the processed_p files? Yes, except for the slight tweaking of some initial values. Also, two sets of shapefiles are generated, each with slightly different values for shape overlap. The first is processed_p, the second is another shapefile from which shoreline_300 is generated. The latter one takes more time to generate and then simplify. 2. It took my server about one hour from the start of extracting the coastline data to creating the shapefiles. My understanding was that this process took about a day. I'm using a different route to extract coastline data than osm2coast, could this account for the difference? A full coastline shapefile run (ie. both processed_p and shoreline_300) takes a few hours to generate, generally. I have no doubt that current hardware (cpu, ssd) can have a drastic positive influence to get it to your 'one hour'. 3. If I were to run the coastline generation daily and upload the files somewhere, could someone then host a slippymap showing coastline errors? I'm sure there could be ways to get that done. 4. Given that it only took an hour to generate, is there any way to get more frequent updates to the coastline files? Another limiting factor in this is that you would need the full planet file, to be able to extract the coastlines. Applying diffs to update that planet file adds a serious amount of time to a coastline run. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] multipolygon inherits from tags way that are neither inner nor outer
On 16-1-2012 18:35, Martin Koppenhoefer wrote: With the boundary and admin_level tags on the relation now the member tagged as admin_centre gets interpreted as inner-way (the administrative boundary is also drawn around the building), but no building tag is inherited anymore on the multipolygon. Well, what do you expect when you add an inner way (the building) to an area object (the administrative region)? Never mind any additional tags. It will be interpreted as such: a gap in the area. An enclave, in this particular case, with an appropriate line drawn around the building. So there you have it: don't add stuff to area datatypes that doesn't belong in them. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Dynamic buttons in side menus
On 16-10-2011 13:53, Dirk Stöcker wrote: Actually I don't think thats a good idea. While this may be good for experienced users, a novice probably needs ages to find such a hidden functionality. Like the selection and search history! People are still amazed when I tell them that it exists and where they can find it. BTW: That's #4869 -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Mapnik osm.xml style file for main map?
On 11 August 2011 19:00, Lennard l...@xs4all.nl wrote: Oh dear. My apologies, it seems I've been using Mapnik2 instead of just Mapnik. Yoink! Mapnik2 has been used on osm.org for months as well, but you would have to know that the osm.xml file is converted to mapnik2 syntax before being fed to mapnik2. :-) Have a look at upgrade_map_xml.py, installed by mapnik2. See http://trac.mapnik.org/wiki/Mapnik2. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik osm.xml style file for main map?
I've been using code from the http://trac.openstreetmap.org/browser/applications/rendering/mapnik project for generating tiles, but the style file (osm.xml) is not the same one used to render tiles for the main OSM map. That is the style file used to generate the osm.org 'mapnik' map. I've regenerated the osm.xml file from source with generate_xml.py and the results are the same. I'm not sure how you are getting those results from the correct style file. Are you getting any notices or errors during rendering or from postgresql? What are you using to render your images? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Where to place world boundaries when mapnik is installed through synaptic package manager
On 4-7-2011 18:33, M∡rtin Koppenhoefer wrote: is there a reason why gdal, ogr and sqlite support is not compiled by default (are they working nonetheless or is there a problem with them?) You'd have to ask the SCons maintainer for mapnik. As all you need for the regular OSM 'mapnik' map is shape and postgis, it's usually not a problem that they are apparently not added by default. They should, however, compile and work once you enable them through SCons. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Where to place world boundaries when mapnik is installed through synaptic package manager
On 3-7-2011 10:28, Parveen Arora wrote: python-mapnik and libmapnik0.7 is available in Ubuntu 10.04 But the one avaible to compile is 0.7.1 If you are actually compiling your own version, I would recommend you to go with the 0.7.2-dev branch. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql installs default.style to /usr/share/osm2pgsql but searches in /usr/share
$ osm2pgsql -U gisuser /tmp/map.osm Couldn't open style file '/usr/share/default.style': No such file or directory Someone here who could fix this? osm2pgsql -U gisuser -S /usr/share/osm2pgsql/default.style /tmp/map.osm -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] openid
On 18-6-2011 15:49, Steve Coast wrote: the openid stuff is nice but is it really necessary to slap 6 big logos on OSM.org? :-( Would you rather they be smaller? :-) -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The Future of Areas - open discussion?
(Could also be done on a per-file basis but I have some use cases in mind where original OSM objects and modified-but-please-do-not-upload-these objects would be mixed.) Like https://josm.openstreetmap.de/ticket/4043 ? Perhaps you could drop the idea of per-object flags in that ticket? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql slow on update import
On 7-5-2011 18:46, Sven Geggus wrote: Jukka Rahkonenjukka.rahko...@latuviitta.fi wrote: Am I right in thinking that if there were suitable diffs available it would be much faster to update directly the osm_point, osm_line and osm_polygon tables without going through osm_points, osm_ways and osm_rels? This would not work because these tables are different depending on the stylefile used. Fully self-referential diffs would be good for one thing: no need to fetch the unchanged nodes of a way to rebuild the geometry. They would potentially be much much larger than the current diffs, so that's a clear argument against them. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The Future of Areas - open discussion?
On 25-4-2011 13:31, Jukka Rahkonen wrote: also: which of the old data is most probably an area and which is a closed linear feature. This might not be clear in all cases. Not in all cases, but the overwhelming majority of them are clear. And further: There are some badly invalid area features in the database now because the multipolygon relation accepts anything. What would be done for those in the conversion? Continue to serve such a case in their broken relation+members form. Let the editors write it back in that form if the user hasn't fixed it, the editors itself were unable to fix it, or upon notifying the user he/she could fix it but then chooses not to do so. 'Conversion by attrition' -- See: created_by=*. Of course, the large majority that are clear could be done in one fell swoop, in some kind of A-Day (Area Day, which in actuality would probably turn out to be an A-Weekend+ ). -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] imposm - New PostGIS importer for OSM data
On 4-4-2011 19:38, Oliver Tonnhofer wrote: Well, that would defeat the purpose of imposm. If you really need the osm2pgsql schema, then I would suggest to use osm2pgsql :) We're keeping an open mind to the idea of changing things. If imposm performs well, works on different platforms (*ix, Win, Mac), and can also output the basic osm2pgsql schema for those transitioning, an argument can be made for adopting imposm at some point. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2psql: minor hstore rework
On 24-3-2011 16:39, Sven Geggus wrote: The rework should not change anything for people who exclusively use a hstore column (no other tag columns). Peter Körners hstore stuff should also be unaffected. When using --hstore, planet_osm_roads is no longer loaded with column tags. Likely a bug, but please point out if I've misunderstood the new method. These tags are stripped from the hstore column as well, but that is by design. What probably happens is that, in write_wkts(), you removeTag(), thereby physically removing that tag from the list. However, for geometries that also go into planet_osm_roads, write_wkts() is called twice in a row (once for lines, once for roads), and the second time, these tags are gone. There's nothing left to put into the columns. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis: merging several daily diffs
On 21-3-2011 21:21, yvecai wrote: I am wrong ? --read-xml-change comes first, then --read-xml -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] List of all point Point elements (symbols) displayed in Mapnik style?
On 19-3-2011 19:53, M∡rtin Koppenhoefer wrote: That's nice Lennard. Does anyone recall where the rules for the text of admin boundaries can be found? I found this some time ago, but now can't locate it again (I guess it is some generic rule). The two ElseFilters at the end of roads-text. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] List of all point Point elements (symbols) displayed in Mapnik style?
On 18-3-2011 12:30, Stefan Keller wrote: Hi, I'd like to get a list of all Point elements (symbols) displayed in Mapnik style. When looking at http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml But only find few PointSymbolizer rules (/turning_circle-livs-fill.xxx.png). Am I looking at the wrong osm.xml? See the inc/ file. You can also have a look at http://tile.openstreetmap.org/style/osm-annotated.xml which is a view of the stylesheet that's being used on osm.org. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] validator question, multipolygons
On 5-3-2011 18:37, Mike N wrote: On 3/5/2011 12:05 PM, Russ Nelson wrote: I agree. What might work for better nannying is to only run the validator on things they've changed. Otherwise they get asked to fix everything within the bounding box they downloaded. ? It already works this way for me. When you hit upload, yes. If you click Validate in the validator, it checks every object. -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] mapnik style - datasources parameters
On 3-3-2011 21:12, Philipp Borgers wrote: is there any reason why the datasource parameters srid and geometry_field are not used in the actual mapnik style file for osm? If I add Parameter name=srid4326/Parameter Parameter name=geometry_fieldway/Parameter to every datasource the amount of requests goes down. Did you only surmise that from the documentation or did you actually see this in your pglogs? These geometry_field,srid queries are only done once per layer during the parsing of the stylesheet, and cached. In mod_tile scenarios this means these extra queries only happen once in weeks or months. If you reload the stylesheet for every render request, then yeah, it could, maybe, make a difference. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] capitals; normalizing true, yes and 1
On 1-2-2011 18:54, M∡rtin Koppenhoefer wrote: looking at my current database extract (imported with osm2pgsql) I find that there is a small problem with several values for the same thing. E.g. if you look at the key capital you will see, that in the current mapnik stylesheet there is only rules for yes but not for true. I was assuming that those would be normalized during import with osm2pgsql, but apparently they aren't. There is some capitals that are marked as capital=true and therefor don't render in mapnik low-zoom As a stylesheet maintainer, I wouldn't mind *at all* when we can finally get rid of true and 1 as alternate values of yes. Or settle on one of those two as the main tag, but 'yes' would seem to be the majority. Fortunately, for capital, we only use yes and not the other 2 variants in the main mapnik map. It's not logical to add these at this point. We already have to normalise true and 1 to yes for bridges and tunnels, and if those variants would disappear from the database and the wiki, all the better. You're right in that these values could be normalised by osm2pgsql, but osm2pgsql is by no means the only tool used to process OSM data. Why impose the same true or 1 then yes rule on every consumer of OSM data? Anyway, shouldn't this now move to [tagging] ? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Patch to osm2pgsql for faster updates
On 25-1-2011 5:04, Erik Burrows wrote: In my 8.4 database, when I re-create the planet_osm_ways_nodes and planet_osm_rels_parts indexes with fastupdate=off, diff import times go from being progressively slower after a vacuum, to being consistent in terms of import time, accounting for the variation of diff size hour-to-hour. Which would be expected, upon reading what fastupdate does. Slower overall, but consistent. The widely differing diff apply times with fastupdate=on would be due to both having to parse the regular index and the temporary one, and it possibly hitting autovacuum or the work_mem limit during diff processing, therefore triggering an immediate consolidation of the index. This is the same positive change in behavior I saw when setting fastupdate=off in 9.0.2. So you imply that you saw the same gradual slowdown in 9.0.2 with fastupdate=on? My experiences with 9.0.2 could very well be biased, since I switched from 8.4 to 9.0 the same time I started using more powerful hardware. A.k.a. a 'real server' with a 10k rpm scsi raid0 instead of a single disk sata desktop disk. :) However, I've also switched our NL test server from 8.4 to 9.0.2 soon after, and that also feels a bit faster when processing diffs. That virtual hardware hasn't changed. My 8.4 db, on a SATA disk is now just better than 1:1 for applying hourly diffs, and my 9.0.2 db on SSD is about 4:1. (diff size to apply time) With minutely diffs, even when processing an hours worth (maxInterval=3600), I think I never hit 1:1, even when on that SATA desktop disk I mentioned earlier. I could always catch up, meaning diffs would apply faster than the interval they represent. For those interested to try fastupdate=off, the manual says you can do ALTER INDEX and then vacuum + rebuild the index. That saves you from having to do a reimport with osm2pgsql. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Patch to osm2pgsql for faster updates
On 23-1-2011 17:44, Tom Hughes wrote: On 23/01/11 16:24, Erik Burrows wrote: I was having great difficulty with applying the daily diffs to my PostgreSQL database (8.4 and 9.0). I would get good performance right [...] I wonder if in fact this is the performance problem that we saw using an 8.4 database. The general consensus was that it was somehow related to the GIN indexes but we never managed to work out exactly what it was. Erik mentions encountering the same issue in 9.0. So either fastupdate=on is more intelligent in 9.0, or we're not on the right track to solve our 8.4 slowdown troubles. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Microsoft gains access to aerial imagery
2010/11/24 Frederik Ramm frede...@remote.org: in case of a constant offset at given locations (and not some warping problem), it would be cool to store (and possibly collect in an OSM / JOSM-database) those locations with their offsets for corrections, so that a user wouldn't have to adjust it manually everytime. Such a system would also be extremely helpful for other image providers. I keep moving yahoo to its right position whenever I edit something in my local area. Having JOSM store that offset locally or even remotely so others can benefit would be something to consider. -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.
On 16-10-2010 9:55, Lennard wrote: On 16-10-2010 8:39, Brett Henderson wrote: If anybody sees any issues with the binary support, please let Scott and I know. I'm now building Osmosis via an automated Hudson process so pushing out new builds should be fairly quick once a fix is identified. Scott already knows about this, but 23580[1] will emit a warning for every occurence of an object without user/uid parameters. These objects, the result of anonymous edits which were possible in the past, do exist in the planet, and could cause some flooding on the console output. In my eyes, this change should be reverted. Just built the current trunk, and this output[1] is still present. Could you please consider removing this notice, or only output it once instead of for every anonymous element? In fact, the suggestion being given is plain incorrect for some uses. For instance, when you're cutting out a piece of the planet, you're probably intending to distribute that extract as-is, i.e. with all metadata intact. The suggestion in that respect is too bold. [1] Attention: Data being output lacks metadata. Please use omitmetadata=true -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.
On 18-11-2010 23:47, Lennard wrote: Just built the current trunk, and this output[1] is still present. Could you please consider removing this notice, or only output it once instead of for every anonymous element? I seem to have missed the fact that it will print upto 100 times this message and then no more. Ah well, that'll do, I guess. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Mapnik Fonts are Nonsense
On 2-11-2010 22:14, maw...@gmail.com wrote: 1. I have created a myOSM.xml stylesheet from the osm.xml template using: generate_xml.py osm.xml myOSM.xml --dbname osm_planet --accept-none --password pw --host localhost --port 5432 --user postgres There is usually no need to generate a local copy of the osm.xml stylesheet. Generating a local copy includes all files from the inc/ directory into a single (monolithic) stylesheet file, but also means that every time that we update the stylesheet in svn, you have to rerun generate_xml.py in this way. If you omit the osm.xml myOSM.xml part from your generate_xml.py call, it will only create 3 files in the inc/ directory based on the .template files there. You then point your tile generating script to osm.xml as the stylesheet. Updating the stylesheet is then also as easy as running svn up. Did you read somewhere that you had to generate a local copy? Earlier versions of the most-used blog about setting up a mapnik rendering stack (hi rweait! :)) told you to do that, but I think that got corrected after pointing this out. 4. I then went to C:\mapnik-0.7.1\inc\fontset-settings.xml.inc and uncommented the unifont lines as such: That's fine. 5. I then opened the myOSM.xml and noticed that it only had listed the DejaVu fonts at the top. I then added the unifonts as such: And that's not surprising, for the reason I already mentioned: you generated a single file based on osm.xml and everything in inc/, and any changes you made after generate_xml.py didn't make it into your myOSM.xml. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Renderd + expire_list
On 20-10-2010 15:51, Samir Faci (Dev) wrote: I was going to submit a patch... but I wanted to understand the intended purpose of these changes. The intended purpose was to remove the need to setup rendering threads with renderd, when they wouldn't be used anyway. it seems like the program flow now is to only render in combination with touchFrom or deleteFrom. That's a bug. The default behaviour is to rerender tiles, and only when a suitable combination of min-zoom and touch-from/delete-from is given, to switch to those exclusively. I just committed a fix that does more explicit checking of these combinations. So, for example: Expire tiles z9 and up by setting their timestamp to the past. This causes mod_tile to issue a rerender the next time the expired tile is requested: --min-zoom=9 --touch-from=9 Rerender tiles z8-11 and touch z12+. The lower zooms take much longer to render, so this rerenders those right away, while delaying rendering the higher zooms until someone actually looks at them. --min-zoom=8 --touch-from=12 If you give no min-zoom/max-zoom (default is 0 and 18 respectively), and no touch-from/delete-from, it will go through all zooms and rerender them, based on the input file. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.7+: Split node concept?
On 12-10-2010 21:45, Chris Browet wrote: Seems to me that it would: - be less confusing, both for consumers and editors Implementation details like this should be hidden from consumers by the editors anyway. - save db space I'm wondering why you think it will save db space? Your idea would mean the end of shared nodes between ways, or am I misunderstanding? - save memory/CPU cycle on the consumer side You are already processing 2 types of nodes on the above way, both directly and indirectly through the nd ref. Might just as well stick to the old nd ref exclusively, and not maintain two code paths. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Editors: Actively removing created_by?
On 10-10-2010 22:37, Chris Browet wrote: Hi, I'm wondering if Potlach and JOSM are actively removing the pre-0.6 created_by tag at the feature level when uploading? Would that be desirable/acceptable? They are, and have been since soon after API 0.6 went live. I think it's desirable. They'll still be available in the object history, and the removal is packed in with a real edit, so no superfluous edits needed just to remove the created_by. It's a matter of attrition now. Very slow attrition nonetheless. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] PostgreSQL 9.0?
On 20-9-2010 23:57, Brendan Morley wrote: Are PostGIS downloads mirrored anywhere? The site is up, but your DNS server chain may not know about it yet. I successfully installed postgresql 9.0 and postgis 1.5.2SVN today, and it's now chugging along on an import. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM coastline on PostGIS + MapRenderer?
On 7-9-2010 17:39, Mulone wrote: I imported the OSM data for Ireland in my postGIS db. I noticed that there is no coastline, which isn't great to render an island. Is there a way to get an XML file containing the coastline and import it into postGIS? natural=coastline, as a tag, is hardwired to be dropped in osm2pgsql. If you want that tag to survive the import, you'll have to remove that bit from the code and recompile/reimport. Then you'll have a bunch of ways in your DB with natural=coastline, and you'll have to build a polygon out of them. And hope that there's nothing in them that prevents that from happening. That's one reason why land in mapnik is rendered from shapefile. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] generate_xml.py not generating osm.xml file?
On 29-8-2010 11:20, Ákos Maróy wrote: what I'm trying to achieve is to include my ownStyle andLayer element in the osm.xml file. my hope was that if I create an inc/layer-foo.xml.inc file with myStyle andLayer definition (just like the others there), and list my .xml.inc in inc/layers.xml.inc, than my stuff would be included, just as the others. They are dynamically included, by putting the relevant layer-xxx; references at the right spot in osm.xml. The ordering of Layer elements in the stylesheet determines the order in which mapnik renders. So water, for instance, is loaded by way of osm.xml including inc/layers.xml.inc, then including any file defined there, and then it's actually 'activated' by encountering layer-water; in osm.xml itself. You may have missed that last bit. but, it seems osm.xml already has the contents the 'stock' xml.inc files literally included. what I was looking for is a way to re-create osm.xml with the updated inc/layers.xml.inc, so that my stuff would be included too. The normal osm.xml file on SVN does not have the xml.inc files included. They are dynamically loaded by libxml2 during parsing of osm.xml. They would only be included in a stylesheet if you tell generate_xml.py to create a new stylesheet from osm.xml. You would also loose the ability to do a simple svn up to keep in sync with osm.org, as you would then also have to rerun generate_xml.py to recreate your local stylesheet, after every svn update. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] generate_xml.py not generating osm.xml file?
On 29-8-2010 14:31, Ákos Maróy wrote: They are dynamically included, by putting the relevantlayer-xxx; references at the right spot in osm.xml. The ordering ofLayer elements in the stylesheet determines the order in which mapnik renders. what do you mean by 'stylesheet' in this context? Mapnik uses a stylesheet to tell it what to render and how to render it. The OSM stylesheet is called osm.xml and is what I'm referring to. yes, I see that. but to 'activate' my own layer, I'd still have to manually edit osm.xml, wouldn't I? Yes, by referring to your external entity (the xml.inc file) at the right place in the osm.xml stylesheet. it's actually a pit confusing, that osm.xml both references layers via these external entities, and containsLayer andStyle definitions on its own. I know. Ideally everything would be found in the xml.inc files, and osm.xml would only be a small skeleton file, referring to the include files. I see. the confusion comes from the content of these xml.inc files and osm.xml in general to be of similar purpose. wonder what make something get into a layer files, and what is in osm.xml itself. When I started to implement the external entities (the include files), I took the easy cases and split them off into xml.inc files. Most of what remains is so interwoven (all the roads/railways/etc and all the bridge/tunnel variants of those) that I left that part alone. but, still. it seems that there is no 'simple' or 'elegant' way of just dropping a new layer-foo.xml.inc file into inc, and to make osm.xml automatically use the definitions in there. as at least one has to add an external entity reference manually. is this correct? That is correct, also because *you* have to tell mapnik *where* your style comes in the whole rendering order, by putting your layer-xxx; at the correct spot. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] generate_xml.py not generating osm.xml file?
On 27-8-2010 15:58, Ákos Maróy wrote: Hi, Maybe I'm misunderstanding the generic purpose of the generate_xml.py file from the mapnik rendering toolset, but for me, it does not seem to touch my osm.xml file in any way. That's correct. when I execute generate_xml.py with appropriate database setttings, osm.xml is not changed in any way. if I remove osm.xml, it is not generated by the gall to generate_xml.py in any way. What does happen when you run generate_xml.py is that three files are created (or updated) in the inc directory. They are: datasource-settings.xml.inc, fontset-settings.xml.inc, settings.xml.inc Some guides still give a syntax like: generate_xml.py my_osm.xml other stuff But that's needed only in rare cases where you actually want it to create a monolithic copy of the entire mapnik style. my_osm.xml would then be composed of osm.xml and all include files from the inc directory. Normally, you use generate_xml.py to set the contents of the three files I mentioned earlier, and then point your map generating script or app to osm.xml. Through XML parsing, osm.xml will dynamically include the contents of the files in the inc directory. Synching the stylesheet to OSM SVN is then only a matter of running svn up. You only need generate_xml.py again if you change any of the settings, or if a new setting was introduced (in the .template files in the inc directory). am I misunderstanding that generate_xml.py would actually create osm.xml based on the contents of the PostGIS database it connects to, and based on the templates in the inc directory? osm.xml does not contain geographic data. It contains the stylesheet that tells mapnik how to render geo data that you load into the postgis db with osm2pgsql. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] validator warning for touching inner multipolygon-ways
On 23-8-2010 11:38, M∡rtin Koppenhoefer wrote: Frederik pointed out in a recent discussion (sorry for not quoting precisely) that OSM generally supports/encourages touching inner ways of multipolygons (which I think is a good idea because it happens all them time, and saves us lots of double ways). My point now: JOSM validator gives a warning on those. Could we get rid of this warning? Not only touching inner ways. The validator will generally 'warn' about any area 'overlapping' another area, when in reality they are only touching along part of the way. It makes this warning generally useless. -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [OSM-talk] RFC: what are empty nodes and how should we use them?
** Adding josm-dev to the list. Please post technical follow-ups there. ** On 16-8-2010 12:15, Peter Körner wrote: The POST /api/0.6/changeset/#id/upload call is atomic in a transaction. Why not split your upload into multiple OSC Parts and post thems via this call. That way no imcomplete data would be visible to other users at any time. Uploading 30k+ objects in a single chunk with JOSM(1) is just too unreliable to make that workable. So either we have to split the data in smaller chunks by hand, or use JOSM's native chunked upload mode. If you have 40k nodes and 5k ways, and upload in 5k chunks, you will upload 8 chunks with nodes, and 1 chunk with ways. Each chunk is atomic, and that's where atomicity ends, as far as the API is involved. JOSM makes no attempt to sort the data in a smart way, to keep all nodes and associated ways and relations close together, in the same chunk when possible. I asked about such a feature before(2), but nothing has come of it as of yet. If such a sorting feature is added to JOSM, the chunk size should be a soft size, able to vary slightly if that means related objects end up in the same chunk. May I point out smarter-sort.py(3)(4) as an example? Sorted uploads would mostly prevent these 'fields of empty nodes' that appear to other mappers during a chunked upload, limiting the opportunity they have to wreak havoc on an ongoing upload by 'helpfully' deleting the nodes. JOSM's chunked upload mode is an answer to API timeout issues, but it does have its own issues to keep in mind. (1) It's not exactly more reliable with dedicated bulk upload scripts either. If the API takes too long to check the uploaded osmChange for validity, the TCP session appears to timeout. The script/JOSM never receives the OK from the API, including the new object IDs. The next time you hit upload to resume, it will reupload that failed chunk in its entirety, leading to (in my example) 5k duplicate objects on the server. (2) http://josm.openstreetmap.de/ticket/4299 (3) http://wiki.openstreetmap.org/wiki/Upload.py (4) http://svn.openstreetmap.org/applications/utils/import/bulkupload/smarter-sort.py -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] The same OSM server but locally available
Plus you can even filtered it at Osmosis level if you want to. Osmosis change stream bbox filtering? Have you tried that yourself? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-Dev]Add Geometry Column in PostgreSQl
On 10-7-2010 0:43, PARVEEN ARORA wrote: psql:/usr/share/postgresql/8.4/contrib/postgis.sql:6949: ERROR: current transaction is aborted, commands ignored until end of transaction block ROLLBACK You are probably running this under a role that does not have the required rights to create functions. Try running it as the postgres user, or as any other role that has the required rights. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Apache + mapnik + mod_python problem
On 28-6-2010 18:18, yvecai wrote: I had just run generate_xml.py again to change some rendering rules. Don't know about the other things, but this remark peeked my interest. What rendering rules had changed, and why would you feel the need to rerun generate_xml.py for them? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multilingual Maps Overlays
On 20-6-2010 18:48, Peter Körner wrote: Any format will do for a try. It'll be performed in the sql queries of the mapnik xml file, just as i did it here: http://svn.toolserver.org/svnroot/mazder/styles/osm-labels-poi/osm-labels.xml Isn't it much easier to create a postgresql view for each name:xx ? That way updating your stylesheet is just an 'svn up' away. Now you'd have to merge your changes into the updated versions. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multilingual Maps Overlays
On 20-6-2010 19:59, Peter Körner wrote: Am 20.06.2010 19:26, schrieb Lennard: That way updating your stylesheet is just an 'svn up' away. Now you'd have to merge your changes into the updated versions. But I have a custom stylesheet anyway - take a look at the xmls ;) Ah, I see. I think all those non-text elements in a label stylesheet threw me off! :) -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Multilingual Maps Overlays
Maybe I should just keep all the geometry objects and just set opacity=0 on them. It's not the geometry objects (roads, water, etc,) that you need to preserve. They don't play a role in the collision avoidance placement routines. Direct your attention to any PointSymbolizer, ShieldSymbolizer and TextSymbolizer if you want to experiment with opacity. Some text elements might still be better in the base map. House numbers come to mind. Oh, and don't forget this will increase the memory consumption again. Not as much as with 200+ complete stylesheets, since you don't need to keep LineSymbolizer/Polygon(Pattern)Symbolizer around, but still worth to keep an eye on. I'll give it a try this evening. In the meantime - do you have a link where you see this problem, so I can test with it? Any moderately dense area would do, but I tested with Soho: http://toolserver.org/~osm/locale/?zoom=17lat=51.51391lon=-0.13035layers=BTFF -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql diff mechanics
Now my question: If I cleaned a geometry (e.g. forest) and a diff specifies a change in this geometry, what will happen? 1.) Will the geometry completely be replaced by the new geometry as specified in the diff. As far as I expect it to work: The diff will be applied to the slim mode tables (_nodes, _ways, _rels) and then a new geometry will be built and added/updated in the applicable geometry tables (_point, _roads, _line, _polygon). -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql diff mechanics
I have a related question. What might be the best procedure to follow if I just want to keep the Finnish excerpt up to date? I have been using the Geofabrik country file and osm2pgsql, but now it takes about 40 minutes to run and some 20 minutes more for some updates and extra indexes etc. which I want to have. Is it possible to generate something like Finland.diff files to be used with osm2pgsql for updating the PostGIS database? I have You can update an extract with the global diffs. Use the bbox parameter for osm2pgsql to limit the working area to the area of your extract. You can also keep an extract.osm up to date using osmosis. Apply the diffs in osmosis and then apply a bounding box/polygon filter before writing out the updated osm file. been thinking that all that I would really need would be osm_point, osm_line and osm_polygon tables, and all those three would only need one attribute field, tags as hstore datatype. All the rest I could do with SQL inside database. You are required to have the slim mode tables (nodes,ways,rels) to be able to apply diffs. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Opening File from mobile Device
On 6-6-2010 21:26, Thomas Ineichen wrote:
I use a Windows Mobile Device with OSMtracker for mapping. When I plug it
to my PC (Windows 7) via USB, the device appears under My Computer as a
Mobile Device ('Tragbare Geräte', no drive letter assigned). With JOSM, the
Open-Dialog only shows my harddisk- and DVD-drives. Thus I have to copy my
tracks to the HDD first and then open it in JOSM.
Is that a general Java-problem and/or is there any workaround?
It's due to the way the device appears under Windows. You can also not
directly open pictures on the device storage, for instance, but have to
copy them off first.
Some devices (like mine) can have the storage card appear as a true USB
storage device, and then you can use it from within JOSM as well.
--
Lennard
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 8:28, John Smith wrote: It occurred to me a few weeks ago that ways shouldn't be tagged with the admin_level, but instead use the information from relations, but How did this occur to you? Tagging the ways is even explicitly documented on the wiki. this doesn't work, in fact I removed the admin_level tag from a way that makes up part of a state border assuming the information would be used from the relation instead, but it just didn't render at all until I reinstate the admin_level on the way. If the relation forms a closed loop, and is tagged as a boundary, it should currently render. I haven't figured out what needs to be fixed in the mapnik style sheet to fix this, can anyone tell me what needs tweaking to fix this? Should work currently. The major drawback to also drawing boundary relations is that they can stack (in osm2pgsql+mapnik). Where a tagged boundary way is part of n boundary relations, you will see n+1 overlapping lines in the render. IMO this is ugly, and you get no sense of the actual admin levels involved. Rendering just the boundary way makes for a clean border render, with a predictable appearance. To this end, the wiki documentation describes tagging the way with the highest order (lowest value) of admin_level. As far as I'm aware, ti...@home already take this approach, and does not render boundary relations. I trust people will now bring the don't tag for the renderer mantra into play, but in my mind, a boundary relation(*) describes the polygon, so the administrative *area*, and the ways describe the demarcation between administrative areas. Thus, it's the ways that should appear on the rendered map, not the area. *) Actually tagged as a multipolygon, because, hey, that's what it really is. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 9:27, John Smith wrote: That makes no sense when rendering can derive it from relations to pick the most important (lowest admin_level value) without people needing to know which way is part of which relation. You are on the same train of thought I was on a year or so ago. Ok, here's the way and here's the relation and here's the rendering, please explain why it's not rendering the relation how ways nearby render: Looks fine. I can't look into the osm.org tile server db to see how it wound (or didn't) up in there. Could be any of a number of reasons. So you admit the logic can be problematic with the rendering, doesn't that mean we're tagging incorrectly for renderers? Don't tag the member boundary ways, and you're right. Ok so you admit there is a problem with rendering, but instead of There is no problem with rendering. The renderer just renders what is there, which includes tagged member ways. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 10:46, John Smith wrote: They render as lines instead of areas, but they still render, I've dealt with this issue a lot of time with broken postcodes in Australia, fix the relation you fix the rendering... type=multipolygon boundary relations do not render. Just realised after sending my previous reply. The fix is easy, the result gobsmackingly ugly (read: overlapping lines). That doesn't solve the issue, that just excludes information from relations, we need to use relation information if the way information doesn't exist, similar to the way information from relations work for other objects. That cannot be solved from mapnik. This is a job to be done during the db import for mapnik, both for non-slim mode (a one off job) and slim mode imports, which have to take into account loading diff files. At some point, it just sounds much simpler to correctly tag the member ways. This is *not* wrong, they *are* boundary demarcation lines. This is the order things need to be found, through a subselect or join, after finding distinct segments, from those segments we need to sort by way admin_level, and then by relation admin_level, simply excluding information only glosses over the issue by excluding broken multipolygons. By the time mapnik sees the data, it has been processed. Relations could have been converted into line geometries, and there is no way for mapnik to discern those from the proper ways, other than the test for osm_id0. I suggest you play around with a limited dataset, and see how that ends up in the pg db, in which tables, for different taggings. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Getting admin_level=* from relations to render properly
On 28-4-2010 10:58, Iván Sánchez Ortega wrote: So you admit the logic can be problematic with the rendering, doesn't that mean we're tagging incorrectly for renderers? Don't tag the member boundary ways, and you're right. So what? Area boundaries will be rendered twice, once per area. You'll be back at the start :-/ I know, that wasn't my point. John argues boundary way tags shouldn't matter, when the way is a member of a boundary relations, and it should inherit some admin_level from those. He implies it's unnecessary tagging for the renderer. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] add_parking_node function in osm2pgsql?
On 9-4-2010 0:36, Sven Geggus wrote: fiddling with the code of osm2pgsql I came across the add_parking_node function which does not seem to be called anywhere as far as I can tell. Can anybody confirm this? Confirmed. Rendering of symbols for areas has been implemented last year, and this piece of code wasn't necessary anymore. There's another few functions that aren't being called anymore, either. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Where are the slippy map chooser tiles cached?
On 8-4-2010 23:31, MP wrote: No. This is where WMS tiles are cached. Slippy map chooser caches it in temporary directory (/tmp on unixes, %TEMP% on Windows machines, which is usually C:\Documents and Settings\Username\Temp) and it creates JMapViewerTiles_Username directory there in which it stores the cached tiles. On my machine, I can find them in: %USERPROFILE%\Local Settings\Temp\JMapViewerTiles_%USERNAME%\Mapnik The way the tiles are stored (all in a flat dir) makes any file operations in the Windows Explorer (in XP) almost impossible, because it incurs very long delays in processing the dir. Mine a few weeks after clearing: 41877 files, 174700223 bytes Fortunately, clearing them from the command prompt is still fast. I wonder why they cannot be stored one dir per zoom, or in another hashing format. -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] problem with mapnik
Ruggero wrote: what's this? Did I forget something? It means you never had a complete map in the first place, but the new mapnik version now points out these syntax errors in the stylesheet instead of silently ignoring that layer. Update your stylesheet. You haven't done that in at least 7 months[1]. Be aware that osm.xml has changed substantially since that time, so be sure to read the documentation again. [1] http://trac.openstreetmap.org/changeset/17301 -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] problem with mapnik
Ruggero wrote: Replying to reply which went direct to me instead of dev@ Update your stylesheet. You haven't done that in at least 7 months[1]. Be aware that osm.xml has changed substantially since that time, so be sure to read the documentation again. [1] http://trac.openstreetmap.org/changeset/17301 thanks, now an other problem: MAPNIK_MAP_FILE=osm.xml MAPNIK_TILE_DIR=tiles/ ./generate_tiles.py RuntimeError: PSQL error: FATAL: Ident authentication failed for user ruggero (encountered during parsing of layer 'leisure') Did you run generate_xml.py or manually edit inc/datasource-settings.xml.inc ? Is your username and password in that file? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Josm Preparing data set... message
Maarten Deen wrote: I was wondering, when you have an incomplete relation in JOSM and you download the missing parts, the download dialog box at some point switches to Preparing data set What is JOSM doing then? Is it downloading more data or is it doing something like organizing the data it downloaded? It's downloading all the nodes that are part of the member ways. If you have the console open, you can see this. There is no progress dialog at this point, and you have to guess how long it will take. http://josm.openstreetmap.de/ticket/4650 -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Getting the replication-sequenceNumber by date
Peter Körner wrote: I'll make it a little nicer soon but it works. It updates every half hour, so the very recent sequenceNumbers aren't available. Very nice, simple, quick. The half hour delay could be gone if this service ran on the diff server (or close to it). -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing Minutely and Hourly Changesets
The heavies task is 1. Maybe we could set up a database for this task.. Peter I rather liked Brett's earlier suggestion to have this solved on the diff server itself. So you could wget http://diffserver/state/minute/20100301_00;, and the web service would find the right state file and return it to you. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql hstore support
Sven Geggus wrote: Now we would just need something like this: select way,(tags-'man_made') as man_made FROM planet_osm_point where ((tags-'man_made') is not NULL); What am I getting wrong here? Nothing. This will work. Mapnik just expects the name used in a filter to correspond with a column name in the resultset, nothing fancy about that. The 'as man_made' takes care of this. Very cool this. What's the speed to access the hstore column, compared to the generic columns we now have? On the one hand, this has the potential to greatly increase the size of the db, as you will now get all kinds of tags you're never interested in. On the other hand, one can now quickly use keys one never used before, without the need to reimport the whole db. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] My Maps Appear to be Predicting Global Warming.
Richard Ive wrote: I've had my rendering server running for a good 3 months now, and the only problem I had with it was that within the last month mod_tile took The one major cause of flooded tiles is when mapnik doesn't process the coastline shapefiles. At z10, it switches from the lowzoom shoreline_300 to the full resolution processed_p shapefile. So focus your effort on that one. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] planet-100127.osm delayed
Grant Slater wrote: An earlier planet-100127.osm dump failed. The dump process has been restarted and is expected around Midday (GMT) tomorrow 28th Jan 2010. How's the planet coming along? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile svn's project variables 1)hardcoded 2)in many files
Jonathan-David SCHRODER wrote: for our project (Geopard) which does indoor outdoor mapping, we need zoom levels up to 24 or so. mod_tile's svn's render_config.h defines a constand #define MAX_ZOOM 18 (and also MIN_ZOOM) but this constant is used in only 2 or so files and the rest of max zoom values are hardcoded (just grep for 18 in the svn and you will find them)... The only 2 hardcoded z18 references I could find for renderd/mod_tile proper were in gen_tile.cpp. The other references are in the python support scripts, none of which play a crucial role in normal renderd operation. Unless you use renderd.py instead of renderd, that is. There is another hardcoded 18 in there. I increased my renderd to z19 for haiti related tiles, and that was as easy as changing those 2 hardcoded '18' occurences and the MAX_ZOOM define to 19. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] amazon AMIs for a full blown openstreetmap.org-like server
jamesmikedup...@googlemail.com wrote: Ok, well I am going to first work on making the mapnik be able to render an osm file standalone without postgis, will report back when that works. *cough* http://trac.mapnik.org/browser/trunk/plugins/input/osm Will not work with the postgis-based stylesheet. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
David MENTRE wrote: No. As far as I know, Mapnik icons for PDF are bitmaps. We are using Mapnik, so any request regarding rendering should be adressed to Mapnik. If you know how to use vector icons in Mapnik, I'll be glad to know it. :-) Vector (SVG) symbols in mapnik are a work in progress, and not currently implemented in the main codebase. http://trac.mapnik.org/ticket/320 -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
Matthias Julius wrote: Are higher resolution icons an option? Probably, but you'll need lots of different sizes for different sized areas. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Maposmatic-dev] Questions on Nominatim and administrative boundaries + osm2pgsql
David MENTRE wrote: Is this the right way to do it? Can we assume that, when nominatim returns an entry with class=boundary type=administrative and osm_type=relation, then we can safely query the planet_osm_line table with the _opposite_ of osm_id? A _way_ will be in the tables with a positive osm_id, where a _relation_ will always have a negative osm_id. This is due to non-unique numbering between OSM object classes. Nominatim tells you* whether you got back a relation or a way, and you can then search for the negative or positive osm_id in planet_osm_polygon, for relations or closed ways, respectively. * At least, it does so in http://nominatim.openstreetmap.org/details.php?place_id=49949948 but I don't know what the bare API result looks like. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing Minutely and Hourly Changesets
Brett Henderson wrote: Are there any objections to me disabling the old minute and hourly changesets and deleting their files from the planet server? No objections from me, but you might take your time, between this announcement/request and actually removing them. I haven't heard any complaints about the replication changesets so I'm assuming they're working well. I've been working with them since about day 1. They work wonderfully well, especially with that one-off bug fixed. I'll leave the daily changesets running for now because they are running with a much longer delay and shouldn't miss data. And are probably used in a lot more automated processes, to create a new planet (extract) every day. I know we do it for planet.openstreetmap.nl, and hypercube uses the same daily diff files for the Coastline Error Checker. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] duplicated entities with osmosis diff-update
Frederik Ramm wrote: osmosis --rci workingDirectory=/path/dir --rx old.osm --ac ... I think if you throw in a --simplify-change before the --rx then it should work! I haven't tried, just that Brett wrote in a recent mail to osmosis-dev that he has introduced this new undocumented feature. Be aware that --simplify-change is meant to be used with the replicating diffs, and --rci is used to process the old-style (non-replicating) diff files. Harald, you might want to investigate the newer --rri task. There is no formal documentation yet, but the second part of http://wiki.openstreetmap.org/wiki/Minutely_Mapnik should tell you most of what you need. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql - Planet.osm fail - Unknown Element name : changeset
Marc Schütz wrote: Changesets are only included in planet.osm since a few weeks, right? As the file linked in the wiki is from July, it will not help him. Since the API 0.6 switchover. If you let the older osm2pgsql continue until it parses the planet past the changeset tags, it will still work correctly. Newer versions just ignore the tags. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] set-mapnik-env stage of rendering tiles
Kuba Z. wrote: bash: set-mapnik-env: command not found What am I missing? The new README file. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] set-mapnik-env stage of rendering tiles
Kuba Z. wrote: Hi Ingo, Thank you for reply. In fact there was some typo in my osm-template.xml. I used the freshly downloaded file now but the result is just the same (blank osm.xml). There are two things going on here: 1) You downloaded the wrong mapnik. You mentioned an include file with *.hpp files. That's the mapnik software repository. What you need to render the 'mapnik' map from osm.org is actually another repository: http://svn.openstreetmap.org/applications/rendering/mapnik/ 2) You're working from outdated guides on the wiki, that haven't been updated to reflect the new method of setting up the stylesheet for your environment. You don't need the osm-template.xml anymore. Read http://svn.openstreetmap.org/applications/rendering/mapnik/README and the generate_xml.py script. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Importing planet file with osmosis into PostgreSQL
Frederik Ramm wrote: The planet files do not have referential integrity. Because the ways are dumped long after the nodes, if someone creates a new way plus new nodes some time during the planet dump creation, the new way will be in the dump but the new nodes will not. I thought that was fixed, and the dump now runs in a transaction? It would thus more likely point to data that is in fact incomplete in the OSM db itself? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] JOSM is the editor with the best user retention
Paul Johnson wrote: created_by= tags get stomped by Potlatch, JOSM leaves it alone if it's already set (unless, of course, a JOSM user deliberately deletes the existing created_by tags). This would give severely skewed results in favor of Potlatch. You would be correct, if you would've said it about 6 months ago. http://josm.openstreetmap.de/changeset/1720 http://josm.openstreetmap.de/changeset/1735 -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Split osm line with perl
Maarten Deen wrote: I've tried a few things, but I'm not fluent in perl. My problem at the moment is that splitting a line on the space character seems logical, but you run into problems if a value has a space in it. So splitting something like tag k=name v=foo bar/ will split the value foo bar also. You have to be fluent in regexes, not perl as such. The trick is to match the quote, then to match anything that is not a quote, followed by a quote. #!/usr/bin/perl my $str = tag k=\name\ v=\foo bar\/; $str =~ /k=([^]*) v=([^]*)/; my ($k, $v) = ($1, $2); print k = '$k', v = '$v'\n; Difficulty: are values with quotes allowed in k/v pairs? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Split osm line with perl
Dave Stubbs wrote: And then hope that the attributes are in the order you're expecting, and that the XML has used rather than '. And in the example code given below hope that only one space was used. Adding that to the example code I gave would detract from the actual matching of what he asked, since he seemed to be stuck on using 'split' instead of a regex. I know it isn't ideal, given the way XML works, but he'll have to work out those difficult bits for himself. ;-) -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Apply a change to .osm file problem
Vladislav Shikhov wrote: I tried to apply a change to .osm file (not a planet but russia only) and got an axception: ./osmosis-0.31/bin/osmosis -v --read-xml file=rf.osm --read-xml-change-0.6 file=20091031-20091101.osc --write-xml file=new-rf.osm You forgot --apply-change, and osmosis expects to read the changefile first: osmosis -v --rxc 20091031-20091101.osc --rx rf.osm --ac --wx new-rf.osm -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Apply a change to .osm file problem
Vladislav Shikhov wrote: Lot of thanx. :) Keep in mind that after this diff has applied, you will then have objects outside of Russia in your new-rf.osm. If you do not want that, you need another task (--bounding-polygon): osmosis -v --rxc 20091031-20091101.osc --rx rf.osm --ac --bp file=your russia polygon.poly --wx new-rf.osm Or, in case rf.osm was created with a simple bbox, the appropriate --bounding-box task. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Empty statefile in minute-replicate breaks osmosis
Teemu Koskinen wrote: There's an empty statefile[1] which breaks osmosis: ... http://planet.openstreetmap.org/minute-replicate/000/073/922.state.txt I could get around it by downloading and 922 and 923, and feeding those to osm2pgsql by hand. Then I downloaded 923.state.txt as the next state.txt to use for the --rri task, and my minutely update script was happy again. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Strange Mapnik rendering
Maarten Deen wrote: Is there an explanation why Mapnik renders the unclassified road on top of the primary road in this example? http://www.openstreetmap.org/?lat=51.35217lon=6.01257zoom=17layers=B000FTF Yes, partly: rendering order is broken in certain situations, mostly related to layer=* issues. I tried to hint to Mapnik that the unclassified road should not be rendered over the primary by adding a layer=-1, but that didn't help. The roads are on the same level. Don't tag for the renderer. If the roads are on the same level, they should have the same layer tag. And if they have the same layer tag, rendering is partly first-in-first-out, and partly hard to explain because of the current obfuscation level in the stylesheet. Having said that, there could be some basic rules in the renderer. Like draw all link roads first, then all lower class roads, followed by higher class roads. We'll get there soon enough, but the stylesheet is in some major flux right now. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hourly diffs are missing edits (too)
Frederik Ramm wrote: Hi, so we know that the minutely diffs are broken (and we have created the minutely-replicate diffs instead; something that I had completely missed until it was mentioned casually a few days ago - can osmosis --rci be run on them or do they require special treatment?). There are corresponding --rri and -rrii tasks for the replication based diffs. I got these to work by doing this: Initialiasing: osmosis --rrii workingDirectory=. You'll have a configuration.txt at this point. It has a wrong URL for the minute-replicate diffs, so correct that. Then run the main task once: osmosis --rri workingDirectory=. --wxc diffs.osc.gz That fetches a state.txt from the server. It's likely you'll want to pick up the diffs at some earlier point in time. Go to the diff server and find the right state.txt with a timestamp for the time at which you want to pick up the diffs. Download that and put it as state.txt in your workingDirectory. Brett has stated that it's best to have an overlap, so personally I start from a diff 3 to 4 hours before the timestamp I actually want. It's also possibly I'm misunderstanding, or that Brett was overly cautious, and you can keep the overlap to a minimum. From that point on, you can run osmosis --rri and output to a change file, or pipe it into other tools: osmosis --rri workingDirectory=. --wxc | osm2pgsql -a . By default, it fetches one hours worth of diffs at each run. You can change that in configuration.txt. But until now I had assumed that at least the hourly diffs were correct which probably was naive - I guess that it is just *less likely* for them to miss out on something than the minute diffs, but not impossible? Yes, even the daily diffs can miss some objects, because of the same reasons, although it's even less likely than with the hourly diffs. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Trouble with osm2pgsql and Postgres 8.4, Postgis 1.4
Tom Hughes wrote: Well that certainly fails for me: Rel. 4.6.1, 21 August 2008 Worksforme Rel. 4.7.1, 23 September 2009 -- Lennard ___ 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
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] 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
Re: [OSM-dev] Black Roads
Peter Körner wrote: It seems there are some bad rules in the mapnik styles for highway=motorway_link / highway=motorway with bridge=yes. Ah, the missing info in the original mail was that he rendered it himself. I went looking at osm.org for those black roads, but couldn't find them and assumed it was a fluke, and already fixed. Richard, before you go on a quest to find those bad rules in the mapnik styles, could you update your render toolchain* to the latest versions and then try again? * osm2pgsql, default.style, osm.xml, mapnik I predict that when you take a look in the postgresql logs, you'll see queries that have failed because of missing columns, or whatnot. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
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
Re: [OSM-dev] shortest streets
Stephan Knauss wrote: So could you specify a better projection that would be equidistant? The data here uses 900913. Would 4326 be equidistant? FWIW, this is what I'm using on my cycle map: ST_length_spheroid(transform(way,4326),'SPHEROID[WGS 84,6378137,298.257223563,AUTHORITY[EPSG,7030]]') Note the space in WGS 84. Is there a difference between st_length() and length()? They both return the same values (at least for 900913). Same thing, but the ST_ is the newer version, thought up to distinguih spatial calls. Postgis manual has a similar query to sum up the length of ways. Why is it working there? Different projection? I guess it's just an example of the ST_length() function as is, not taking into account any projection issues. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shortest streets
Stephan Knauss wrote: something like this? select osm_id, st_length(way) as length from planet_osm_roads order by length asc limit 10 Something, but not exactly that. ST_Length(way) is in projected meters, which varies with latitude. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] How to: Running JOSM from an USB stick - without JAVA installed on the target machine!!!
Ulf Lamping wrote: That made me think if it might be possible to install JAVA and JOSM on an USB stick and run JOSM on any suitable Windows machine without any further installation on the target machine. It seems to be possible! It is, I had this working last year. I followed the guide on http://wiki.openstreetmap.org/wiki/JOSM/HOWTO/Run_from_flash_disk_with_Java -- Lennard ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Keeping .osm database up-to-date
Richard Ive wrote: Sorry for being a noob, but what is the perpose of threading it though osmosis using -rci. Why not run a cron that does ./osm2pgsql -a ../diff.ocm? Osmosis --rci takes care of downloading and merging of diffs for you. Say your cron doesn't run for a while, for whatever reason. Osmosis remembers the last diff it downloaded, and will pick up where it stopped, merge all more recent diffs that it finds, and pipes that to osm2pgsql in one stream. Say your diff import takes more than the time between your cron runs, and again, it's very handy that osmosis takes care of a lot of diff bookkeeping for you. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Richard Ive wrote: Is http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--read-change-interval_.28--rci.29 the only documentation available for this? The example on the Minutely Mapnik wiki page is useful too, but yeah, your link points to the official osmosis documentation. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Bug: Mapnik renders 'addr:housenumber' rather than 'name'
andrzej zaborowski wrote: 2009/9/5 Dan Homerick danhomer...@gmail.com: Is the algorithm that decides what text to render relying on the order? No, mapnik doesn't even know what the ordering in the OSM db is, but even then it wouldn't matter. Tags aren't ordered afaik, it's somewhere in the mapnik style and I noticed the problem is caused by some recent change in the style because the building names have all disappeared in my city this or last week. There are 2 tickets about this, and it's something that will be looked at soon. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Proposal: Multiline country, state, city names?
It would be very good if someone could modify render to wrap or to make multiline names so they fit better to object named. Currently, those country names are entered as nodes. The mapnik renderer has no idea how large the area of the respective country is, so there is no information to drive a line wrap decision. A possible alternative is tagging place=country on an area, or by logical extension: a relation. Those do not render quite correctly at the moment, but there is a current ticket for mapnik requesting this feature be added. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Proposal: Multiline country, state, city names?
But I don't think that mapnik would be able to solve the problem. We should be looking at some kind of bot, similar to the coast checker, to relate all the borders of one country into one big closed polygon. Which is exactly what osm2pgsql has been doing for some months now. If the members of a boundary relation (either type=boundary or type=multipolygon, doesn't matter) form a closed ring, they also get added to planet_osm_polygon -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] renderd
Should the renderd daemon stay running for ever once you have done $./renderd ? Mine stays running for about 30seconds, then vanished from ps -ef, then tiles don't get rendered. Have I missed a step? Yes, it should. It's probably hitting an error situation along the way. Try running it with ./renderd -f, which will make it run in the foreground. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] renderd
Replying to list again... Richard Ive wrote: Output: ... ... renderd[7412]: DEBUG: Got command Render fd(13) xml(default), z(14), x(8257), y(5463) renderd[7412]: DEBUG: DONE TILE default 14 8256-8263 5456-5463 renderd[7412]: DEBUG: Got command Render fd(12) xml(default), z(14), x(8255), y(5462) renderd[7412]: DEBUG: DONE TILE default 14 8248-8255 5456-5463 renderd[7412]: DEBUG: Got command Render fd(17) xml(default), z(15), x(16508), y(10928) Segmentation fault Oh dear, not a simple issue of missing fonts or syntax error in the stylesheet, then. Do you at least find some tiles in the tiles dir you set in the config? Are you running the latest version from svn? Are your other components up to date? -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
