Re: [OSM-talk] osm2pgsql 1.2.0

Hi, On Tue, Nov 05, 2019 at 12:16:30AM +0100, wambac...@posteo.de wrote: > i'm using osm2pgsql-0.96 right now. Is it possible (and meaningful) to > switch to osm2pgsql-1.2.0? > > Must i change anything in my database? Runing diff updates using a flatfile. You can switch from 0.96 to 1.2 any

[OSM-talk] osm2pgsql 1.2.0

Hi, i'm using osm2pgsql-0.96 right now. Is it possible (and meaningful) to switch to osm2pgsql-1.2.0? Must i change anything in my database? Runing diff updates using a flatfile. Regards walter -- My projects: Admin Boundaries of the World

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

be a few out-of-Europe visitors at that time; but as my site is quite niche with limited visitors, I consider this acceptable downtime. Nick From: Paul Norman Sent: 13 November 2018 10:12:58 To: talk@openstreetmap.org Subject: Re: [OSM-talk] osm2pgsql diff a

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

On 2018-11-11 7:53 AM, Nick Whitelegg wrote: After thinking about this, I realised that I don't really want to update _all_ the data that often. The only thing I need to update on a weekly basis is the footpaths (I'm not so bothered if say the roads, or the pubs are a year out of date - as

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

@openstreetmap.org Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data On 2018-11-08 6:34 AM, Nick Whitelegg wrote: At the moment I download full planet extracts about every 6 months. However, due to the limitations of my server, I filter out (with osmosis) a lot of stuff I

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

... append mode! From: Nick Whitelegg Sent: 11 November 2018 15:53:18 To: talk@openstreetmap.org Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data Thanks for all the replies. After thinking about this, I realised that I don't really

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

On 2018-11-08 6:34 AM, Nick Whitelegg wrote: At the moment I download full planet extracts about every 6 months. However, due to the limitations of my server, I filter out (with osmosis) a lot of stuff I don't need so that I am basically left with roads, footpaths, natural features, water

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

On 08/11/2018 16:16, Darafei "Komяpa" Praliaskouski wrote: Usually people also clip minutely osc, as per day database grows by a small country otherwise. There's a worked example of that (in a slightly different context) at

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

8 16:16:48 To: Nick Whitelegg Cc: osm-talk Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data Hi Nick, osm2pgsql is tolerant to features absent in database. You can in theory even start with empty set of tables and just insert new diff data. Usually people also clip mi

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

Hi, On 08.11.2018 15:34, Nick Whitelegg wrote: > My question is this; given that not everything in the diff will be in my > database (as I filter out what I don't need during the import process), > will osm2pgsql apply the diff successfully or will it complain that not > all features in the diff

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

Hi Nick, osm2pgsql is tolerant to features absent in database. You can in theory even start with empty set of tables and just insert new diff data. Usually people also clip minutely osc, as per day database grows by a small country otherwise. чт, 8 нояб. 2018 г. в 17:37, Nick Whitelegg : > >

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

... sorry, when I say "full planet extracts" I mean only England, Wales, Scotland, Ireland (all) and Greece - not the entire planet. Thanks, Nick From: Nick Whitelegg Sent: 08 November 2018 14:34:17 To: osm-talk Subject: osm2pgsql diff application with

[OSM-talk] osm2pgsql diff application with filtered OSM data

Hi, Looking towards overhauling the import system I use for my Freemap site (free-map.org.uk) which is itself going to go through an overhaul in the near future by moving to Tangram and hopefully applying hill shading. At the moment I download full planet extracts about every 6 months.

Re: [OSM-talk] osm2pgsql 0.90.0 release

Thank you for the update Paul, I am excited to try the improved MSVC compiler support soon. (I am currently upgrading to Visual Studio 2015, from an old 2008) -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 2016-03-02 10:27 AM, Paul

[OSM-talk] osm2pgsql 0.90.0 release

Osm2pgsql 0.90.0 has been released. The major changes since 0.88.0 are - Windows support is much improved, and osm2pgsql builds natively with MSVC - Osm2pgsql now requires a C++11 compiler - Memory overhead for very small extracts is significantly reduced - Multi-threading support is enabled

[OSM-talk] osm2pgsql and JOSM osm files

Hi. I've been trying to export osm file created by JOSM to my pgsql databse but I'm having a problem with multipolygons. Everything seems to be fine in windows build, but in linux version relations are parsed (as I see in slim mode relations are added) but they are not added to planet_osm_polygon

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013/9/23 Kai Krueger kakrue...@gmail.com wrote: Indirectly it is a question of tagging schemas. To me this is actually indirectly a question of a proper area type! See e.g. Towards an Area Datatype for OSM from Jochen at SOTM http://lanyrd.com/2013/sotm/scpkrr/ --Stefan 2013/9/23 Kai Krueger

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 24.09.2013 10:12, schrieb Stefan Keller: 2013/9/23 Kai Krueger kakrue...@gmail.com wrote: Indirectly it is a question of tagging schemas. To me this is actually indirectly a question of a proper area type! See e.g. Towards an Area Datatype for OSM from Jochen at SOTM

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 23.09.2013 18:48, schrieb Yves: Sorry, I meant osm2pgsql is not used for the slippy map ONLY. Thanks for all the feedback :) Sure, but changing the DEFAULT behaviour to a more strict one while keeping the old behaviour with a flag should enable anybody to keep the old behaviour on demand; and

