Re: [osmosis-dev] nodes column in way table and way_nodes table

2011-12-22 Thread Brett Henderson
Hi Michel,

Yes, there is redundant data stored in the pgsnapshot schema.  It's there
for performance reasons.  If you compare the pgsnapshot schema to the
earlier pgsimple schema you'll notice that the way.nodes column is new, but
that the way_nodes table has always existed.  Both way-node mechanisms are
used for different purposes.

The pgsnapshot schema relies heavily on the PostgreSQL CLUSTER feature
where table contents can be sorted to align with one of the indexes.  The
nodes and ways tables are both organised by geographical location which
drastically improves performance when performing bounding box style queries
because data in the same geographical area will be stored close together on
disk.  The way_nodes table can't make use of geographical clustering which
means that joining the ways table to the nodes table via way_nodes is very
slow for large amounts of data due to large amounts of disk seeks.
Therefore the way-node information is duplicated inside the ways table for
fast lookup of nodes within ways.  This schema includes tags directly
against the node, way and relation tables in hstore columns for exactly the
same reason.  On typical SATA disks, the pgsnapshot schema performs
approximately 10 times faster than the pgsimple schema for bounding box
queries.

I can't drop the way_node table because it is still needed for two reasons
(may be others I've forgotten).  1. It is used for replication when a node
changes and the related way geometries have to be updated. 2. It is used
for bounding box queries if the ways table doesn't have any geometric
columns configured.

I hope that makes it clearer.
Brett
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev


Re: [osmosis-dev] nodes column in way table and way_nodes table

2011-12-22 Thread Michel Seuthe
Thanks for your detailed reply, Brett. Makes sense.

2011/12/22 Brett Henderson br...@bretth.com

 Hi Michel,

 Yes, there is redundant data stored in the pgsnapshot schema.  It's there
 for performance reasons.  If you compare the pgsnapshot schema to the
 earlier pgsimple schema you'll notice that the way.nodes column is new, but
 that the way_nodes table has always existed.  Both way-node mechanisms are
 used for different purposes.

 The pgsnapshot schema relies heavily on the PostgreSQL CLUSTER feature
 where table contents can be sorted to align with one of the indexes.  The
 nodes and ways tables are both organised by geographical location which
 drastically improves performance when performing bounding box style queries
 because data in the same geographical area will be stored close together on
 disk.  The way_nodes table can't make use of geographical clustering which
 means that joining the ways table to the nodes table via way_nodes is very
 slow for large amounts of data due to large amounts of disk seeks.
 Therefore the way-node information is duplicated inside the ways table for
 fast lookup of nodes within ways.  This schema includes tags directly
 against the node, way and relation tables in hstore columns for exactly the
 same reason.  On typical SATA disks, the pgsnapshot schema performs
 approximately 10 times faster than the pgsimple schema for bounding box
 queries.

 I can't drop the way_node table because it is still needed for two reasons
 (may be others I've forgotten).  1. It is used for replication when a node
 changes and the related way geometries have to be updated. 2. It is used
 for bounding box queries if the ways table doesn't have any geometric
 columns configured.

 I hope that makes it clearer.
 Brett


___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev


Re: [osmosis-dev] nodes column in way table and way_nodes table

2011-12-22 Thread Michel Seuthe
I got a question left... If i add the linestring-column to the ways table
_after_ I imported all the data, is there a way to fill this column without
re-import everything?

Cheers.


2011/12/22 Michel Seuthe m.seu...@googlemail.com

 Thanks for your detailed reply, Brett. Makes sense.


 2011/12/22 Brett Henderson br...@bretth.com

 Hi Michel,

 Yes, there is redundant data stored in the pgsnapshot schema.  It's there
 for performance reasons.  If you compare the pgsnapshot schema to the
 earlier pgsimple schema you'll notice that the way.nodes column is new, but
 that the way_nodes table has always existed.  Both way-node mechanisms are
 used for different purposes.

 The pgsnapshot schema relies heavily on the PostgreSQL CLUSTER feature
 where table contents can be sorted to align with one of the indexes.  The
 nodes and ways tables are both organised by geographical location which
 drastically improves performance when performing bounding box style queries
 because data in the same geographical area will be stored close together on
 disk.  The way_nodes table can't make use of geographical clustering which
 means that joining the ways table to the nodes table via way_nodes is very
 slow for large amounts of data due to large amounts of disk seeks.
 Therefore the way-node information is duplicated inside the ways table for
 fast lookup of nodes within ways.  This schema includes tags directly
 against the node, way and relation tables in hstore columns for exactly the
 same reason.  On typical SATA disks, the pgsnapshot schema performs
 approximately 10 times faster than the pgsimple schema for bounding box
 queries.

 I can't drop the way_node table because it is still needed for two
 reasons (may be others I've forgotten).  1. It is used for replication when
 a node changes and the related way geometries have to be updated. 2. It is
 used for bounding box queries if the ways table doesn't have any geometric
 columns configured.

 I hope that makes it clearer.
 Brett



___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev


[OSM-dev] 0.6 API read load balancer/proxy prototype with lower limits

2011-12-22 Thread sly (sylvain letuffe)
Hi,

Following :
http://lists.openstreetmap.org/pipermail/dev/2011-December/023945.html
http://lists.openstreetmap.org/pipermail/dev/2011-December/023981.html

I've set up a read load balancer/proxy to the main OSM API 

Better than a thousand words, here it is :
http://beta.letuffe.org/api/

It should be usable wherever any osm editors, tools, bulk downloader use 
http://api.openstreetmap.org/api
- For example, you can put this adresse in JOSM F12 - connexion - API url
- It only supports the France area for now (it's a demo)
- You need valid credential at the 0.6 API dev server : 
api06.dev.openstreetmap.org if you want write operations to work

In a few words why :

The main API server is applying sanity restrictions in order to limit per IP, 
per area or per elapsed time calls sent to it. This simple proxy is reducing 
such calls by answering the data request calls itself. It's only a prototype 
showing one solution among many others to accelerate read calls and reduce 
load on the main API server.

In a few words how :

When handeling a request,  any of map, node, way, relation, nodes, ways, 
relations and capabilities GET calls are converted to the overpass API 
syntaxe and forwarded to a local (or even could do to a distant) overpass API 
server.
When handeling any other PUT, POST, DELETE, WHATEVER or GET requests, it 
forwards the call to the 0.6 API dev server acting as a transparent proxy as 
much as possible.
Advantage beeing that no modifications are needed in the client if it supports 
the 0.6 API (beside changing the target URL of course)

note: Your credentials are clear text transmitted to my server, but no storing 
is done (you'll have to trust me or use unimportant credential from de dev 
server)

note: the dev server does not have a live copy of the main osm API, so any 
modification done to existing data will fail with a version error (you have 
to create fresh data to test it)

note: please DO NOT try to force re-upload to the live API unless you are very 
sure of what your datas looks like, because I suspect a few bugs to still be 
hidding around

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Mapnik style Problem

2011-12-22 Thread Sven Geggus
Hello,

I'm trying to render a hillshade+contour baselayer. This is loosely based on the
manual in the Wiki http://wiki.openstreetmap.org/wiki/HikingBikingMaps.

Looks like my stylefile is somewhat broken because calling nik2img.py I get
this:

...
Step: 14 // -- Extent of all layers: 
Envelope(-3.14159265359,-1.57079632679,20037508.3428,59613540.2073)
Step: 15 // -- Long/lat extent of all layers: 
Envelope(-2.8221406972e-05,-1.41107034975e-05,180.0,89.99)
...

This is certainly wrong and looks like mixed lat/long and google mercator
coordinates. The result is that my Objects from PGSQL are assumed to be
outside of the map.

...
Step: 16 // -- Long/lat center of all layers: 
Coord(89.858893,44.9949929446)
Step: 17 // -- No layers intersecting map!
...

Here is how nik2img.py is called:
nik2img.py hill_style.xml foo.png  -b -17.35010 28.07573 -17.31736 28.11230 
--no-open -v

And here is hill_style.xml:

---cut---
?xml version=1.0 encoding=utf-8?
!DOCTYPE Map
Map bgcolor=#B4B4B4 srs=+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +no_defs +over

Style name=contours10
Rule
MaxScaleDenominator5/MaxScaleDenominator
MinScaleDenominator1599/MinScaleDenominator
LineSymbolizer
CssParameter name=stroke#66/CssParameter
CssParameter name=stroke-width0.3/CssParameter
/LineSymbolizer
/Rule
/Style
Style name=contours50
Rule
MaxScaleDenominator15/MaxScaleDenominator
MinScaleDenominator1599/MinScaleDenominator
LineSymbolizer
CssParameter name=stroke#66/CssParameter
CssParameter name=stroke-width0.5/CssParameter
/LineSymbolizer
/Rule
/Style
Style name=contours100
Rule
MaxScaleDenominator409483/MaxScaleDenominator
MinScaleDenominator1599/MinScaleDenominator
LineSymbolizer
CssParameter name=stroke#55/CssParameter
CssParameter name=stroke-width0.5/CssParameter
/LineSymbolizer
/Rule
/Style
Style name=contours-text50
Rule
MaxScaleDenominator2/MaxScaleDenominator
MinScaleDenominator1599/MinScaleDenominator
TextSymbolizer name=height face_name=DejaVu Sans Book 
size=9 fill=#4F2B00 halo_radius=1 halo_fill= #ff placement=line 
max_char_angle_delta=30 /
/Rule
/Style
Style name=contours-text100
Rule
MaxScaleDenominator5/MaxScaleDenominator
MinScaleDenominator2/MinScaleDenominator
TextSymbolizer name=height face_name=DejaVu Sans Book 
size=9 fill=#4F2B00 halo_radius=1 halo_fill= #ff placement=line  
max_char_angle_delta=30 /
/Rule
Rule
MaxScaleDenominator2/MaxScaleDenominator
MinScaleDenominator1599/MinScaleDenominator
TextSymbolizer name=height face_name=DejaVu Sans Book 
size=10 fill=#381D00 halo_radius=1 halo_fill= #ff placement=line  
max_char_angle_delta=30 /
/Rule
/Style



Style name=raster
  Rule
RasterSymbolizer
  CssParameter name=opacity1.0/CssParameter
  CssParameter name=scalingbilinear/CssParameter
  !--CssParameter name=modemultiply/CssParameter--
/RasterSymbolizer
  /Rule
/Style


Layer name=srtm_10 status=on srs=+proj=latlong +datum=WGS84
StyleNamecontours10/StyleName
StyleNamecontours-text10/StyleName
Datasource
Parameter name=typepostgis/Parameter
Parameter name=host/Parameter
Parameter name=port/Parameter
Parameter name=user/Parameter
Parameter name=password/Parameter
Parameter name=dbnamegeg/Parameter
Parameter name=estimate_extentfalse/Parameter
Parameter name=table(select way,height from contours WHERE 
height::integer % 10 = 0 AND height::integer % 50 != 0 AND height::integer % 
100 != 0) as contours-10/Parameter
Parameter name=extent-180,-90,180,89.99/Parameter
/Datasource
/Layer
Layer name=srtm_50 status=on srs=+proj=latlong +datum=WGS84
StyleNamecontours50/StyleName
StyleNamecontours-text50/StyleName
Datasource
Parameter name=typepostgis/Parameter
Parameter name=host/Parameter
Parameter name=port/Parameter
Parameter name=user/Parameter
Parameter name=password/Parameter
Parameter name=dbnamegeg/Parameter
Parameter name=estimate_extentfalse/Parameter
Parameter name=table(select way,height from contours WHERE 
height::integer % 50 = 0 AND height::integer % 100 

Re: [OSM-dev] map disappear on YourS local installation

2011-12-22 Thread Anwar Azulfa
i have checkout from
http://svn.openstreetmap.org/applications/routing/yours/branches/version-1.0-via

now, map is appear. but when i try to make routing, i get error again


this is step which i did :

1. i following reference from http://wiki.openstreetmap.org/wiki/YOURS and
checkout from http://svn.openstreetmap.org/applicatio …
on-1.0-viahttp://svn.openstreetmap.org/applications/routing/yours/branches/version-1.0-via

2. i checkout gosmore source from http://svn.openstreetmap.org/applicatio …
ng/gosmore http://svn.openstreetmap.org/applications/rendering/gosmore

3.download file .pak and rename to gosmore.pak.i put this file inside
gosmore folder

4. i put YOURS/* to /var/www so i can acces it via browser with
http://localhost
now i can access map, but when i make a route from one location to another
location and click find route, error message :Status: An unexpected error
occured in Gosmore: appear

i check on /var/log/apache2/error.log and i get this error message :

*[Thu Dec 22 22:29:48 2011] [error] [client 127.0.0.1] PHP Notice:
 Undefined index: format in /home/maple/yours/api/1.0/gosmore.php on line
105, referer: http://localhost/*

*nice: ./gosmore: No such file or directory*

*
*

What should i do to solve this ?


Help me, please



2011/12/21 Anwar Azulfa an...@troyans.net

 I try install yours on my computer, i have followed reference from
 http://wiki.openstreetmap.org/wiki/YOURS

 But when i access it via browser, i can't found any map.

 then i get idea to pointing js to my map on local computer because i have
 own local tiles .

 I try to change init function on yournavigation.js with :


  function init() {
var options = {
 projection: new OpenLayers.Projection(EPSG:900913),
 displayProjection: new OpenLayers.Projection(EPSG:4326),
 units: m,
 maxResolution: 156543.0339,
 maxExtent: new OpenLayers.Bounds(-20037508.34,
 -20037508.34,
  20037508.34, 20037508.34),
 numZoomLevels: 16,
 controls: [
 new OpenLayers.Control.Navigation(),
 new OpenLayers.Control.PanZoomBar(),
 new OpenLayers.Control.Permalink(),
 new OpenLayers.Control.ScaleLine(),
 new OpenLayers.Control.MousePosition(),
 new OpenLayers.Control.KeyboardDefaults()

   ]
 };
 myFirstMap = new OpenLayers.Map(map,options);
 var newL = new OpenLayers.Layer.OSM(Default, 
 http://localhost/osm_tiles3/${z}/${x}/${y}.png;, {numZoomLevels: 19});
 map.addLayer(newL);
  if (!map.getCenter()) {
var center = new OpenLayers.LonLat(116.97,-2.56);
 center.transform(options.displayProjection,
 options.projection);
 map.setCenter(center, 5);
  }

   }


 But i stil l can't find map on it ?


 What should i do to solve this ?


 --
 Regards,
 M.Iftakhul Anwar





-- 
Regards,
M.Iftakhul Anwar
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


[OSM-dev] New version of API

2011-12-22 Thread Kozuch
Hi there,

what about new version of API (0.7)? Since 2009 demands on OSM changed 
drastically so new API is really needed... I can not really find any activity 
in this arey is going on...

We definitely need a kind of API-Lite for rendering of heavy relations at least 
(see 
http://help.openstreetmap.org/questions/9024/large-relations-slow-to-show-caching-a-solution).

Cheers,
Jan

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Full history extracts

2011-12-22 Thread Simon Poole
I've regenerated all statistics on odbl.poole.ch from the most recent 
full history dump (2011-12-08) and have uploaded most of the extracts to 
http://odbl.poole.ch/extracts/ . I have more (continents, German states 
etc) that I can upload on request (uploading from home is simply -very- 
slow, that is why I just don't dump everything on the server)


The extracts were cut with the softcut algorithm and are in XML format.

Simon


___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] New version of API

2011-12-22 Thread Roland Olbricht
 Hi there,
 
 what about new version of API (0.7)? Since 2009 demands on OSM changed
  drastically so new API is really needed... I can not really find any
  activity in this arey is going on...

http://wiki.openstreetmap.org/wiki/API_v0.7

There is a lot of stuff. But I frankly say that it would be insane to do any 
API change before the license change, because all OSM tool writers are more or 
less busy at the moment with the license change.

Cheers,

Roland

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Merkaator port to Android

2011-12-22 Thread Samat K Jain
On Friday, December 02, 2011 12:56:02 PM Jaak Laineste wrote:
 Hi,
  as you may now, during GSoC QGIS was ported to Android tablets
 (http://hub.qgis.org/projects/quantum-gis/wiki/QGIS_Mobile_GSoC_2011).
 Merkaator has technically same base elements: Qt, GEOS, PROJ.4 etc, so
 based on this experience porting of Merkaator could be also possible
 with much smaller fuss. It should be even smaller work than getting
 JOSM working under Android.
 
  Question: do you know anyone who really would need and use it?

FYI, there is a Mobile Merkaartor in it's source repo:

  https://gitorious.org/merkaartor/main/trees/master/mobilemerk

No idea on it's status, though. I remember seeing something about a Merkaartor 
port to Lighthouse (Qt for Android) but can't find it now.

-- 
Samat K Jain http://samat.org/ ▪ GPG: 0x4A456FBA

I don't know with what weapons World War III will be fought, but World War IV 
will be fought with sticks and stones.
— Albert Einstein (267)

This e-mail is: [ ] bloggable [x] ask first [ ] private


___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev


Re: [josm-dev] Stabilization ends

2011-12-22 Thread Matthias Julius
Jo winfi...@gmail.com writes:

 2011/12/21 Dirk Stöcker openstreet...@dstoecker.de

 Hello,


  I can attach my config as a file to the ticket if you like, but in


 If that repoduces the error, do so.

 I'll have to try it first then.

And delete any passwords that might be in there.

Matthias

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev