[OSM-talk] osmlib osm-export shp column name size limit?
Playing with Jochen's Ruby osmlib for the past couple of hours; trying to convert osm to shapefiles. I find that the column names I configure in the "setup" section are truncated to ten characters. Has anyone else run into this? This is osmlib 0.1.3. Thanks. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wanted: Osm2pgsql.exe developer
On Sat, 2008-11-15 at 14:25 +0200, Rahkonen Jukka wrote: > Jon Burgess wrote: > > On Sat, 2008-11-15 at 13:06 +0200, Rahkonen Jukka wrote: > > > In short, I don't think we can give any guarantees about the uniqueness > > of the osm_id column. > > Good to know. I am playing with Finnish and Scandinavian data only and I set > keep PostGIS using WITH_OIDS as default and thus I get primary keys > automatically. Not really a problem for me, but those who are playing with > more data and perhaps have a remote database without db-admin rights need to > create the primary key field themselves. Primary key is compulsory for many > uses. But knowing the situation helps. > > >> - There are some features that are not imported at all by the new > >> version. At least areas with tag shop=supermarket and no other tags > >> except name (way 4881398). It does not appear on Mapnik map either, so > >> the program works for me in the similar way than in Mapnik slippy map > >> production. > > > I don't think the 'shop' tag has ever been included in the list of > > imported tags. It is definitely not being rendered by the current > > osm.xml file. > > Right, did not remember that shop wan one of those extra tags that was added > to osm2pgsql.exe. It is possible to read map features page so that giving > shop=supermarket as an area is supported, but not all shop=something. > Osmarender seems to render it. For on-demand rendering it would be more > simple to keep all shops as points and perhaps colour the building according > to building=shop or building=commercial or the like. But I have understood > that now I can just edit the default.style file for having some own tags, for > example max_speed if I'd like to colour highways according to that. Mapnik does not render everything listed in Map_Features but building=* will render. The default.style will let you customise this quite easily which is a nice new feature for the Windows version. Good luck with max_speed. I believe there are lots of variations in the way the data has been entered which will probably cause issues. > >> - Combination highway=[any type], area=yes comes now correctly as > >> polygon, while they used to be lines. > >> - Major part of differencies in number of line features are due to > >> riverbanks and highways marked with area=yes tag. They get now > >> correctly converted into polygons and can be found there. > > > This is one of several new features introduced since the last time the > > Windows version was built. Another big feature is the support for diff > > imports. > > >> For me it looks like it is safe to use the new osm2pgsql.exe, but only > >> in slim mode. > > > Thanks for doing the testing. > > Thanks for compiling. By the way, the final report is missing now, that used > to look like this > > > Node stats: total(2658737), max(312060206) > Way stats: total(175231), max(28408381) > Relation stats: total(836), max(51578) > > I see these in the output when I run the program as below: $ ./osm2pgsql.exe -W --slim -U foo -d foo cyprus.osm.bz2 osm2pgsql SVN version 0.55-20081113 $Rev: 10464 $ Password:foo Using projection SRS 900913 (Spherical Mercator) Setting up table: planet_osm_point Setting up table: planet_osm_line Setting up table: planet_osm_polygon Setting up table: planet_osm_roads Mid: pgsql, scale=100, cache=800MB, maxblocks=102401*zd Setting up table: planet_osm_nodes *** WARNING: intarray contrib module not installed *** The resulting database will not be usable for applying diffs. NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_nodes_pkey" for table "planet_osm_nodes" Setting up table: planet_osm_ways NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_ways_pkey" for table "planet_osm_ways" Setting up table: planet_osm_rels NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_rels_pkey" for table "planet_osm_rels" Reading in file: cyprus.osm.bz2 Processing: Node(213k) Way(20k) Relation(0k) Node stats: total(213472), max(312053827) Way stats: total(20617), max(28408030) Relation stats: total(3), max(48708) Going over pending ways processing way (1k) Going over pending relations node cache: stored: 213472(100.00%), storage efficiency: 2.78%, hit rate: 100.00% Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live API 0.6 servers (was Why is JOSM upload so slow?)
On 15 Nov 2008, at 17:43, Claudius Henrichs wrote: > Frederik Ramm: >> Hi, >> >> Martijn van Oosterhout wrote: >>> The 0.6 API wil have a bulk upload stream which can significantly >>> reduce the overhead. >> >> BTW, current JOSM versions already exclusively use bulk uploading for >> changes if the server speaks 0.6. There are a few conflict >> resolution/ >> error detection issues but I'm sure they'll be ironed out when 0.6 >> goes >> live. > > I read the instructions on the API 0.6 page on how to activate it, but > one questions remains: > Is there any API 0.6 Server yet that i can use to write into the live > OSM DB? I could only find some test server with limited data which are > not connected to the live system. > No. As there is a significant database difference between the 0.5 and 0.6 APIs, a full database structure migration is required, that will take a few days to run. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live API 0.6 servers (was Why is JOSM upload so slow?)
Frederik Ramm: > Hi, > > Martijn van Oosterhout wrote: >> The 0.6 API wil have a bulk upload stream which can significantly >> reduce the overhead. > > BTW, current JOSM versions already exclusively use bulk uploading for > changes if the server speaks 0.6. There are a few conflict resolution/ > error detection issues but I'm sure they'll be ironed out when 0.6 goes > live. I read the instructions on the API 0.6 page on how to activate it, but one questions remains: Is there any API 0.6 Server yet that i can use to write into the live OSM DB? I could only find some test server with limited data which are not connected to the live system. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
Hi, Martijn van Oosterhout wrote: > The 0.6 API wil have a bulk upload stream which can significantly > reduce the overhead. BTW, current JOSM versions already exclusively use bulk uploading for changes if the server speaks 0.6. There are a few conflict resolution/ error detection issues but I'm sure they'll be ironed out when 0.6 goes live. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contour lines from SRTM-Data in OSM format
On Sat, Nov 15, 2008 at 10:10 AM, Igor Brejc <[EMAIL PROTECTED]> wrote: > Well, first of all, CycleMap uses the same SRTM data (as far as I know), > so if the license is an issue, this applies to CycleMap too. > I haven't been able to find any info directly describing the license of > SRTM, but, as far as I know, all NASA's products (images, data) are > "public domain". And since people who generated SRTM void-filled data > license it under their own terms (and not NASA's), I guess this means > that the original data has a very permissive license. So we should be in > the clear ;) the license for CGIAR's void-filled dataset is here: http://srtm.csi.cgiar.org/SELECTION/SRT_disclaimer.htm it looks like using the dataset for deriving contours for non-commercial use is OK as long as the contours (and tiles based on them) are attributed to CGIAR. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
On Sat, Nov 15, 2008 at 9:34 AM, Keith Ng <[EMAIL PROTECTED]> wrote: > I see. Thanks for the information. > > When will the 0.6 API be ready and in use then? we're aiming for christmas. if anyone wants to help out with the server or client code, see the (mostly up-to-date) list of things on the wiki page http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6 cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM not acceptable for geocaching.com
2008/11/15 Till Harbaum / Lists <[EMAIL PROTECTED]>: > Hi, > > i have recently released a geocache which basically required you to look up a > certain node > in the OSM database. The position of that node was then the place where the > geocache was > hidden. Geocaching.com users can perhaps still read the original listing at: > http://www.geocaching.com/seek/cache_details.aspx?guid=80a9308b-6719-485d-a0dc-846798a8cac2 Through a bug in their site code, the original listing is visible here: http://www.geocaching.com/seek/cdpf.aspx?guid=80a9308b-6719-485d-a0dc-846798a8cac2 > Geocaching.com recently completely deleted that cache antry as they claim > that it forces you to use a certain > software (a web browser!!!) and a certain web service. They have un-published the listing, an event that occurs not very often - usually only if the reviewer who published it realises they made a mistake soon after. The specific guideline reads something like caches that require (unusual) third party software to be installed are not permitted, there's also a similar rule about cache perminance in terms of external resources on the net - eg hosting an mp3 on a personal website will not be acceptable as a part of the 'puzzle' as they have a habit of falling offline. > This is a strange explanation as geocaches requesting you to find a certain > image on google earth > are pretty common. On the other hand Geocaching.com seems to have a business > with google. This > may be the explanation why they don't like to deal with openstreetmap. I > really wonder if > it's google behind this. They have business with Google as far as using their Maps API, publishing KML files, and using AdWords, I don't think they have any further links with them. > This includes quite extreme behaviour on the GC.com side as they are not > using their usual methods > of disabling or archiving caches. Instead they reset their entire database > with respect to this > cache to the state before it was published. It's like they really want to > clean all traces related to > this geocache. "The GC.com" side is usually just a volunteer reviewer rather than one of the company's employees. As noted, caches can be removed completely from the site - 'unpublished' on the event of the reviewer making a mistake. > IMHO a very interesting issue and may mean that google sees a serious > competitor arriving ... Not in my view. > Till I'm asking some contacts I have to see if I can get the full logs for publishing and subsequent removal of it to see if a reason is further given. -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM not acceptable for geocaching.com
On Sat, Nov 15, 2008 at 12:42:17PM +0100, Till Harbaum / Lists wrote: Geocaching.com recently completely deleted that cache antry as they claim that it forces you to use a certain software (a web browser!!!) and a certain web service. If your geocache is inside a german-speaking country (*), you could use opencaching.de instead - they also have much better license terms / terms of use and even support bulk downloading of search results in a variety of formats. Great for spontaneous geocaching without internet access (just download a list a geocaches in your region from time to time and store it on your laptop/PDA/handheld GPS). In case you want to pay (like geocaching.com Premium membership), you can just donate to them (e.V. => tax deductible). :) (*) You are able to add geocaches in other countries, too, but the interface is in german only. :( CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wanted: Osm2pgsql.exe developer
Jon Burgess wrote: On Sat, 2008-11-15 at 13:06 +0200, Rahkonen Jukka wrote: > In short, I don't think we can give any guarantees about the uniqueness > of the osm_id column. Good to know. I am playing with Finnish and Scandinavian data only and I set keep PostGIS using WITH_OIDS as default and thus I get primary keys automatically. Not really a problem for me, but those who are playing with more data and perhaps have a remote database without db-admin rights need to create the primary key field themselves. Primary key is compulsory for many uses. But knowing the situation helps. >> - There are some features that are not imported at all by the new >> version. At least areas with tag shop=supermarket and no other tags >> except name (way 4881398). It does not appear on Mapnik map either, so >> the program works for me in the similar way than in Mapnik slippy map >> production. > I don't think the 'shop' tag has ever been included in the list of > imported tags. It is definitely not being rendered by the current > osm.xml file. Right, did not remember that shop wan one of those extra tags that was added to osm2pgsql.exe. It is possible to read map features page so that giving shop=supermarket as an area is supported, but not all shop=something. Osmarender seems to render it. For on-demand rendering it would be more simple to keep all shops as points and perhaps colour the building according to building=shop or building=commercial or the like. But I have understood that now I can just edit the default.style file for having some own tags, for example max_speed if I'd like to colour highways according to that. >> - Combination highway=[any type], area=yes comes now correctly as >> polygon, while they used to be lines. >> - Major part of differencies in number of line features are due to >> riverbanks and highways marked with area=yes tag. They get now >> correctly converted into polygons and can be found there. > This is one of several new features introduced since the last time the > Windows version was built. Another big feature is the support for diff > imports. >> For me it looks like it is safe to use the new osm2pgsql.exe, but only >> in slim mode. > Thanks for doing the testing. Thanks for compiling. By the way, the final report is missing now, that used to look like this Node stats: total(2658737), max(312060206) Way stats: total(175231), max(28408381) Relation stats: total(836), max(51578) -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FW: [OpenStreetMap] #1327: Rendering non-existent data
On Thu, 2008-11-13 at 10:40 +, Dave Stubbs wrote:
> On Thu, Nov 13, 2008 at 10:02 AM, Steve Chilton <[EMAIL PROTECTED]> wrote:
> > Trac #1327 below assigned to me but I can't resolve it.
> > It is a minor nuisance of something rendering at origin:
> > http://www.openstreetmap.org/?lat=0.59&lon=-0.16&zoom=18
> > Shows as station on mapnik, car park on cycle, station on nonames, nothing
> > on osma
> > Editors show nothing there. Data layer says it is the API.
> > Any thoughts.
> > Just ignore it?
> >
>
> It's because the data isn't actually /there/ -- it's somewhere else.
> When things go wrong it's not unusual for the projection code etc to
> end up sticking stuff at 0,0. The API doesn't return it though.
>
> For example, the station is node 32009797, located at -90 latitude...
> the south pole.
> There's also a BP petrol station at the north pole, a helpful
> place=continent for Antartica, a helpful place for the North Pole, and
> a number of parking nodes inserted by osm2pgsql from parking areas
> that it obviously doesn't like.
>
> So it's partially some bad data, and partially some odd behaviour on
> the part of osm2pgsql/postgis/mapnik.
> I'll have a go at correcting some of the data.
As Dave says, they are artefacts of the osm2pgsql conversion process.
I will add some code to discard these when I find some time.
gis=> select osm_id,amenity,name,astext(way) from planet_osm_point where
way && setSRID('BOX3D(-10 -10, 10 10)'::box3d,900913);
osm_id | amenity | name| astext
---+-+---+---
36966060 | | Antarctica| POINT(0 -1.5707963267949)
32009797 | | Peñagrande| POINT(0 -1.5707963267949)
26535074 | parking | Place de l'Eglise | POINT(0 0)
26414180 | parking | Schüren | POINT(0 0)
23025831 | parking | | POINT(0 0)
27962310 | parking | | POINT(0 0)
24805472 | parking | | POINT(0 0)
25209770 | fuel| Station Bp| POINT(0 1.5707963267949)
269538499 | | North Pole| POINT(0 1.5707963267949)
gis=> select osm_id,highway,ref,astext(way) from planet_osm_line where
way && setSRID('BOX3D(-10 -10, 10 10)'::box3d,900913);
osm_id | highway| ref | astext
--+--++---
22529607 | unclassified | TF-463 | LINESTRING(0 1.5707963268,0 1.57)
(1 row)
Jon
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wanted: Osm2pgsql.exe developer
On Sat, 2008-11-15 at 13:06 +0200, Rahkonen Jukka wrote: > Jon Burgess wrote: > > On Fri, 2008-11-14 at 21:08 +0200, Rahkonen Jukka wrote: > >> I'd say that the new one has problems at least with multipolygon > >> relations. For example a multipolygon, relation with OSM_ID 4230, is > >> imported as separate polygons, outer ring having OSM_ID 12298022. > >> That's probably why the number of polygons is bigger, there are lots > >> of lakes with holes in the data. I have not yet isolated any line or > >> point differencies, I am just learning how to query them visible from > >> PostGIS. I am sorry I can't give lat/lon coordinates now, I have > >> reprojected the data into Finnish KKJ system in the database. I will > >> reproject it to epsg:4326 before next investigations. > > > Did you import the data with --slim? There is a bug in the current code > > which which breaks multipolygons unless the slim mode is used. > > > I see relation 4230 appearing as a polygon with lots of holes: > > > foo=> select osm_id,name,"natural",NumInteriorRings(way) from > > planet_osm_polygon where osm_id in (-4230,12298022); > > osm_id | name| natural | numinteriorrings > > +---+-+-- > > -4230 | Konnivesi | water | 67 > > (1 row) > > > No, I did not use the --slim switch. As advertised, it is much slower > to import with slim mode, but it does import polygons with holes > correctly. Differencies in feature count was now 97223-96970 for lines > and 48305-48581 for polygons. > > I created difference layers from tables imported with the old > osm2pgsql.exe and this new one in slim mode. Query may be stupid, but > I think that it selects reliably objects imported with the old one > (named OSM_) which do not have a pair with same OSM_ID in the other > table (named GOSM_) SQL is like this > create table diff2 as (select * from (select osm.*, gosm.osm_id as > goo, gosm.name as gname from osm_polygon osm LEFT JOIN gosm_polygon > gosm using(osm_id)) as foo where foo.goo is null); > > Some findings: > - Old program gave positive OSM_IDs for features created from > relations while the new seems to give them negative values. Obviously > the code has been changed in between. I guess and hope that this > change makes OSM_ID as unique identifier so it can be used as a > primary key in the imported PostGIS tables. Until now I have been > forced to create a new OID field for primary key. When we create nodes for parking areas the way ID is used to identify the new node which could cause a clash. We could make this a negative ID which would help. I think there is an edge case in the multipolygon support which can cause multiple linear ways to be created with the same relation ID if the rings are not closed. In short, I don't think we can give any guarantees about the uniqueness of the osm_id column. > - There are some features that are not imported at all by the new > version. At least areas with tag shop=supermarket and no other tags > except name (way 4881398). It does not appear on Mapnik map either, so > the program works for me in the similar way than in Mapnik slippy map > production. I don't think the 'shop' tag has ever been included in the list of imported tags. It is definitely not being rendered by the current osm.xml file. > - Combination highway=[any type], area=yes comes now correctly as > polygon, while they used to be lines. > - Major part of differencies in number of line features are due to > riverbanks and highways marked with area=yes tag. They get now > correctly converted into polygons and can be found there. This is one of several new features introduced since the last time the Windows version was built. Another big feature is the support for diff imports. > For me it looks like it is safe to use the new osm2pgsql.exe, but only > in slim mode. Thanks for doing the testing. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM not acceptable for geocaching.com
Hi, i have recently released a geocache which basically required you to look up a certain node in the OSM database. The position of that node was then the place where the geocache was hidden. Geocaching.com users can perhaps still read the original listing at: http://www.geocaching.com/seek/cache_details.aspx?guid=80a9308b-6719-485d-a0dc-846798a8cac2 Geocaching.com recently completely deleted that cache antry as they claim that it forces you to use a certain software (a web browser!!!) and a certain web service. This is a strange explanation as geocaches requesting you to find a certain image on google earth are pretty common. On the other hand Geocaching.com seems to have a business with google. This may be the explanation why they don't like to deal with openstreetmap. I really wonder if it's google behind this. This includes quite extreme behaviour on the GC.com side as they are not using their usual methods of disabling or archiving caches. Instead they reset their entire database with respect to this cache to the state before it was published. It's like they really want to clean all traces related to this geocache. IMHO a very interesting issue and may mean that google sees a serious competitor arriving ... Till ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wanted: Osm2pgsql.exe developer
On Sat, Nov 15, 2008 at 12:06 PM, Rahkonen Jukka <[EMAIL PROTECTED]> wrote: > Some findings: > - Old program gave positive OSM_IDs for features created from relations while > the new seems to give them negative values. Obviously the code has been > changed in between. I guess and hope that this change makes OSM_ID as unique > identifier so it can be used as a primary key in the imported PostGIS tables. > Until now I have been forced to create a new OID field for primary key. Nope, because some OSM features translate to more than one postgis feature and so they get the same OSM id. > - There are some features that are not imported at all by the new version. At > least areas with tag shop=supermarket and no other tags except name (way > 4881398). It does not appear on Mapnik map either, so the program works for > me in the similar way than in Mapnik slippy map production. Is the shop tag mentioned in the style config? > For me it looks like it is safe to use the new osm2pgsql.exe, but only in > slim mode. Non-slim mode is basically fine as long as you don't need anything with relations, otherwise... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wanted: Osm2pgsql.exe developer
Jon Burgess wrote: On Fri, 2008-11-14 at 21:08 +0200, Rahkonen Jukka wrote: >> 2008/11/14 Rahkonen Jukka <[EMAIL PROTECTED]>: >> >> This version imports Finland.osm dataset OK. There are slight >> >> differencies in the number of features imported by this and Artem's >> >> version: >> >> >> >> Old >> >> points: 24578 >> >> lines: 97223 >> >> polygons: 48305 >>> >> >> >> New >> >> points: 23680 >> >> lines: 96889 >> >> polygons: 50316 >> >> >> >> I will do cross check later by selecting features imported by the old but >> >> not with the new and vice versa. >> >> >> >> -Jukka- >> >> > I'd guess that its just a change in the osm2pgsql style definition, >> > which determines which features are interesting, and whether those >> > features should be treated as polygons or as linestrings. >> >> I'd say that the new one has problems at least with multipolygon >> relations. For example a multipolygon, relation with OSM_ID 4230, is >> imported as separate polygons, outer ring having OSM_ID 12298022. >> That's probably why the number of polygons is bigger, there are lots >> of lakes with holes in the data. I have not yet isolated any line or >> point differencies, I am just learning how to query them visible from >> PostGIS. I am sorry I can't give lat/lon coordinates now, I have >> reprojected the data into Finnish KKJ system in the database. I will >> reproject it to epsg:4326 before next investigations. > Did you import the data with --slim? There is a bug in the current code > which which breaks multipolygons unless the slim mode is used. > I see relation 4230 appearing as a polygon with lots of holes: > foo=> select osm_id,name,"natural",NumInteriorRings(way) from > planet_osm_polygon where osm_id in (-4230,12298022); > osm_id | name| natural | numinteriorrings > +---+-+-- > -4230 | Konnivesi | water | 67 > (1 row) No, I did not use the --slim switch. As advertised, it is much slower to import with slim mode, but it does import polygons with holes correctly. Differencies in feature count was now 97223-96970 for lines and 48305-48581 for polygons. I created difference layers from tables imported with the old osm2pgsql.exe and this new one in slim mode. Query may be stupid, but I think that it selects reliably objects imported with the old one (named OSM_) which do not have a pair with same OSM_ID in the other table (named GOSM_) SQL is like this create table diff2 as (select * from (select osm.*, gosm.osm_id as goo, gosm.name as gname from osm_polygon osm LEFT JOIN gosm_polygon gosm using(osm_id)) as foo where foo.goo is null); Some findings: - Old program gave positive OSM_IDs for features created from relations while the new seems to give them negative values. Obviously the code has been changed in between. I guess and hope that this change makes OSM_ID as unique identifier so it can be used as a primary key in the imported PostGIS tables. Until now I have been forced to create a new OID field for primary key. - There are some features that are not imported at all by the new version. At least areas with tag shop=supermarket and no other tags except name (way 4881398). It does not appear on Mapnik map either, so the program works for me in the similar way than in Mapnik slippy map production. - Combination highway=[any type], area=yes comes now correctly as polygon, while they used to be lines. - Major part of differencies in number of line features are due to riverbanks and highways marked with area=yes tag. They get now correctly converted into polygons and can be found there. For me it looks like it is safe to use the new osm2pgsql.exe, but only in slim mode. -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contour lines from SRTM-Data in OSM format
Christoph Eckert wrote: > Hi, > > >>> I believe srtm2osm uses void filled data that is copyrighted. So is >>> you do distribute the results make sure that you specify it's only for >>> academic research. IANAL. >>> >> No, it uses original SRTM data downloaded directly from NASA's FTP server. >> > > I've been on the SRTM pages a couple of minutes before, and am still unsure > about the license stuff. Before I distribute the data, I'd really like to > know if it is legal. Any hint would be much appreciated. > > Best regards, > > ce > > > Well, first of all, CycleMap uses the same SRTM data (as far as I know), so if the license is an issue, this applies to CycleMap too. I haven't been able to find any info directly describing the license of SRTM, but, as far as I know, all NASA's products (images, data) are "public domain". And since people who generated SRTM void-filled data license it under their own terms (and not NASA's), I guess this means that the original data has a very permissive license. So we should be in the clear ;) Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
On Samstag 15 November 2008, Martijn van Oosterhout wrote: > On Sat, Nov 15, 2008 at 9:49 AM, Keith Ng <[EMAIL PROTECTED]> wrote: > > I am currently uploading fixed coastline from JOSM and I notice that the > > upload is excruciatingly slow. The maximum speech achievable is around > > 1.5KB/s and the average speed is around 800 byles/s. > > > > I am uploading data from Melbourne, Australia. There's nothing wrong with > > my Internet. My maximum upload bandwidth is 256KB/s. Yet, JOSM notifies > > me that my current upload will take around 95 minutes. > > The problem is not speed, it's latency. I'm not sure what your ping > time is to the server (I'm guessing near 350ms), but remember that any > single update done by JOSM will take at least a whole HTTP request to > do which is at least 4*RTT so maybe 1.5 seconds. Multiply by number of > objects... > > The 0.6 API wil have a bulk upload stream which can significantly > reduce the overhead. Another possibility is do a Save in JOSM and you > bulk_upload from a machine closer to the server. Somtimes working over a local squid helps improving Speed. This way squid might use one http/1.1 request to tunnel all http/1.0 requests over one tcp connection. -- Jörg (Germany, Tettnang) http://www.ostertag.name/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contour lines from SRTM-Data in OSM format
Hi, > > I believe srtm2osm uses void filled data that is copyrighted. So is > > you do distribute the results make sure that you specify it's only for > > academic research. IANAL. > > No, it uses original SRTM data downloaded directly from NASA's FTP server. I've been on the SRTM pages a couple of minutes before, and am still unsure about the license stuff. Before I distribute the data, I'd really like to know if it is legal. Any hint would be much appreciated. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contour lines from SRTM-Data in OSM format
Nic Roets wrote: > I believe srtm2osm uses void filled data that is copyrighted. So is > you do distribute the results make sure that you specify it's only for > academic research. IANAL. > No, it uses original SRTM data downloaded directly from NASA's FTP server. Regards, Igor -- http://igorbrejc.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
I see. Thanks for the information. When will the 0.6 API be ready and in use then? Regards, Keith On Sat, Nov 15, 2008 at 8:31 PM, Martijn van Oosterhout <[EMAIL PROTECTED]>wrote: > On Sat, Nov 15, 2008 at 9:49 AM, Keith Ng <[EMAIL PROTECTED]> wrote: > > I am currently uploading fixed coastline from JOSM and I notice that the > > upload is excruciatingly slow. The maximum speech achievable is around > > 1.5KB/s and the average speed is around 800 byles/s. > > > > I am uploading data from Melbourne, Australia. There's nothing wrong with > my > > Internet. My maximum upload bandwidth is 256KB/s. Yet, JOSM notifies me > that > > my current upload will take around 95 minutes. > > The problem is not speed, it's latency. I'm not sure what your ping > time is to the server (I'm guessing near 350ms), but remember that any > single update done by JOSM will take at least a whole HTTP request to > do which is at least 4*RTT so maybe 1.5 seconds. Multiply by number of > objects... > > The 0.6 API wil have a bulk upload stream which can significantly > reduce the overhead. Another possibility is do a Save in JOSM and you > bulk_upload from a machine closer to the server. > > Have a nice day, > -- > Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
On Sat, Nov 15, 2008 at 9:49 AM, Keith Ng <[EMAIL PROTECTED]> wrote: > I am currently uploading fixed coastline from JOSM and I notice that the > upload is excruciatingly slow. The maximum speech achievable is around > 1.5KB/s and the average speed is around 800 byles/s. > > I am uploading data from Melbourne, Australia. There's nothing wrong with my > Internet. My maximum upload bandwidth is 256KB/s. Yet, JOSM notifies me that > my current upload will take around 95 minutes. The problem is not speed, it's latency. I'm not sure what your ping time is to the server (I'm guessing near 350ms), but remember that any single update done by JOSM will take at least a whole HTTP request to do which is at least 4*RTT so maybe 1.5 seconds. Multiply by number of objects... The 0.6 API wil have a bulk upload stream which can significantly reduce the overhead. Another possibility is do a Save in JOSM and you bulk_upload from a machine closer to the server. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why is JOSM upload so slow?
On Saturday 15 November 2008 02:19:12 pm Keith Ng wrote: > So, why is uploading so slow? probably too many people uploading - it is one single server afaik. Try uploading when it is 2 am in Germany ;-) -- regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Why is JOSM upload so slow?
I am currently uploading fixed coastline from JOSM and I notice that the upload is excruciatingly slow. The maximum speech achievable is around 1.5KB/s and the average speed is around 800 byles/s. I am uploading data from Melbourne, Australia. There's nothing wrong with my Internet. My maximum upload bandwidth is 256KB/s. Yet, JOSM notifies me that my current upload will take around 95 minutes. So, why is uploading so slow? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contour lines from SRTM-Data in OSM format
I believe srtm2osm uses void filled data that is copyrighted. So is you do distribute the results make sure that you specify it's only for academic research. IANAL. I used srtm2osm to make an OSM file of over 1 GB and played around with it in gosmore. Distributing gosmore files that include srtm contours will be pretty cool especially for hiking. But making a setup that uses the PD data and does not exceed the 420MB limit on WinCE will take some effort. Regards, Nic On Sat, Nov 15, 2008 at 2:00 AM, Christoph Eckert <[EMAIL PROTECTED]> wrote: > Hi, > > I have used srtm2osm (all credits to Igor Brejc) to convert srtm data into > OSM > contour lines. All tiles are zippes in zip format and the complete world > consumes 61G of disk space. See some example at [1]. > > I have some questions so far: > > * I have no clue if there's some interest in the data, but if so, what > would > be the best method to distribute it? I thought about Bittorrent, but I have > no clue if it is sufficient if there only are a couple of downloaders. > > * OSM2Navit just crashes when I try to convert the tiles for Navit. So if > someone knows a little bit more about C than me... ;-) > > * One further usage of the data was to convert it as Garmin tiles, using a > transparent background. This way, the data could be used in conjunction > with > openstreetmap, well, maps :) . I do not use such maps on Garmin, but if > someone fiddles out how to do it best, we surely can run a script again. > > * If someone needs an individual tile, "do not hesitate to drop me a > line" :) . > > Cheers, > > ce > > [1] http://www.christeck.de/wp/?p=114 > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