Re: [OSM-talk] osm2pgsql multipolygon parsing

On Sun, Sep 22, 2013 at 12:29 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: The suggestion is to discourage this in all cases and encourage always tagging the relation (this is also straightforward and much easier as you can do A or B). +1 -1 Check cities with tens of thousands

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013/9/23 Pieren pier...@gmail.com -1 Check cities with tens of thousands buildings. You will have sometime the building tag on ways, sometimes on relations. Having the tag always on the surrounding way is more consistent and easier to catch for everybody, including newcomers. Not if they

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 23/set/2013 um 11:03 schrieb Pieren pier...@gmail.com: Check cities with tens of thousands buildings. You will have sometime the building tag on ways, sometimes on relations. Having the tag always on the surrounding way is more consistent and easier to catch for everybody, including

Re: [OSM-talk] osm2pgsql multipolygon parsing

From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing it has a different meaning. tags on a closed way are for the whole area inside the way, tags on a mp relation are for the area of the outer minus the inner ways. Unless

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 23.09.2013 11:59, schrieb Paul Norman: From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing it has a different meaning. tags on a closed way are for the whole area inside the way, tags on a mp relation are for the area

Re: [OSM-talk] osm2pgsql multipolygon parsing

Dne 23.9.2013 11:59, Paul Norman napsal(a): Unless the closed way is a member of a multipolygon relation with no other tags on the relation - then you'll have a resulting area with a hole. This is a very well established means of tagging areas with holes (~22% of type=multipolygon relations

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]: I propose that: 1) By default the relation and ways are treated separately - relation creates polygon with tags from the relation and ways are processed on their own. 2) If and only if the relation has only type=multipolygon tag go to

Re: [OSM-talk] osm2pgsql multipolygon parsing

Sorry, I meant osm2pgsql is not used for the slippy map ONLY. Thanks for all the feedback :) Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ talk mailing list talk@openstreetmap.org

Re: [OSM-talk] osm2pgsql multipolygon parsing

Dne 23.9.2013 16:03, Peter Wendorff napsal(a): Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]: I propose that: 1) By default the relation and ways are treated separately - relation creates polygon with tags from the relation and ways are processed on their own. 2) If and only if the

Re: [OSM-talk] osm2pgsql multipolygon parsing

quot;Petr Morávek [Xificurk]quot;-2 wrote Anyway, this thread was not started to debate tagging schemes, the question I (and others) wanted to discuss here is this: Given the data that are currently in the database, how should osm2pgsql handle the import to get as much as possible

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 22/set/2013 um 04:14 schrieb Eugene Alvin Villar sea...@gmail.com: It's most likely that these people are not familiar with relations and they see an outer way with no building=yes tag and decided to helpfully tag it. Because of this, a more complicated interpretation of tags, such

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 22.09.2013 04:14, schrieb Eugene Alvin Villar: I agree that this is a good way of tagging multipolygons. Unfortunately, many people don't tag multipolygons in this way. I've seen people add building=yes to an outer way of a building with holes even though there's a multipolygon relation

