Subject: Re: [OSM-dev] [OSM-talk] Landsat and waypoints in JOSM - msg#00236

Previous Message by Date: click to view message preview

[OSM-dev] OSM renderer -- which way now?

With a good deal of discussion on how to speed up the database queries, I'd like to raise the issue of what the future is for the OSM renderer. I'm particularly interested in this regarding Freemap; what I'd kind of like to do with Freemap is to use the default OSM renderer, but configured so that the maps are drawn in a "Freemap" style. One option would be to keep a live renderer as now. If the bottleneck is with SQL queries and caching, and SQL queries and caching can be optimised (as extensively discussed on another thread) this would seem viable. Another option would be to develop something else which runs off planet.osm, or a read-only version of the database. My gut feeling and personal preference w.r.t Freemap (warning - not backed up by research) would be to develop something custom rather than use Mapserver; it seems to me that something designed from the ground up using OSM's data model (e.g with Map Features as a core feature of any configuration) would be more easily configurable by OSM users, and you wouldn't be battling against another data model. This could be configured by a MapFeatures.xml file (as suggested by Joerg) or an osmarender rules file. If we did this there could again be a number of options: - use existing Ruby code. Pros: less maintenance overhead, performance issues could be lessened by good caching. Cons: performance. - use the fastest possible language, i.e. C. Pros: performance; other systems like mapserver use C. Cons: more maintenance. Part of this code could involve exporting to other formats such as shapefiles, for interoperability with other applications. If people agree that a configurable renderer, a custom OSM solution would be a good thing (from the point of view of freemap, I would certainly say so) I will prioritise this in my list of coding tasks, and get going on it. But if people *don't* see this as good, again let me know as I don't want to waste time coding something which will not be used :-) Nick

Next Message by Date: click to view message preview

Re: [OSM-dev] Tile and dev down

Tile++ is now up and running. Tile is still struggling, but working. Dev is up and running, with a copy of planet.osm on the database ready for eager developers. Spent about 6-7 hours today travelling, fixing, updating, testing, changing hard drives, servers. I found an option in both dev and tile for the machines to turn on on power-up. The option only worked on tile, so have bypassed soft power on dev. Hopefully dev will start again in the event of a power interruption. This is by no means certain as dev seems to be ailing. Gave flashing greek on screen on several start-up attempts. Nick Hill wrote: > Raphael Jacquot wrote: >> Nick Hill wrote: >>> A power interruption at 07:09 saturday morning possibly explains dev >>> and tile being down. These machines don't automatically power up after >>> power interruption. >>> >> that should be a setup option in the bios >> "what do I do when power comes in ?" "start up" > > Some machines don't have this BIOS option. I recall checking dev and > tile and they didn't seem to have the option. > > The db, www, and new tile machine which I built do have this option. > > It is possible to jump-lead the power supply connector to bypass soft > power off if this BIOS option is lacking. > > _______________________________________________ > dev mailing list > dev@xxxxxxxxxxxxxxxxx > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev >

Previous Message by Thread: click to view message preview

[OSM-dev] OSM renderer -- which way now?

With a good deal of discussion on how to speed up the database queries, I'd like to raise the issue of what the future is for the OSM renderer. I'm particularly interested in this regarding Freemap; what I'd kind of like to do with Freemap is to use the default OSM renderer, but configured so that the maps are drawn in a "Freemap" style. One option would be to keep a live renderer as now. If the bottleneck is with SQL queries and caching, and SQL queries and caching can be optimised (as extensively discussed on another thread) this would seem viable. Another option would be to develop something else which runs off planet.osm, or a read-only version of the database. My gut feeling and personal preference w.r.t Freemap (warning - not backed up by research) would be to develop something custom rather than use Mapserver; it seems to me that something designed from the ground up using OSM's data model (e.g with Map Features as a core feature of any configuration) would be more easily configurable by OSM users, and you wouldn't be battling against another data model. This could be configured by a MapFeatures.xml file (as suggested by Joerg) or an osmarender rules file. If we did this there could again be a number of options: - use existing Ruby code. Pros: less maintenance overhead, performance issues could be lessened by good caching. Cons: performance. - use the fastest possible language, i.e. C. Pros: performance; other systems like mapserver use C. Cons: more maintenance. Part of this code could involve exporting to other formats such as shapefiles, for interoperability with other applications. If people agree that a configurable renderer, a custom OSM solution would be a good thing (from the point of view of freemap, I would certainly say so) I will prioritise this in my list of coding tasks, and get going on it. But if people *don't* see this as good, again let me know as I don't want to waste time coding something which will not be used :-) Nick

Next Message by Thread: click to view message preview

Re: [OSM-dev] [OSM-talk] Another point in support of ways as ordered lists

