There is pbf dump from OSM, debian, osmosis and mysql database. How to dump only nodes that point to houses/buildings with params lat, lon, street name and city name?
running osmosis with keys:
osmosis --read-pbf planet-latest.osm.pbf --tag-filter accept-nodes
addr:housenumber=*, addr:street=* --write-apidb dbType="mysql"
validateSchemaVersion=no
throws different error about duplicates. Look like it's because some nodes points to same location address. In current dump I'm telling only about address list, not the list of companies and places or so on.
Related
I split polygons into separate polygons that where connected. when I ran the function vector/data management tools/split vector layers. it created .gpkg files. i want to export from QGIS as shapefiles and name them from a field in the attribute table . is there a function in QGIS to do a bulk export of individual polygons and rename based on field ?
I used the plugin Bulk vector exporter and used lupus re name
I am attempting to store a LINESTRING using PostGIS into a column of type geography(LINESTRING, 4326). Here is my insert statement:
INSERT into routes (line) VALUES (st_linefromtext('LINESTRING(-35.3350743932 149.084182978,-35.3350306311 149.085041285)', 4326));
But when I run a query to get the line back out of the database.
SELECT st_astext(line) from routes;
Result:
LINESTRING(-35.3350743932 30.915817022,-35.3350306311 30.914958715)
The latitude coordinates come out completely differently from how I inputted them. Can anyone point out to me why this would be?
I am new to PostGIS - I think I must be missing something about the storage and retrieval of 4326 data. Any help appreciated.
I'm trying to convert the shape file which represents the administrative area of Philippines into geojson. I'm getting the shape file from here . The file I'm trying to convert is this PHL_adm3.shp .
I'm using this bash script:
function shp2geojson() {
ogr2ogr -f GeoJSON "$1.geojson" "$1.shp"
}
for var in *.shp; do shp2geojson ${var%\.*}; done
I ran this script on my server and got the corresponding geojson file. Now I ran the same script on my local and the geometry for many cities were different in my local than what was on my server. Though the coordinates do not differ much, they only differ after 6-7 places of decimal, but they throw an exception when I try to insert them in PostGIS.
Here's an example of the geometry that is producing error on server while inserting it in PostGIS. I'm also posting the geometry that I'm getting on my local of the same city.
Server: Geometry
Local: Geometry
I also ran ST_IsValidReason on both geometries. I got the following error on my server.
SELECT ST_IsValidReason(ST_SetSRID(
ST_GeomFromGeoJSON(my_geometry),4326))
Server : Error [('Self-intersection[120.979159 14.71218]',)]
Local : [('Valid Geometry',)]
I tried the exact same thing on different countries like India, Japan Thailand and for all those countries that I tested, the same thing was happening. On local I didn't found any error but on my server I was getting Invalid geometry.
Can anyone explain what's wrong with my queries and how to fix this ?
P.S.- Both of my systems are 64 bit and running Ubuntu 14.04.
I have import OpenstreetMap data into Postgres with gis extension with tool
osm2pgsql (-s option)
of course, I have the following tables
planet_osm_point
planet_osm_ways
....
Within planet_osm_ways I have a column called way, type geometry(LineString, 4326), content like following
"0102000020E6100000070000005E70BCF1A49F2540D3D226987B134840896764EB749F25403B5DCC858013484040D1860D609F2540C426327381134840CE50DCF1269F2540EF552B137E1348405AAB2CC02D9E2540F978324976134840D66F26A60B9D2540CE8877256E1348403CA81F2FFF9C2540BC1D86FB6D134840"
What is that ? How could I get all points along this way ?
Thanks a lot
That's hex-encoded extended well-known binary (EWKB) of a LINESTRING.
There are several methods to get the points along the way. To get individual coordinates as points, use ST_DumpPoints. Or to simply output the geometry in other human-readable formats (WKT, EWKT, GeoJSON, GML, etc.), see the relevant manual section.
i am trying to insert LineStrings to a local Postgres/PostGIS-database. I use Python 2.7, psycopg2 and ppygis.
Every time when i make a loop-input, only a few records were inserted into the table. I tried to find out the problem with mogrify, but i see no failure.
polyline = []
for row in positions:
lat = row[0]
lon = row[1]
point = ppygis.Point(lon, lat, srid=4326)
polyline.append(point)
linestring = ppygis.LineString(polyline, srid=4326)
self.cursor.execute("BEGIN")
self.cursor.execute("INSERT INTO gtrack_4326 (car, polyline) VALUES (%s,%s);", ("TEST_car", linestring))
self.cursor.execute("COMMIT")
The use of execute.mogrify results in Strings like this:
INSERT INTO gtrack_4326 (car,polyline) VALUES ('TEST_car', '0102000020e610000018000000aefab72638502940140c42d4d899484055a4c2d84250294056a824a1e3994840585b0c795f50294085cda55df1994840edca78a57650294069595249f8994840ec78dd6cbd502940828debdff5994840745314f93f5129407396fecaef994840e1f6bafbd25129404eab329de7994840da588979565229407a562d44e2994840ebc9fca36f522940c2af4797ed9948403bd164b5af5229407a90f9dbf99948407adbf1cb05532940818af4ec039a484062928087585329402834ff9e0e9a4840e8bb5b59a2532940b1ec38341b9a4840dcb28d89de532940afe94141299a484084d3275e0a54294019b1aab9379a484080ca42853454294053509b82469a48408df8043f6054294063844b22569a48406d3e09c7875429406dfbc33b659a4840aa5a77989b542940c20e08196d9a48401b56a7b9cb542940a0a0b9f3699a4840cf2d742502552940192543e9669a484045ac0f351b552940fdb0efd46d9a48406891ed7c3f552940450a0a28799a4840d0189c77525529405f7b6649809a4840');
But if i look into the Database, i see a lot of records without geometry-data in the second column. I did not understand why mogrify shows data in each column and in the DB there is in nearly 50 % of the table no data in the geometry-column.
First, psycopg2 does its own transaction management, so you should generally write:
self.cursor.execute(
"INSERT INTO gtrack_4326 (car, polyline) VALUES (%s,%s);",
("TEST_car", linestring)
)
self.conn.commit()
See the psycopg2 docs.
Second, consider loading data in batches with COPY. See COPY in the psycopg2 docs.
Also consider setting log_statement = 'all' in postgresql.conf and a suitable log_line_prefix then restarting the PostgreSQL server. Examine the logs and see if you can tell what's doing the bogus inserts.
If practical, add a CHECK and/or NOT NULL constraint to the geometry column so that any incorrect INSERTs will fail and report an error to the program doing the insert. This might help you diagnose the problem.
How did you determine that 50% of the rows have no geometry data? I'll warn anyone using clients like pgAdminIII show a blank cell if it contains too much data, so it appears to be NULL, when it isn't. You can also directly view the GIS data in a program like Quantum GIS.
With an SQL client, a better diagnostic to determine if a linestring is really there is to get the number of points in the linestring:
SELECT car, ST_NumPoints(polyline) FROM gtrack_4326;
If the numbers are empty, then your assessment is correct that they are empty. Otherwise, the data are too large to display in your client application.