Re: [OSM-talk] osm2pgsql multipolygon parsing

Osm2pgsql is not used for the default map on osm.org. While the current behaviour in osm2pgsql is OK for consumers, could a 'strict' mode to handle mutipolygons be used on osm.org default map ? Of course, it should be accompagnied with a large campaign of multi-polygons fix. Yves

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013/9/22 yvecai yve...@gmail.com Of course, it should be accompagnied with a large campaign of multi-polygons fix. I'd suggest to start modifying the recommendations in the wiki: http://wiki.openstreetmap.org/wiki/Multipolygon reads: If you have one closed way making up the outer ring and

Re: [OSM-talk] osm2pgsql multipolygon parsing

On 22/09/2013 10:03, yvecai wrote: Of course, it should be accompagnied with a large campaign of multi-polygons fix. ... and a patch to any editors that don't create multipolygons in this format. For example, here are three attempts at multipolygons in iD, P2 and JOSM:

Re: [OSM-talk] osm2pgsql multipolygon parsing

Am 22.09.2013 11:31, schrieb Martin Koppenhoefer: 2013/9/22 yvecai yve...@gmail.com Of course, it should be accompagnied with a large campaign of multi-polygons fix. I'd suggest to start modifying the recommendations in the wiki: http://wiki.openstreetmap.org/wiki/Multipolygon reads:

[OSM-talk] osm2pgsql multipolygon parsing

Hello, I've run into some problems with osm2pgsql parsing of multipolygon relations, so I've opened an issue on github [1]. It turned out that the behavior was recently changed. The remaining question is, what should be the correct behavior? The question is not easy to answer, because there are

Re: [OSM-talk] osm2pgsql multipolygon parsing

Hi, The remaining question is, what should be the correct behavior? My assumption until now was: * If a multipolygon is untagged - where untagged means that it has no tags except a small list (type, source, source:*, note) then it will simply receive *all* tags from all (outer) member ways,

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013/9/21 Frederik Ramm frede...@remote.org Hi, The remaining question is, what should be the correct behavior? My assumption until now was: * If a multipolygon is untagged - where untagged means that it has no tags except a small list (type, source, source:*, note) then it will simply

Re: [OSM-talk] osm2pgsql multipolygon parsing

IMHO it's clear: - a tag on a way describes that way, if it's a closed way and the tag is describing an area, the tag matches the complete area inside that polygon. - if a way is outer of a multipolygon and there are tags on the way, these tags nevertheless describe the whole area, including all

Re: [OSM-talk] osm2pgsql multipolygon parsing

On Sun, Sep 22, 2013 at 4:51 AM, Peter Wendorff wendo...@uni-paderborn.dewrote: IMHO it's clear: - a tag on a way describes that way, if it's a closed way and the tag is describing an area, the tag matches the complete area inside that polygon. - if a way is outer of a multipolygon and there

Re: [OSM-talk] osm2pgsql import failed, no more space on device

Hi, On 09/07/2013 08:48 AM, Torsten Mohr wrote: I think --flat-nodes needs a parameter, but i'm not sure what to give there. A file name. I can't imagine that 480 Gb is not enough, can anybody tell me what went wrong? Are you *sure* that your PostgreSQL table space is actually on the 480

Re: [OSM-talk] Osm2pgsql/TileMill - how to detect whether way is in a route?

* Steve Bennett stevag...@gmail.com [2013-03-19 10:52 +1100]: One way to fudge this is to render the way, then render the route relation over the top, obscuring it. But that doesn't work if you want to use line smoothing (eg, line-smooth:0.6). The route relation will form a smooth bezier curve

[OSM-talk] Osm2pgsql/TileMill - how to detect whether way is in a route?

Hi, I'm trying to render a mountain bike map with TileMill. Some trails are in route relations, eg: 3xWay: highway=path, mtb=yes 1xRelation: type=route, route=mtb, name=My Cool Trail Osm2pgsql converts those to 4 rows: the relation is the complete trail. What I want to do is not render any

Re: [OSM-talk] Osm2pgsql/TileMill - how to detect whether way is in a route?