I've switched this conversation to dev, its probably a bit heavy for talk.Looks like you've done the hard bit.  The same for nodes is easy:<xsl:choose>  <xsl:when test='name()="node"'>      <xsl:variable name='lat' select='@lat' />     <xsl:variable name='lon' select='@lon' />  </xsl:when>  <xsl:otherwise>    <!-- get lat and lon from first and last segment as ou are currently doing it -->   </xsl:otherwise></xsl:choose>(Written before my first cup of coffee and not tested anyway so don't expect it to work).EtienneOn 9/26/06, Robert Hart <Robert.Hart@xxxxxxxxxxxxxxx> wrote: Yes, I don't have a problem with the names. Anyway, it was just asuggestion. The problem I have is finding the location. For a node thelocation is attributes of the node, but for a way, you have to dereference the segments then nodes, and find a mid point.My current code just does ways (see below), but I'd like to include nodes asway:  <xsl:template name='keyDraw'>    <xsl:for-each select="$data/osm/way/tag[@k='name']">       <xsl:sort select="@v"/>        <xsl:variable name="col" select="floor(position() div (($height -40) div 6))" />        <xsl:variable name="row" select="position() - $col * floor(($height - 40) div 6)" />        <text font-family='Verdana' font-size='6px' fill='black'>          <xsl:attribute name='x'><xsl:value-of select='10 + $width +$col*80'/></xsl:attribute>           <xsl:attribute name='y'><xsl:value-of select='20 + 6 *$row'/></xsl:attribute>          <xsl:value-of select="@v"/>        </text>        <text font-family='Verdana' font-size='6px' fill='black'>           <xsl:attribute name='x'><xsl:value-of select='80 + $width +$col*80'/></xsl:attribute>          <xsl:attribute name='y'><xsl:value-of select='20 + 6 *$row'/></xsl:attribute>           <xsl:variable name='startseg' select='../seg[1]' />          <xsl:variable name='endseg' select='../seg[position()=last()]' />          <xsl:variable name='start'select='key("segmentById",$startseg/@id)' />           <xsl:variable name='end' select='key("segmentById",$endseg/@id)'/>          <xsl:variable name='startNode'select='key("nodeById",$start/@from)'/>          <xsl:variable name='endNode' select='key("nodeById",$end/@from)'/>           <xsl:variable name='lat' select='($startNode/@lat + $endNode/@lat)div 2' />          <xsl:variable name='lon' select='($startNode/@lon + $endNode/@lon)div 2' />          <xsl:value-of select="floor(($lon - $bllon) div 0.0089928)"/>          <xsl:value-ofselect="substring('ABCDEFGHIJKLMNOPQRSTUVWXYZ',floor((($lat - $bllat) div0.0089928) * $projection),1)"/>          <!--<xsl:value-of select="$start" />,           <xsl:value-of select="$lat" />,          <xsl:value-of select="$lon" />-->        </text>     </xsl:for-each>  </xsl:template> -----Original Message-----From: EtienneTo: Robert HartCc: Nick Whitelegg; talk-bounces@xxxxxxxxxxxxxxxxx ; talk@xxxxxxxxxxxxxxxxx Sent: 9/26/2006 9:29 PMSubject: Re: [OSM-talk] Another point in support of ways as ordered listsRobAn xpath _expression_ like $elements[tag[@k="name"]] will select all nodesand ways with a name tag.  You don't need to do anything special to combine nodes and ways, because the $elements variable is already a setof nodes and ways that match the rule (assuming the rule is <rulee="node|way">).If you want all the names in alphabetical order try something like: <xsl:for-each select='$elements[[tag[@k="name"]]/@name''>  <xsl:sort order="ascending">  ...EtienneOn 9/26/06, Robert Hart < Robert.Hart@xxxxxxxxxxxxxxx<mailto:Robert.Hart@xxxxxxxxxxxxxxx> > wrote:I just had a brain wave. If ways are ordered lists of nodes, then POIscan be ways containing only one node. This may sound odd, but I think it hasreal advantages (well at least one advantage anyway...)I've been playing around with creating map indices in osmarender. To dothis I need to know the name and approximate location of everything thatshouldbe included in the index. This means I have to handle nodes andways/areasseperately, which is going to be painful if I want the whole index in alphabetical order (as opposed to having separate indices for ways andnodes). If POIs were single-node ways, everything would just work withonecode path.RobThis message has been scanned for viruses by MailControl - www.mailcontrol.com <http://www.mailcontrol.com>_______________________________________________talk mailing list <mailto: talk@xxxxxxxxxxxxxxxxx> talk@xxxxxxxxxxxxxxxxxhttp://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk <http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk> _______________________________________________ dev mailing list dev@xxxxxxxxxxxxxxxxx http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev