Chris,
I'm not suggesting that you change your workflow yet, only that you try
some experiments. I've worked with both Spatialite and postgis, but I
have much more experience with postgis.
While they both have many of same functions, the interactions with the
indexes is much more automatic
Hi again Steve, The input is osm data, filtered so that only highways of some
significance remain. I am trying to get road intersections as points based
on certain criteria. I have an ogr2ogr sqlite based workflow that works on
test data. But scaling up is proving to be a problem for this
On 4/10/2017 5:51 PM, CTL101 wrote:
I've removed the intersection part after realising that I didn't need it as
the intersection geometry is already calculated in the input (slow hand
clap me!)
So after investigating a bit more I have:
ogr2ogr -gt unlimited -nlt PROMOTE_TO_MULTI25D --config
I've removed the intersection part after realising that I didn't need it as
the intersection geometry is already calculated in the input (slow hand
clap me!)
So after investigating a bit more I have:
ogr2ogr -gt unlimited -nlt PROMOTE_TO_MULTI25D --config OGR_SQLITE_CACHE
10240 -f SQLite -dsco
Peter Baumann wrote
> Hi all,
>
> why not simply check against the compliance tests of WCS 2 and maybe a
> reference
> implementation? Might be the easiest for answering all such questions.
>
> cheers,
>
> Peter
Hi,
I could not find exact match for raster image (GeoTIFF) case from
Hi all,
why not simply check against the compliance tests of WCS 2 and maybe a reference
implementation? Might be the easiest for answering all such questions.
cheers,
Peter
On 04/10/2017 04:23 PM, Even Rouault wrote:
>
> On lundi 10 avril 2017 15:57:03 CEST Andrea Aime wrote:
>
> > Hi Even,
CTL101 wrote
> Hi Jukka, Thanks for your advice and the useful link. I have done as you
> suggested and put together a revised query and tested in on a sample. This
> worked successfully and significantly more quickly. I will now test on the
> full dataset. The following is my command as it
Hi,
Even wrote:
However I'm not sure in which way GDAL is involved in this discussion :-)
I am preparing for the future when GDAL will have a support for WCS 2.0.1 and
it will try to read EPSG:4326 coverage data from GeoServers witch describe
coverage like this:
Hi Jukka, Thanks for your advice and the useful link. I have done as you
suggested and put together a revised query and tested in on a sample. This
worked successfully and significantly more quickly. I will now test on the
full dataset. The following is my command as it stands. Is this what you
On lundi 10 avril 2017 15:57:03 CEST Andrea Aime wrote:
> Hi Even,
> in CIS 1.1 they state:
>
> Coverages are assumed to have a 1:1 correlation between the axis names
> given in axis-Labels and gridLabels, i.e.: they shall relate pairwise,
> given by their sequence position. For example,
Hi Even,
in CIS 1.1 they state:
Coverages are assumed to have a 1:1 correlation between the axis names
given in axis-Labels and gridLabels, i.e.: they shall relate pairwise,
given by their sequence position. For example, axisLabels=“Lat Long h date”
and gridLabels={i j k l} implies a
On lundi 10 avril 2017 15:06:55 CEST Andrea Aime wrote:
> Hi,
> sorry I lost track of the subject. So, to close up, and approach where the
> envelope is reported as "lat lon" and the "i j" raster space
> axis would map pairwise, so i pointing north-wards and j east-wards, would
> be considered
Hi,
sorry I lost track of the subject. So, to close up, and approach where the
envelope is reported as "lat lon" and the "i j" raster space
axis would map pairwise, so i pointing north-wards and j east-wards, would
be considered valid?
E.g., if one rescaling says "i is going to be 200 pixels" it
Hi,
>
> gnm_wrap.cpp is missing in GDAL-2.1.3.tar.gz on
> https://pypi.python.org/pypi/GDAL:
> https://pypi.python.org/packages/36/d7/f89ac1347185db56939c156330efbfa2e3be
> 560060b74e31f41e514ee627/GDAL-2.1.3.tar.gz
> This caused the following error when building osgeo._gnm extension:
In GDAL
14 matches
Mail list logo
