Thanks for responding Jukka!
I'm getting real irritated of myself for not getting such a simple thing to
work with such grate tools.
I have now tried with:
PEN(c:#FF00FF,w:3px,p:"3px 3px")
PEN(c:#FF00FF,w:3px,p:3px 3px)
PEN(p:"3px 3px",c:#FF00FF,w:3px)
PEN(p:3px 3px,c:#FF00FF,w:3px)
Ahmet,
You can use either the gdalwarp.exe or the underlying gdal warper C++ API to
create a new image using the polygon geometry as a cutline. See the
gdalwarp.exe or gdal warper C++ API documentation on how to do that.
Basically, the cutline geometry will NULL out any pixels in the
wow, thanks.
I'm not quite sure I'm following it all though. I'm reaching a bit my
knowledge limit here with those transforms. I'll need to spend a bit more
time on it to get more understanding and see what I can do, how I might use
your update.
But thanks for the quick turnaround
Cheers
---
> This is not a PROJ6 issue, but a GDAL one related to the logic starting at
> https://github.com/OSGeo/gdal/blob/master/gdal/ogr/ogrct.cpp#L843
>
> You could try to add a test that if OGRSpatialReference::GetTOWGS84()
> returns OGRERR_NONE then the resolution to the WKT of the EPSG code is
>
On mercredi 13 novembre 2019 16:18:32 CET Rahkonen Jukka (MML) wrote:
> Hi,
>
> GeoJSON from OGC API Features service may contain schema or reference to
> schema and OAPIF driver resolves it. Does the plain GeoJSON driver have the
> same support? If not, how about to add the support, possibly
Hi,
GeoJSON from OGC API Features service may contain schema or reference to schema
and OAPIF driver resolves it. Does the plain GeoJSON driver have the same
support? If not, how about to add the support, possibly with an open option to
read the schema from a local file? Otherwise it can
The implementation is fine. Thanks for listening to my comments, Even. I
think that plugins are really the business of apps like QGIS and MapServer
and that plugins in GDAL complicate the situation for developers, but one
might use these with caution in some special cases. -0 from me.
On Wed, Nov
+1
-Jukka Rahkonen-
Even Rouault-2 wrote
> Hi,
>
> I've updated both the RFC text and candidate implementation with the
> provided comments, so I think we are now good to vote on it.
>
> ~~
>
> Motion: adopt RFC 76 OGR Python drivers:
>
Hi,
What is supported is documented in a table in
https://gdal.org/drivers/raster/pdf.html. For PEN only these options are
supported: color (c); width (w); dash pattern (p).
So why, you know, nobody has implemented it yet. Meanwhile you can do
something with dash pattern, or edit the PDF with
Even,
Great!
Of course my +1
MArco
On 13-11-19 15:22, Even Rouault wrote:
Hi,
I've updated both the RFC text and candidate implementation with the
provided comments, so I think we are now good to vote on it.
~~
Motion: adopt RFC 76 OGR Python drivers:
Hi,
I've updated both the RFC text and candidate implementation with the
provided comments, so I think we are now good to vote on it.
~~
Motion: adopt RFC 76 OGR Python drivers:
On mercredi 13 novembre 2019 13:18:52 CET Grégory Bataille wrote:
> Hey Even,
>
> So I can confirm that this is the issue
> On Mac
> OGRCT: Selecting transformation +proj=pipeline +step +proj=axisswap
> +order=2,1 +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=450
> +y_0=0 +ellps=bessel
Hi,
I’m now setting attribute OGR_STYLE in my postGis db for a testlayer (line)
I’m now setting attribute OGR_STYLE in my postgis db for a test layer
(LineString):
… SET \"OGR_STYLE\"= 'PEN(c:#FF,id:ogr-pen-4,w:1px)'
Does anyone know why the pen symbol (id) is ignored when exporting the PDF,
Hey Even,
So I can confirm that this is the issue
On Mac
OGRCT: Selecting transformation +proj=pipeline +step +proj=axisswap
+order=2,1 +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=450
+y_0=0 +ellps=bessel +step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1
14 matches
Mail list logo