Hi, On 19.03.2013 00:52, Steve Bennett wrote: So I'm just wondering if there is a way around this - some setting in osm2pgsql, some SQL magic I could play with. It will be very slow magic, but two things come to mind: One would use the line geometry table and ask for routes in the vicinity

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On 2/16/2012 6:00 PM, Jochen Topf wrote: Generic key names can be confusing, especially when one OSM object is used for multiple things. Say there is a way tagged as railway and at the same time this way is part of an area tagged as a generating station. Does power_source mean the type of

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On Fri, Feb 17, 2012 at 07:44:41AM +, Jukka Rahkonen wrote: Frederik Ramm frederik at remote.org writes: Hi, On 02/16/2012 07:25 PM, Graham Jones wrote: This reminded me of a question I have been meaning to ask for quite a while - is a database generated by osm2pgsql with an

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

- is a database generated by osm2pgsql with an hstore expected to perform similarly to one without? It performs at the same speed for me. Of course you're not supposed to use hstore for every tag, but just for those on highest zoom levels, where spatial indexes are used mostly, not indexes for

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

Komяpa writes: - is a database generated by osm2pgsql with an hstore expected to perform similarly to one without? It performs at the same speed for me. Of course you're not supposed to use hstore for every tag, but just for those on highest zoom levels, where spatial indexes are used

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

Thanks - I will give it another try - I have got a computer running Ubuntu 11.10, which has Postgres 9.1.2. I will create a second database with an hstore and see how it compares. Graham. On 17 February 2012 11:36, Stephan Knauss o...@stephans-server.de wrote: Komяpa writes: - is a

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

Jochen Topf jochen at remote.org writes: Much too slow. Requiring joins on every query is not a good idea. And having the right indexes is important. You can't just index everything and hope it would do the right thing. (The most important index btw is the geometry index not the attribute

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On Fri, Feb 17, 2012 at 02:02:26PM +, Jukka Rahkonen wrote: Jochen Topf jochen at remote.org writes: Much too slow. Requiring joins on every query is not a good idea. And having the right indexes is important. You can't just index everything and hope it would do the right thing.

[OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On 16 February 2012 16:25, Frederik Ramm frede...@remote.org wrote: Hi, On 02/16/2012 03:05 PM, Kay Drangmeister wrote: Isn't there a hstore in the rendering-db? No. This reminded me of a question I have been meaning to ask for quite a while - is a database generated by osm2pgsql with

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

Hi, On 02/16/2012 07:25 PM, Graham Jones wrote: This reminded me of a question I have been meaning to ask for quite a while - is a database generated by osm2pgsql with an hstore expected to perform similarly to one without? I never ran one with hstore when I think of what this must mean for

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On 16 February 2012 18:51, Frederik Ramm frede...@remote.org wrote: On 02/16/2012 07:25 PM, Graham Jones wrote: This reminded me of a question I have been meaning to ask for quite a while - is a database generated by osm2pgsql with an hstore expected to perform similarly to one without? I

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On 16-2-2012 19:25, Graham Jones wrote: grumble Why create a key generator:power_source rather than just use power_source. power_source is much more generic so you could re-cycle it for things like district heating, but generator:power_source is only ever going to be used for generating

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

On Thu, Feb 16, 2012 at 06:25:30PM +, Graham Jones wrote: grumble Why create a key generator:power_source rather than just use power_source. power_source is much more generic so you could re-cycle it for things like district heating, but generator:power_source is only ever going to be

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

2012/2/17 Jochen Topf joc...@remote.org: On Thu, Feb 16, 2012 at 06:25:30PM +, Graham Jones wrote: Generic key names can be confusing, especially when one OSM object is used for multiple things. +1. E.g. an object tagged barrier=fence, height=2, landuse=forest. In this example you could

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

Frederik Ramm frederik at remote.org writes: Hi, On 02/16/2012 07:25 PM, Graham Jones wrote: This reminded me of a question I have been meaning to ask for quite a while - is a database generated by osm2pgsql with an hstore expected to perform similarly to one without? I never ran

[OSM-talk] osm2pgsql - some tables missing

hi, on importing data with osm2pgsql, there is no error, but some tables are missing: gis=# \dt List of relations Schema |Name| Type | Owner ++---+- public | geometry_columns | table | gisuser public |

[OSM-talk] osm2pgsql - some tables missing

hi, on importing data with osm2pgsql, there is no error, but some tables are missing: gis=# \dt List of relations Schema |Name| Type | Owner ++---+- public | geometry_columns | table | gisuser public |

Re: [OSM-talk] osm2pgsql - some tables missing

Hi, On 08/10/2011 09:54 AM, kenneth gonsalves wrote: on importing data with osm2pgsql, there is no error, but some tables are missing: This is the normal set of tables that you get when importing without --slim. It is fully sufficient for rendering. Only if you want to do incremental

Re: [OSM-talk] osm2pgsql - some tables missing

On Wed, 2011-08-10 at 10:00 +0200, Frederik Ramm wrote: On 08/10/2011 09:54 AM, kenneth gonsalves wrote: on importing data with osm2pgsql, there is no error, but some tables are missing: This is the normal set of tables that you get when importing without --slim. It is fully sufficient

Re: [OSM-talk] osm2pgsql for 64-bit

On 09.06.2011 16:10, Saphy Mo wrote: For windows 64 there is need of osm2pgsql for 64-bit. is there any version of that available for users? a while ago I tried a cross compile and failed on the needed include library from postgres 8.3. I was not able to create a 64bit lib of it. With

[OSM-talk] osm2pgsql for 64-bit

For windows 64 there is need of osm2pgsql for 64-bit.is there any version of that available for users? regards, Saphy___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] osm2pgsql error in Oxford/Cotswolds .osm data 19/12/09

