Importing OSM data

GRASS GRASS user
, ,
1

Please help: I use

g.proj -c project=LWT_region datumtrans=-1 epsg=27700

So I make the project current:

g.mapset mapset=PERMANENT project=LWT_region

fine. I am using postgresql + postgis to store OSM data. Because I had problems with this every time I try, I used delete from spatial_ref_sys where srid <> 27700; to make the CRS unambiguos. Now when I import data with v.in.osm I still get:

Coordinate reference system of dataset does not appear to match
       current project.

Project PROJ_INFO is:
       name: OSGB36 / British National Grid
       ellps: airy
       proj: tmerc
       lat_0: 49
       lon_0: -2
       k: 0.9996012717
       x_0: 400000
       y_0: -100000
       no_defs: defined

       Dataset PROJ_INFO is:
       Dataset proj = 0 (unreferenced/unknown)

g.proj -j returns:

+proj=tmerc
+lat_0=49
+lon_0=-2
+k=0.9996012717
+x_0=400000
+y_0=-100000
+ellps=airy
+units=m
+no_defs
+type=crs

Which is correct. v.in.osm -o doesn’t work. I’ve been trying all the different ways to import these data. It has taken me many days to get started with GRASS. I would use QGIS but it relies on 32 bit libraries, which I want to steer clear of.

2

I don’t have any experience with this tool, so I am not sure why the o flag doesn’t work, it looks like it should. Can you post the entire command?
Also you can try to create a project in the native CRS of the data (4326 or 3857?) and import it there and see how it goes. You can always reproject it later.

3

In my OSM database I have (had, but I can regenerate it) 5800 records that seemed to include all the alternative SRS codes. So I just selected the one close to the area I’m interested in and deleted the rest. The table now has one row, The command I used to fetch the data from the database was:

v.in.osm input="PG:host=localhost dbname=osm user=osmuser" table=planet_osm_line type=point,line output=roads

which is an editted version of the example given in v.in.osm manual .

4

You don’t have the -o flag in the command…

5

Apologies. I get this weird error when I use -o:

GRASS LWT_region/PERMANENT:~ > v.in.osm -o input="PG:host=localhost dbname=osm user=osmuser" table=planet_osm_line type=point,line output=roads

ERROR: v.in.ogr: Sorry, <T> is not a valid flag
ERROR: v.in.ogr: Sorry, <u> is not a valid flag
ERROR: v.in.ogr failed
WARNING: No data base element files found
6

There is a bug, I will let you know when the fix is merged so you can reinstall it.

7

Isn’t it reporting errors at the end of this:

def main(self, options, flags):
        # just get the layer names
        if flags["l"]:
            try:
                gs.run_command(
                    "v.in.ogr", quiet=True, input=options["input"], flags="l"
                )
                sys.exit()
            except CalledModuleError:
                gs.fatal(_("%s failed") % "v.in.ogr")
        else:
            if not options["table"]:
                gs.fatal(_("Required parameter <%s> not set") % "table")
            if not options["output"]:
                gs.fatal(_("Required parameter <%s> not set") % "output")

It looks as if the if block needs an elif flags["o"] block before the else. – Just my pennyworth.

8

I’ve switched to QGIS. I imported my data with about two clicks from the get go. No problem. However, it insists I use X11. Grass is happy with Wayland.

9

I merged the fix, so I would still be curious if that helped. The addon needs to be reinstalled with g.extension.

11

Hi Anna, Thank you for all the trouble you’re going through to get me started. Your mod certainly changed the behaviour but now I get a list of permission errors! I will check this out myself. I have run [db.connect] and [db.login] successfully and I always choose the correct pg driver and the right database name. I don’t hit this problem with QGIS, and the documentation for v.in.osm gives no hint of needing extra authorisation.

But leave it with me!

Thanks!

12

FYI: And in case anyone finds this useful: In the manual for osm2pgsql, it says:

This user doesn’t need any special rights. We’ll use osmuser here.

Actually, v.in.osm needs at least select and create table privileges.