<div dir="ltr"><div><div><div><div><div><div><div>Hi Mikel et al.,<br><br></div>Has anyone looked at performance issues with PostgreSQL. <br><br>When I tried something similar a couple of years ago with Peter Koerner's Berlin History data I had problems because my constraints on start & end date caused the optimiser to not pick any of the GIST indexes on the geometry columns (which would have been much more performant).<br>
<br></div>I can't remember how complex the queries were & the relevant database is now in an archive, plus relevant data volumes were high (overview <a href="http://sk53-osm.blogspot.co.uk/2011/05/on-histories-of-openstreetmap-data.html">here</a>).<br>
<br></div>A quick scan in a project folder suggests the way I did it was using views like this:<br><br><div style="margin-left:40px"><span style="font-family:courier new,monospace">CREATE OR REPLACE VIEW planet_osm_line AS <br>
 SELECT w.osm_id, w.version, w.access, w."addr:flats", w."addr:housenumber"<br> , w."addr:interpolation", w.admin_level, w.aerialway<br> , w.aeroway, w.amenity, w.area, w.barrier, w.bicycle, w.bridge, w.boundary<br>
 , w.building, w.capital, w.construction, w.cutting, w.disused, w.ele<br> , w.embankment, w.foot, w.highway, w.historic, w.horse, w.junction<br> , w.landuse, w.layer, w.learning, w.leisure, w.lock, w.man_made<br> , w.military, w.motorcar, <a href="http://w.name">w.name</a>, w."natural", w.oneway, w.operator<br>
 , w.poi, w.power, w.power_source, w.place, w.railway, w.ref, w.religion<br> , w.residence, w.route, w.service, w.shop, w.sport, w.tourism<br> , w.tracktype, w.tunnel, w.waterway, w.width, w.wood, w.z_order, w.way, 0.0::float as way_area, w.date_from, w.date_to<br>
   FROM planet_osm_way_merge w, notional_date<br>  WHERE notional_date.not_date >= w.date_from AND notional_date.not_date <= w.date_to<br></span></div><br></div>The notional_date table just was a 1 row, 1 column table to enable me to avoid having to change the mapnik stylesheet at all, and was changed in the python script for each render run. Anyway the queries ran several hundred times slower than expected because the optimser picked the date_from column index rather than the geometry one which would have been much more selective.<br>
</div><div><br></div>I have no idea if this is anything close to what you guys are working on, but thought it might be worth sharing in case you hit similar problems.<br><br></div><div>I also have a vague notion that it's better to have two predicates on the dates rather than using BETWEEN because the optimiser doesn't seem to automatically re-write the BETWEEN predicate during parsing.<br>
</div><div><br></div>Cheers,<br><br></div>Jerry<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 7:09 PM, Mikel Maron <span dir="ltr"><<a href="mailto:mikel_maron@yahoo.com" target="_blank">mikel_maron@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div><span>Jerry</span></div><div style="font-style:normal;font-size:16.363636016845703px;background-color:transparent;font-family:'times new roman','new york',times,serif">
<span><br></span></div><div style="font-style:normal;font-size:16.363636016845703px;background-color:transparent;font-family:'times new roman','new york',times,serif"><span>Today, we're looking at switching to the Carto stylesheet as a starting point, and adding in variables to filter on start_date and end_date. We'd manage the carto in github, so totally possible to experiment with styles. Will let everyone know how the sprint turns out today.</span></div>
<div style="font-style:normal;font-size:16.363636016845703px;background-color:transparent;font-family:'times new roman','new york',times,serif"><span><br></span></div><div style="font-style:normal;font-size:16.363636016845703px;background-color:transparent;font-family:'times new roman','new york',times,serif">
<span>-Mikel</span></div><div></div><div> </div><div>* Mikel Maron * <a href="tel:%2B14152835207" value="+14152835207" target="_blank">+14152835207</a> @mikel s:mikelmaron<br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px">
  <div style="font-family:'times new roman','new york',times,serif;font-size:12pt"> <div style="font-family:'times new roman','new york',times,serif;font-size:12pt"> <div dir="ltr"> <hr size="1">
  <font face="Arial"> <b><span style="font-weight:bold">From:</span></b> sk53.osm <<a href="mailto:sk53.osm@gmail.com" target="_blank">sk53.osm@gmail.com</a>><br> <b><span style="font-weight:bold">To:</span></b> <a href="mailto:historic@openstreetmap.org" target="_blank">historic@openstreetmap.org</a> <br>
 <b><span style="font-weight:bold">Sent:</span></b> Monday, June 10, 2013 8:50 AM<br>
 <b><span style="font-weight:bold">Subject:</span></b> [OHM] Modifying the default renderer<br> </font> </div> <div><div><div class="h5"><br><div><div dir="ltr"><div><div><div><div><div><div><div>I've been looking at the Seattle data and feel a bit dissatisfied with how the data looks. I realised that my issue was the early grid being represented as tracks.<br>
<br>
</div>I believe that we should try and use a functional classification of highways for all historical periods, and keep the actual physical condition (whether a residential street is a muddy trackway, a narrow alley filled with ordure or a stone paved road with raised sidewalks) in distinct tags.<br>

<br></div>For most historical periods values of highway=motorway, trunk, motorroad will be irrelevant, but I think there will always be at least two classes of highways loosely corresponding to longer distance roads, and local routes: for now I would suggest continuing to use primary/secondary. I'm not sure that tertiary is relevant in the pre-car age. We should also consider whether specific tags are needed for pack-horse trails & mule paths: the remnants of both are common across Western Europe, usually now tracks or bridleways.<br>

<br></div>Whatever tags are used I think the appropriate cartography for main highways needs to be much more muted that what I've learnt is the "Telly Tubby style". One potential point of inspiration is the cartography of older editions of the Ordnance Survey's Roman Britain map (extract <a rel="nofollow" href="http://www.bibliographics.com/MAPS/BRITAIN/BRIT-MAP-FRAME-25.htm" target="_blank">here</a>). WIth a single cartographic style covering multiple periods I think we should aim to be fairly conservative. Furthermore there are many style rules which can be removed. <br>

<br></div>Obviously any changes should wait until the main OSM site goves over to the CartoCSS style sheet. However, I think it's worth kicking off a discussion about both tagging & cartography at this point, before too much data is entered. So far it's only highways which have caught my attention: there may be some other feature classes which need a more period-neutral cartography.<br>

<br></div>Regards,<br><br></div>Jerry<br><br></div>PS. I'd love to hear a resume of the BoF session in SF.<br></div></div><br></div></div>_______________________________________________<br>Historic mailing list<br><a href="mailto:Historic@openstreetmap.org" target="_blank">Historic@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/historic" target="_blank">http://lists.openstreetmap.org/listinfo/historic</a><br><br><br></div> </div> </div> </blockquote></div>   </div></div></blockquote></div><br></div>