Hello everyone, I'm having problems loading in a slab of OSM data for the Oxford/Cotswolds area for the UK extract for 19/12/09 downloaded from geofabrik.de. osm2pgsql stops with the error Error allocating ways (no other info is produced) The relevant file is

Re: [OSM-talk] osm2pgsql error in Oxford/Cotswolds .osm data 19/12/09

On Tue, 2009-12-22 at 17:21 +, Nick Whitelegg wrote: Hello everyone, I'm having problems loading in a slab of OSM data for the Oxford/Cotswolds area for the UK extract for 19/12/09 downloaded from geofabrik.de. osm2pgsql stops with the error Error allocating ways (no other info is

[OSM-talk] osm2pgsql usage

Hello, I asked that question on the mapnik mailing list but was told that the OSM mailing list would have more knowledgeable people on this issue: I was in the process of setting up Mapnik and as a start I was using an OSM file from around my area to test with small data. I get stuck with an

Re: [OSM-talk] osm2pgsql usage

The data file comes from XAPI ( http://www.informationfreeway.org/api/0.6/map?bbox=-83.56,42.17,-83.01,42.71 ) and works fine for other purposes like generating a map for my GPS using mkgmap. Have you tried loading a even smaller part from api? This could sort out problems with the xapi

Re: [OSM-talk] osm2pgsql

On Fri, 2009-06-26 at 18:28 -0400, James McManus wrote: Hi - I'm trying to use osm2pgsql to extract a subset area of OSM, but the --bbox option does not appear to be working. I downloaded planet-090617.osm.bz2 and then issued the following command: osm2pgsql --bbox -0.5,51.25,0.5,51.75 -m

Re: [OSM-talk] osm2pgsql

On Fri, 2009-06-26 at 23:44 +0100, Jon Burgess wrote: On Fri, 2009-06-26 at 18:28 -0400, James McManus wrote: But it runs for hours and uses up all of my RAM. I eventually have to kill it. How long should it take to subset a small area such as this? How much RAM and swap do you have?

[OSM-talk] osm2pgsql and proper/legacy mercator

Hi list, osm2pgsql --help says: -m|--merc: Store data in proper spherical mercator (default) -M|--oldmerc: Store data in the legacy OSM mercator format I'm wondering what's the difference between those two srs. Which one is epsg:900913 (aka epsg:3785

Re: [OSM-talk] osm2pgsql and proper/legacy mercator

On Fri, May 1, 2009 at 4:52 PM, Francois Van Der Biest francois.vanderbi...@camptocamp.com wrote: Hi list, osm2pgsql --help says: -m|--merc: Store data in proper spherical mercator (default) -M|--oldmerc: Store data in the legacy OSM mercator format I'm wondering what's the difference

Re: [OSM-talk] osm2pgsql and proper/legacy mercator

On Fri, 2009-05-01 at 17:52 +0200, Francois Van Der Biest wrote: Hi list, osm2pgsql --help says: -m|--merc: Store data in proper spherical mercator (default) -M|--oldmerc: Store data in the legacy OSM mercator format I'm wondering what's the difference between those two srs. Which one is

Re: [OSM-talk] osm2pgsql and proper/legacy mercator

...@openstreetmap.org en nombre de Francois Van Der Biest Enviado el: vie 01/05/2009 17:52 Para: talk@openstreetmap.org Asunto: [OSM-talk] osm2pgsql and proper/legacy mercator Hi list

[OSM-talk] Osm2pgsql and column names with two underscores

Hi, An osm2pgsql user writes on the forum about importing special tags into PostGIS. He has defined for example these tags: node openGeoDB:telephone_area_code text node openGeoDB:license_plate_code text Import fails and error message is: CREATE

Re: [OSM-talk] Osm2pgsql and column names with two underscores

On Mon, Mar 30, 2009 at 2:08 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Hi, An osm2pgsql user writes on the forum about importing special tags into PostGIS. He has defined for example these tags: node       openGeoDB:telephone_area_code       text node      

Re: [OSM-talk] Osm2pgsql and column names with two underscores

On Monday 30 March 2009 14:08, Jukka Rahkonen wrote: Hi, Hi, ( better transfert this to dev ?) An osm2pgsql user writes on the forum about importing special tags into PostGIS. He has defined for example these tags: node openGeoDB:telephone_area_code text node

Re: [OSM-talk] Osm2pgsql and column names with two underscores

On Monday 30 March 2009 14:08:11 Jukka Rahkonen wrote: Look at these: openGeoDB:telephone_are a_code, openGeoDB:license_plate _code It looks like column name gets truncated at the second underline character. Could it be some bug in osm2pgsql, or is it some other place where the error

Re: [OSM-talk] Osm2pgsql fails with Finland.osm.bz2

Hi, Jukka Rahkonen wrote: Processing: Node(2835k) Way(194k) Relation(0k)terminate called after throwing an instance of 'geos::util::TopologyException' what(): TopologyException: found non-noded intersection between 2.78294e+006 9.41427e+006, 2.78315e+006 9.41433e+006 and 2.78326e+006

Re: [OSM-talk] Osm2pgsql fails with Finland.osm.bz2

On Wed, 2009-02-04 at 15:27 +, Jukka Rahkonen wrote: Hi, I have been importing Finland.osm.bz2 dataset from Geofabrik into Postgis every day with osm2pgsql.exe (on Windows) but now it fails. The error looks like this: Reading in file: finland.osm.bz2 Processing: Node(2835k) Way(37k)

Re: [OSM-talk] Osm2pgsql fails with Finland.osm.bz2

Jon Burgess jburgess777 at googlemail.com writes: On Wed, 2009-02-04 at 15:27 +, Jukka Rahkonen wrote: Hi, I have been importing Finland.osm.bz2 dataset from Geofabrik into Postgis every day with osm2pgsql.exe (on Windows) but now it fails. The error looks like this:

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Sun, Oct 26, 2008 at 06:11:04PM -0700, Michal Migurski wrote: What is the difference between osmosis and osm2pgsql, with regards to postGIS? osm2pgsql creates the structure needed for Mapnik. Osmosis creates a structure more simliar to the one in the OSM central database. If I've been

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Shaun McDonald wrote: On 27 Oct 2008, at 00:50, Michal Migurski wrote: Planet dumps are not snapshots - they do not represent a consistent view at any particular point in time because they take a number of hours to generate, during which time new changes are constantly being made to the

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Mon, Oct 27, 2008 at 08:22:32AM +, Tom Hughes wrote: Shaun McDonald wrote: On 27 Oct 2008, at 00:50, Michal Migurski wrote: Planet dumps are not snapshots - they do not represent a consistent view at any particular point in time because they take a number of hours to generate,

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Others have already commented on most of your points but I'll add my thoughts in case there's some gaps. Michal Migurski wrote: Hi, I've been trying to keep up to date with the dumps and diffs from http://planet.openstreetmap.org/ , and I'm running into a number of bugs related to cutoff

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Jochen Topf wrote: If the planet dump plus the diff from the same day is what everybody wants anyway, why not do this on the server side and hold the planet back after the first diff is available, run this over the planet and then publish that as the planet? It would add delay to the

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Hi, Brett Henderson wrote: Brett Henderson has offered to look into creating the dailies from history as well, but I don't know about the status of that. Are you referring to the daily changesets? [...] Or did you mean planets instead of dailies? Mix-up on my part, sorry, yes I meant

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Yep, as others have commented there are two tables types in the osm database; current tables, and history tables. The planet dumper just reads current tables which is the fastest approach. Unfortunately the current tables change constantly during the planet generation process

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Mon, Oct 27, 2008 at 9:39 PM, Michal Migurski [EMAIL PROTECTED] wrote: I'm liking Jochen Topf's suggestion here: If the planet dump plus the diff from the same day is what everybody wants anyway, why not do this on the server side and hold the planet back after the first diff is

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Mon, Oct 27, 2008 at 9:40 PM, Michal Migurski [EMAIL PROTECTED] wrote: Now that I think about it though, I think what I did was take one of the planet dumps from http://hypercube.telascience.org/planet/ (which *are* consistant snapshots), and run the dailies from there. Is there any reason

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Tue, Oct 28, 2008 at 7:39 AM, Michal Migurski [EMAIL PROTECTED] wrote: Finally, the boundaries between the hourlies and dailies seem misaligned. This shouldn't be the case. After running the remaining hourlies for the 22nd, I attempted to pick up on the 23rd with a daily. The

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Mon, Oct 27, 2008 at 9:39 PM, Michal Migurski [EMAIL PROTECTED] wrote: I'm liking Jochen Topf's suggestion here: If the planet dump plus the diff from the same day is what everybody wants anyway, why not do this on the server side and hold the planet back after the first diff

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Michal Migurski wrote: The final event in each weekly planet dump does not fall on an even day boundary. In the case of the most recent Oct. 22nd planet.osm, it was necessary to experiment with hourly diffs from that day to find that the boundary was approx. 2:00pm. Hourlies up to and

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

Hi, Michal Migurski wrote: I've noticed some misalignments between the data in the dumps and the osm2pgsql importer that leads to unavoidable holes in the data. As TomH has already said, this is not a bug, it stems from the fact that the full planet export reads the current tables and as

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

The final event in each weekly planet dump does not fall on an even day boundary. In the case of the most recent Oct. 22nd planet.osm, it was necessary to experiment with hourly diffs from that day to find that the boundary was approx. 2:00pm. Hourlies up to and including

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On Oct 26, 2008, at 5:50 PM, Frederik Ramm wrote: Brett Henderson has offered to look into creating the dailies from history as well, but I don't know about the status of that. If you use osmosis, it is safe (and in fact recommended) that, after loading the database with a planet file

Re: [OSM-talk] osm2pgsql planet: frustrations, cutoffs, and idempotence

On 27 Oct 2008, at 00:50, Michal Migurski wrote: The final event in each weekly planet dump does not fall on an even day boundary. In the case of the most recent Oct. 22nd planet.osm, it was necessary to experiment with hourly diffs from that day to find that the boundary was approx.

[OSM-talk] osm2pgsql password for non-interactive use

Hi, It appears that osm2pgsql (SVN version 0.55-20080901) does not have a way to specify the db password on the command line. Is this true? It'd be nice to be able to run it without needing to babysit the password prompt at the beginning. Can this be added a flag? -mike.

Re: [OSM-talk] osm2pgsql - invalid input syntax for integer : Breërivier

Yes, downloading the last version fron SVN the error was resolved. Thanks. Rpr 2008/4/16, Martijn van Oosterhout [EMAIL PROTECTED]: On Wed, Apr 16, 2008 at 7:05 PM, Ricardo Peironcely [EMAIL PROTECTED] wrote: I've a problem with osm2pgsql and the last version of planet file. When I

[OSM-talk] osm2pgsql - invalid input syntax for integer : Breërivier

I've a problem with osm2pgsql and the last version of planet file. When I try to execute the process, always receive the same error: invalid input syntax for integer: Breërivier Any one knows something about this? Thanks in advance. Rpr ./osm2pgsql -u -U postgres -d map planet-080409.osm.bz2

  1   2   >