[gdal-dev] IIP: unable to translate if handled by openseadragon
Hello,
I tried to use GDAL to translate an iIIF image:
https://ianua.arianna4.cloud/patrimonio/1ec6a87e-c5ff-4156-a495-9e08f399a6ba/16-carta-topografica-del-territorio-di-serravalle-%5B1804-set-22%5D
OpenSeaDragon disables the direct link to the tiles, substituting it with
an indirect connection to the image server:
https://asge.jarvis.memooria.org/images/iiif/db/d4eca4e9-d5e9-4db7-9586-9ec0ff49d8c4/0,0,2048,2048/256,256/0/default.jpg
I couldn't manage to get something out of it with the IIP WMS micro-driver.
A hint, suggested by the documentation of OpenSeaDragon, led me to:
https://asge.jarvis.memooria.org/images/iiif/db/d4eca4e9-d5e9-4db7-9586-9ec0ff49d8c4/info.json
which is informative:
{
"@context" : "http://iiif.io/api/image/3/context.json";,
"protocol" : "http://iiif.io/api/image";,
"width" : 8721,
"height" : 13120,
"sizes" : [
{ "width" : 136, "height" : 205 },
{ "width" : 272, "height" : 410 },
{ "width" : 545, "height" : 820 },
{ "width" : 1090, "height" : 1640 },
{ "width" : 2180, "height" : 3280 },
{ "width" : 4360, "height" : 6560 }
],
"tiles" : [
{ "width" : 256, "height" : 256, "scaleFactors" : [ 1, 2, 4, 8,
16, 32, 64 ] }
],
"id" :
"https://asge.jarvis.memooria.org/images/iiif/db/d4eca4e9-d5e9-4db7-9586-9ec0ff49d8c4";,
"type": "ImageService3",
"profile" : "level1",
"maxWidth" : 8000,
"maxHeight" : 8000,
"extraQualities": ["color","gray","bitonal"],
"extraFeatures":
["regionByPct","sizeByForcedWh","sizeByWh","sizeAboveFull","sizeUpscaling","rotationBy90s","mirroring"],
"service": [
{
"@context": "http://iiif.io/api/annex/services/physdim/1/context.json";,
"profile": "http://iiif.io/api/annex/services/physdim";,
"physicalScale": 0.1,
"physicalUnits": "cm"
}
]
}
But I couldn't go further.
TIA for any help
c
--
--
Carlo A. Bertelli
Charta servizi e sistemi per il territorio e la storia ambientale srl
Dipendenze del palazzo Doria,
vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)
tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711
e-mail: berte...@chartasrl.eu http://www.chartasrl.eu
--
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] odbc issue
Dear Margherita, what about increasing complexity and adding a true spatial database in the middle? You could use PostgreSQL as a shared database that works well with both. I think both QGIS and FileMaker would benefit a lot by having an ORDBMS to help them to manage data in a more efficient way. Using a database server (any DBMS supported by both programs) would avoid lock-in and would open other research groups to use the tool they prefer to handle their data. c On Fri, Sep 16, 2022 at 9:00 PM Margherita Zannini (margh...@libero.it) wrote: > > Date: Fri, 16 Sep 2022 12:59:07 +0200 (CEST) > From: margh...@libero.it > To: "gdal-dev@lists.osgeo.org" > Subject: [gdal-dev] odbc issue > Message-ID: <58699396.106601.1663325947...@mail1.libero.it> > Content-Type: text/plain; charset="utf-8" > > > Good morning, > > > I write because I?ve a big issue. I?m an italian archaeologist and I?m > doing a PhD in an archaeological site in Spain. My project was based on > doing a gis on this site, but after an year working on it, my Professor > told me I need to create an automatic connection between Filemaker and > QGIS, otherwise I won?t be allow to continue my Phd, that for me it?s kind > of like life and death. > > > After some months of attempts I was able to connect the softwares through > ODBC (but there are some bugs and it works only using some specific > versions), but currently only filemaker can dialogue with QGIS but not vice > versa. I think that the issue is that ODBC driver that filemaker use for > connecting to QGIS is ?read only?. I did some attempts also between > filemaker and LibreOffice and I?ve the same issue, so I doubt could be that > filemaker doesn?t give the permission for driver ?writ?. > > > Anyway I read here ( > https://gdal.org/drivers/vector/odbc.html?fbclid=IwAR2mUiMTb9hsGLpDdSaSY_qnpny8DUTDKc49WVkPw4yvizBBnPB9JoOByX8#creation-issues) > that could be also a QGIS issue, so I want to know what do you think about > that and if this problem could be solved implementing that. My PhD is > without scholarship (so I?m not paid for this), but I?m so desperate that > I?m willing to pay for resolve this problem and, in this cane, I need to > know how much would be. > > > Thank you so much. > > > Margherita Zannini > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to deal with IIP image via WMS minidriver?
Dear Petr, I'm very fond of georeferencer.com; for many topographic and geographic maps it's more effective than using a desktop application like QGIS. The idea of implementing IIP/IIIF inside gdal has several reasons. The first one is due to rights over the images. They are meant for personal use, sometimes institutions are bound to contracts with private firms that would not allow them to put these on georeferencer (I'm strongly againt these agreements, but they are here to stay...), so hosting them elsewhere would be at least embarassing if not illegitimate (there should also be a way to open an arbitrary souce besides uploaded images, which is not the case). Another one is the ability of comparing historical maps one with another, which is sometimes useful, besides a comparison between an unreferenced image and Google Maps/Osm. Sometimes being able to use another reference, say a cadastral map or a very detailed one is compelling (which is a third reason). I think that an alternative way to use IIP/IIIF may be useful and in the spirit of and Open Source project as gdal. It's obviously easy to download the tiles one by one (jot/curl) and assemble them in a sometimes huge file (montage), but a more dynamic way is a must in these cases. Evan confirmed it would be fairly easy modifying the WMS mini-driver to do it, but I think a pseudo-referenced (by pixel) VRT file could be forged (as a temporary provision), knowing the number of tiles in a row (easy to do) and the number of rows. I'll try to raise some funding for the project to help in this development. Meanwhile, if someone would like to try doing something on it, I'll be grateful and I will try to support this effort even afterwards. c On Tue, Sep 15, 2015 at 12:12 AM, Petr Pridal wrote: > Dear Carlo, > > if you use our Georeferencer.com online service we can provide you with a > fast OGC WMTS service and crowdsourced online georeferencing of the remote > image sources such as IIIF or IIP done in a web browser. > > Best regards, > > Petr > > On Thu, Sep 3, 2015 at 5:17 PM, Carlo A. Bertelli (Charta s.r.l.) < > berte...@chartasrl.eu> wrote: > >> Hello, >> >> is there a way -- maybe using the WMS minidriver -- to open an IIP >> streamed picture? >> The online service is well documented ( >> http://iipimage.sourceforge.net/documentation/) but unfortunately it >> shows that the protocol is not at all compliant with the WMTS or TMS or >> Google/SlippyMap schemas, even if it shares some of the ideas behind them. >> There is an also an implementation of a plugin for Leaflet that could help. >> Would anyone give some advice on how to deal with this common raster map >> source for historical maps? >> c >> > -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel./fax +39(0)10 2475439 +39 0108566195 gsm:+39 393 1590711 e-mail: berte...@chartasrl.eu http://www.chartasrl.eu -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to deal with IIP image via WMS minidriver?
Hello, is there a way -- maybe using the WMS minidriver -- to open an IIP streamed picture? The online service is well documented ( http://iipimage.sourceforge.net/documentation/) but unfortunately it shows that the protocol is not at all compliant with the WMTS or TMS or Google/SlippyMap schemas, even if it shares some of the ideas behind them. There is an also an implementation of a plugin for Leaflet that could help. Would anyone give some advice on how to deal with this common raster map source for historical maps? c -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel./fax +39(0)10 2475439 +39 0108566195 gsm:+39 393 1590711 e-mail: berte...@chartasrl.eu http://www.chartasrl.eu -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Adding a "Commercial support" section on gdal.org?
Charta is interested to be listed as experienced provider if gdal.org will ever add info about commercial support. Nevertheless, I think this item has to receive more attention, considering at least: * the license of GDAL. Using MIT license means being expecially open to commercial usage. I don't know if this is really consequential with selecting a group of commercial providers instead of being agnostic about usage of the code and technology created (I don't agree with this, but...); * usually support means choice between several tools and technologies, being a core contributor could mean some bias about recurring to a specific tool. Being listed as such could become a double-edged sword; * any evaluation aobut support should be based on the help provided to the user and not about the contribution to the project. The client shoud be able to choose if he needs "broad" or "focused" support, if he needs new developments or better integration and so on. Listing experiences or specialisation (geodatabases, remote sensing and so on) could be more useful. Even's case is noteworthy, because he is more than a "Core contributor", but a project leader for GDAL. When his affiliation to École des Mines changed to his own company, Spatialys, I thought this was a very good move because he could more easily provide consulting services to commercial entities. Maybe his visibility as a prominent person in this community is already warranted, I understand that his proposal is addressed to others, but I think gdal-dev is about developing, although the list provides a lot of help to users, is this the right place? c On Thu, Aug 20, 2014 at 10:02:35 PM, Even Rouault wrote: Date: Wed, 20 Aug 2014 22:02:35 +0200 From: Even Rouault To: "gdal-dev@lists.osgeo.org" Subject: [gdal-dev] Adding a "Commercial support" section on gdal.org ? Message-ID: <201408202202.36022.even.roua...@spatialys.com> Content-Type: Text/Plain; charset="us-ascii" Hi, I'm wondering if there would be a concensus and interest to add a "Commercial support" section on gdal.org. A number of OSGeo projects have such page (see [1]), so that wouldn't be completely awkward to have one for GDAL as well. The OSGeo Service provider database reference 137 companies/individuals that have registered themselves as providing GDAL support ([2]) ! Pretty cool, but I'm wondering how a user not familiar with the project could effectively use that list to identify core contributors from casual advanced users. If we agree for adding a "Commercial support" section, the question is : on which criteria do we accept an organization/individual to be listed in the section ? We would want them to be as most objective and non debatable as possible. A simple criterion could be anyone who has commit rights (in trunk, not just in a sandbox or customer branch). There are currently 56 SVN committers. That could be strengthened with a minimum number of commits/lines changed during a period, but we perhaps don't need that level of complexity. We could possibly also extend that to entities that provide public support to users through gdal-dev or other public forums (gis.stackexchange, others?). Other suggestions ? Should we distinguish several categories of actors ? - QGIS makes a division between "Core contributors" vs "Contributors". GeoServer has "Core contributors", "Experienced providers" and "Additional services" (the last one is populated on service provider request). - On the other side, deegree, Geomoose or Geotools simply list them in a single section. The answer likely depends on the number of organizations that would be listed (I guess below 10 we don't need much structure). The difficulty here would be to establish the categories and criteria. So, could entities interested in being listed reply to this email so we can have a better idea of how many would be listed, and if we need more stricter criteria or several categories ? As far as I'm concerned, Spatialys would be interested. Best regards, Even [1] Non exhaustive list of OSGeo projects with a commercial support section : http://geoserver.org/support/ http://www.geomoose.org/info/commercial_support.html http://docs.geotools.org/latest/userguide/welcome/support.html http://wiki.deegree.org/deegreeWiki/GettingSupport http://qgis.org/en/site/forusers/commercial_support.html [2] OSGeo Service Provider catalog with entities declaring GDAL expertise : http://www.osgeo.org/search_profile?SET=1&MUL_TECH[]=00013 -- Spatialys - Geospatia
Re: [gdal-dev] regarding DGN v8
Hello Shubham, DGN v 8 is a completely different format; it's a derivative of Autodesk DWG even if the dgn extension stays the same. There are "open" libraries developed by Open Design Alliance ( http://www.opendesign.com). They are not really open source, they disclose some information for developers and there are free (as in free beer) libraries and converters/viewers. Some true open source library has already been developed in java (for DWG - see Orbis CAD), but I have never seen anything for DGN 8. Sorry. c > Message: 1 > Date: Mon, 19 Aug 2013 12:05:09 +0530 > From: "Shubham Dhabhai" > To: > Subject: [gdal-dev] regarding DGN v8 > Message-ID: <000101ce9ca6$412b6430$c3822c90$@vizexperts.com> > Content-Type: text/plain; charset="us-ascii" > > Hi > > I have to use DGN v8 .OGR supports DGN v7 but not DGN v8 so I was > wondering if there is some way to extend OGR so that it can support the DGN > v8 files. If not ,can anyone suggest some other library for DGN > v8(preferably open source) > > > > Regards ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hillshading to vector
Thanks a lot, Roger, it worked like a charm, just fiddling a little with parameters and than run it in python. It's really magic, I struggled with this question for two days before writing to the list. I think that instead of making another script you could add it as an option to gdal_contour.py and use it alternatively with -l (default) or -p (output to polygons). By the way, another enhancement for gdal_contour could be adding an options to cut the output with a line or polygon layer (say the shoreline or other boundary). c c > > On Wed, Jul 3, 2013 at 8:04 PM, Roger Veciana i Rovira > wrote: > >> Hi, I was just working on that. >> I think that you need a script like gdal_contour, but creatig polygons >> instead of lines. The algorithm used is Marching Squares. >> You can see the code, without explanation, here: >> https://github.com/rveciana/geoexamples/tree/master/python/raster_isobands >> In some weeks I'll add some more info in a README file and transform the >> file into a working script, not just a function. But you can use it just >> changing the file name and the intervals. >> >> Roger >> > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] hillshading to vector
Hello, gdaldem makes a very good work and gdal_polygonize.py too, but the combination is not so effective. Is there a way to obtain smooth polygons representing shaded areas as it's possible with Arc? When using a dem, you get polygons for pixels. Yes you can dissolve them, but you still have jagged boundaries. I even tried to get contours from hillshading, but obviously I get only polylines sometimes not useful to be transformed into polygons. Is there a way to get smooth polygons from gdal_polygonize or polygons from gdal_contour? -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel. +39(0)10 2475439 fax +39(0)10 2475439 gsm:+39 393 1590711 e-mail: berte...@charta.acme.com http://www.charta.acme.com -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ocr(opus) and ogr
hello, I had a fairly clean map with street codes, a very good candidate for optical character recognition, so I tried to recognize it with some of the available ocr engines and applications, just to try what if. To my surprise, ocropus (https://code.google.com/p/ocropus/) got something useful. It's output is an xhtml file with pixel based *coordinates* (may I add some exclamative marks here?). Here is an example: ‹span class="ocr_line" title="bbox 6309 5042 6465 5085"›506V‹/span› I hope I could do something with it. One great thing could be writing a specialized ocroscript (which is the command ocropus uses). Ocropus is written in python, so it shouldn't be impossible. But even with search and replace I could obtain a reasonable csv/xml file. The problem is still having to deal with pixel based coordinates. I think this could be solved with some proj magic, to feed it to ogr2ogr and voilà... Being able to deal with pixel based coordinates could enable us to use basic raster to vector conversion, which is not unuseful. Could someone help me? c -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel. +39(0)10 2475439 fax +39(0)10 2475439 gsm:+39 393 1590711 -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Erosive pyramids again
Hello, some time ago I complained with this list, asking for a better algorithm for black and white and paletted raster maps. While you scale the image, smaller black lines become thinner and thinner, scaling to half size usually works without data loss but further size reductions result into severe data loss. I suggested introducting an "erose" option as to make thin lines become fatter while reducing size. Evaluating the consequences of the proposal, Even Rouault suggested this was not a task for GDAL, but a user level choice to be provided by QGis or other programs. This is true, well known and expensive proprietary map-something show antialised raster layers without any special effort, but at the expense of huge computational requests. Now, making pyramids should substantially reduce this burden, but without severe data loss. Obviously, Even is right, client programs should design a better strategy to deal with line art and paletted maps, they could take into account a near scale pyramid and an higher resolution one to draw antialised layers in a slower rendition (this approach could be user selectable or automatical, based on raster type), but it's still true that GDAL should do its part not to lose data. And that happens without any choice by the user than to avoid pyramids. Could we do something better? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Help from MapInfo users, please
I don't understand the question (you didn't put any question in your message), but I tried the mif/mid files provided. The first time I got an error: "Not enough CoordSys parameters specified for projection 8." (which means State plane 1983). You provided this: CoordSys Earth Projection 8, 74, 'm', -87.5, 30.0, 0.33, 60, 0 but you should also put the coordinate bounds. This is the string that MapInfo puts in the header of a mif file with the same coordinate system: CoordSys Earth Projection 8, 33, "m", -87.5, 30, 0.33, 60, 0 Bounds (-7648594.01042, -13321190.9883) (8848594.01042, 6681406.87453) When you add bounds to your file, it can be imported without any fault. Almost all necessary for any coordinate system is found inside a file (MAPINFO.PRJ) provided with MapInfo, You could get a copy installing the latest version of MI from testdrive.mapinfo.com. Just let me know if this is the question and my answer fits it. c ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: OGR SQL Parser/Evaluator Overhaul
Thank you very much to you, Frank, and Camp To Camp. This is a very
welcome addition for file based datasources.
GDAL is becoming more and more powerful, versatile, useful and ... big.
Maybe you could add a
-straight
clause so to avoid the parser. GDAL/OGR shoud remain fast when used
only as a conversion library.
c
on Sun, 01 Aug 2010 20:03:05 Frank Warmerdam wrote:
> Subject: [gdal-dev] OGR SQL Parser/Evaluator Overhaul
>
> Folks,
>
> With the support of Camp To Camp I have been working on an overhaul for the
> OGR SQL parsing engine. The minimum goal was to support functions in the
> column definitions for the output record set of a SELECT, but in order to
> achieve this in a reasonable way I have worked towards a substantial
> generalization of expression in OGR SQL and extending them to column
> definitions.
>
> I have written up a preliminary RFC for review at:
>
> http://trac.osgeo.org/gdal/wiki/rfc28_sqlfunc
>
> I am seeking feedback before I polish it off and call for a vote this
> week.
>
> I will note that in my local development tree I now have this overhauled
> implementation working, including the autotest/ogr/{ogr_join_test.py,
> ogr_sql_test.py,ogr_index_test.py} test scripts all passing without
> alteration.
>
> Best regards,
--
--
Carlo A. Bertelli
Charta servizi e sistemi per il territorio e la storia ambientale srl
Dipendenze del palazzo Doria,
vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)
tel. +39(0)10 2475439 fax +39(0)10 2475439 gsm:+39 393 1590711
e-mail: berte...@charta.acme.com http://www.charta.acme.com
--
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] WMS overlapping tiles
Hello, JOSM wms and the fairly simplistic Grass r.in.wms allow tile overlapping which is sometimes very useful when checking map consistency and trying to spot digitizing errors. I didn't find this option nor in the xml definition nor in gdal_translate. I imagine it could be feasible with an appropriate combination of gdal_translate e and gdalretile.py, but... Do someone have any suggestion about it? c ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR: Accessing ESRI Personal Geodatabase on OS X
Hello, maybe a solution may be found at a lower level, using gdal java bindings with Jackcess (http://jackcess.sourceforge.net/), the library behind mdb-sqlite. This could be a simpler solution for all platforms besides Windows. c On Fri, 25 Jun 2010 16:06:48 William Kyngesburye wrote: > PGeo support depends on a working ODBC driver for MDB databases. On Linux, > this is done with mdbtools. I have not been able to get this working on OS X > with the system iODBC (I last looked at it a year ago). It compiles (with > some hackery), but does not load. I haven't tried mdbtools with UnixODBC, > mainly because I prefer to use stuff available from the system, and UnixODBC > is a large project. Maybe if I can whittle it down to a bare minimum needed > for mdbtools (and assuming it works), I could bundle it in the GDAL framework. > > There is a commercial Actual Access iODBC driver (apparently it's derived > from mdbtools), but it corrupts binary data when reading. I've reported this > to the developers, and pestered them, but so far they haven't been able to > fix it. > > One alternative option that I haven't followed up on yet (mainly lack of C++ > skills, also lack of need) is to convert the mdb to sqlite with the > mdb-sqlite java tool (http://code.google.com/p/mdb-sqlite/), then write a > custom pgeo driver that reads the pgeo data from sqlite instead of ODBC/MDB. > This wouldn't mirror the pgeo driver exactly as a feature (requires a > separate external step), but it's _something_. > > On Jun 25, 2010, at 2:58 PM, Bob Cave wrote: > >> >> Hello, >> >> I see that OGR supports reading ESRI Personal Geodatabases. We are >> considering adding this capability to our product, which has both Windows >> and Mac OS X implementations. I have tried the basic functionality on >> Windows (using FW_Tools), and the OGR documentation has instructions for >> using the reader on Linux, but I don't see any information about OS X. Has >> anyone used it on OS X? If so, what were the major issues that needed to be >> resolved? >> >> Thanks, >> >> Bob >> -- >> View this message in context: >> http://osgeo-org.1803224.n2.nabble.com/OGR-Accessing-ESRI-Personal-Geodatabase-on-OS-X-tp5223574p5223574.html >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > - > William Kyngesburye > http://www.kyngchaos.com/ > > All generalizations are dangerous, even this one. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Stop gdalladdo eating fillets
Hallo, I have a set of very detailed b&w needing an overlay. But when I run gdaladdo, no matter what option I choose, fillets are spitefully deleted. I don't know if there is a better solution, I tried to get a thicker trace on a copy of the original image, make the pyramids and rename the resulting file. To make the fillets grow I used ImageMagick, like this convert -blur 3 -threshold 20 ORIGINAL.tif THICKER.tif (the treshold is less than 50 because the original image is white on black) gdaladdo --config COMPRESS_OVERVIEW DEFLATE -r average --config INTERLEAVE_OVERVIEW PIXEL --config NODATA 0 -ro THICKER.tif 2 4 8 16 than I renamed THICKER.tif.ovr as ORIGINAL.tif.ovr. Well, it doesn't work well, I should have made a thicker version while I was reducing the image. There is always a size where fillets disappear. The problem seems to ask for a resize method that keeps the thickness of the lines while reducing the objects. There should be a procedure like mine but carefully adapted to any scale reduction. Am I missing something or this is really a problem? Carlo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] pre-rectifying to georeference old maps
Hello, dealing with old maps which have to be georeferenced we are not able to solve a problem: sometimes old (very old, 18th or even 17th century maps) cannot be scanned flat or may only be photographed. This leads to bending, shading and so on. The margins of the map become curved and the light uneven, not to talk about maps which were conservated in albums: the center fold is deeply shaded and aroud it the curved paper shines. Researchers developed image recognition techniques to solve this problems for book reproductions (I have refereces, if someone is interested) but those need to have informations on light directions and so on (they use shade to detect shape); this technique is mainly useful for scanned images. In the old times, I remember using Bentley's IRAS/C to solve a simpler issue (a curved map), by now I think gdalwarp would possibly solve deformation problems -- but how to set data to make it run properly in this case, I cannot imagine how to use it without a GUI to set points, maybe a vector polygon to set the deformation. An this would only be good for shape, not for shade (surely useful but not perfect). Any suggestion is gratefully accepted. c -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel. +39(0)10 2475439 fax +39(0)10 2475439 gsm:+39 393 1590711 e-mail: berte...@charta.acme.com http://www.charta.acme.com -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
