import wkt data in csv files

I am having the same issue.... trying to import a linestring wkt file via feeds and nothing imports? No errors and no data. If I copy one of the item from the csv file into the geofield works fine. The import just does not work..help... LINESTRING(-89.2366 48.39772,-89.2366 48.39772,-89.2366 48.39774,-89.2366 48.39779,-89.2366 48.39906,-89.2366 48.39908,-89.2366 48.39909,-89.2367 48.39911)

Same

Subscribe. I am trying to import from csv to a taxonomy with a PostGIS (geospatial data) field for the WKT info (from a QGIS data export). Everything is working except this field, which shows (EMPTY) geometry. I suspect the text field is not allowing enough characters, but what is a good fix? Reducing decimal points reduces accuracy, as does simplifying the geometries. I had the same issue for another site installed on MySQL with Geofield. Importing with feeds did not work but I was able to copy and paste the WKT information into the field manually. This would be okay, but now I have thousands of features that need WKT data.

I suspect I am having issues due to the complexity of the shapes, ie: lots of points that make up the geometries. The PostGIS field is capable of handling the complex shapes when I manually enter the WKT into the field. However it fails when trying to populate this field when importing. Could it be that the feeds importer cannot handle large enough WKT files, even though the database field can handle it?

This looks like a geofield issue.

I have found this same issue with Geofield when Drupal is installed on MySQL and with a PostGIS field ('geospatial data' field) installed on Postgresql. In both cases, when the WKT info is manually inserted into the field, all works well. But when trying to import, this field remains empty. When I edit the content (or taxonomy) the text field shows 'GEOMETRYCOLLECTION(EMPTY)'
It seems like it may be a character limit within the Feeds module, or other related module. Being that it is just text, and I can copy and paste them in manually fine, what else can it be?

I am experiencing this as well. I am successful with this in other cases, so I am going to hunt down any version issues I can see between my working and non-working installs. For what this is worth, the actual error is spawned in the GeoPHP Module: /geophp/geoPHP/lib/geometry/LineString.class.php

I just fleshed out a little more about my own error case. I determined that the error was caused by the presence of spaces in the WKT string before the first point longitude. It seems that PostGIS wkt parsing functions are OK with this (example below), but the geoPHP is not happy.

Postgis handles spaces OK, as is evidenced by the fact that it st_geomFromText creates a valid geom from BOTH of the below:

-- good one for GeoPHP without spaces
select asText(st_geomFromText('POINT(-75.7416666666667 37.7091666666667)'));

                  astext
-------------------------------------------
 POINT(-75.7416666666667 37.7091666666667)
(1 row)

-- bad one with spaces
select asText(st_geomFromText('POINT( -75.7416666666667 37.7091666666667 )'));

                  astext
-------------------------------------------
 POINT(-75.7416666666667 37.7091666666667)
(1 row)

A Feeds importer fails on the one with spaces, but is OK with one that doesn't possess spaces:

title	wkt
good4geophp	POINT(-75.7416666666667 37.7091666666667)
bad4geophp	POINT( -75.7416666666667 37.7091666666667 )

The screenshots attached show the results of this file - good one goes in, bad one does not. Given that WKT is space delimited within the XY pair it may be as easy as using a trim() function before splitting on spaces?

I believe based on #10 that this is a GeoPHP issue.

Verified that for my case, applying an additional "trim" to remove spaces before the first point in a WKT POINT declaration allows import to complete without error. Source of error is in the WKT parsers in ./geoPHP/lib/adapters/WKT.class.php - code snip below shows the needed change.

    $data_string = trim($this->trimParens($data_string));
//    $data_string = $this->trimParens($data_string);

Patch attacjed which fixes only "parsePoint" - work on a patch applying this fix to all affected methods if someone can look at this use case.

Hey @de_chris there may be more than one problem case here - your case may be that geophp doesn't like geometrycollection? Can you try with just POINT(13.266279 52.375039) - and if you need multiple points in a single node, use MULTIPOINT((13.266279 52.375039)) instead? Note, my multipoint syntax is just a guess, you will need to verify format for multipoint.

I have something similar when trying to import KML data from CSV to Geospatial data field (Geometry Collection, SRID 4326) using Feeds.
If I'm importing KML to node with geofield - everything's fine. But if I'm trying to import same KML to taxonomy term with same geofield, I got this:

SQLSTATE[XX000]: Internal error: 7 ERROR: parse error - invalid geometry HINT: "GEOMETRYCOLLECTION(EMPTY)" <-- parse error at position 25 within geometry

Changing "Geometry Collection" to "Multi Polygon" in term geofield gives this result: successful import, but new term have only "GEOMETRYCOLLECTION(EMPTY)" in geofield.
Very strange...

I have something similar when trying to import KML data from CSV to Geospatial data field (Geometry Collection, SRID 4326) using Feeds.
If I'm importing KML to node with geofield - everything's fine. But if I'm trying to import same KML to taxonomy term with same geofield

I can confirm this with PostGIS Field, along with this log:

Notice: Undefined property: stdClass::$language in postgis_feeds_set_target() (line 85 of <sitename>\profiles\cartaro\modules\contrib\postgis\includes\postgis.feeds.inc).

@de_chris - perhaps it is the nesting of geometrycollection and point that GeoPHP is unable to contend with? Is there a specific reason why the data needs to be in a collection?

I'm using patch from #12 with Migrate module and it seems to work correctly.