Open ssokol opened 2 years ago
Got a bit further by fixing the issue with the stream count function. Apparently something has changed in the way mutool works. I was able to get the number of streams by revising the function as:
sub getNumberOfStreams {
#Get number of objects/streams in the targetpdf
my $_mutoolShowOutput = qx(mutool show $main::targetPdf trailer/Size);
if ($debug) {
say "mutools show output: " . $_mutoolShowOutput;
}
my $retval = $? >> 8;
die "No output from mutool show. Is it installed? Return code was $retval"
if ( $_mutoolShowOutput eq "" || $retval != 0 );
my $_objectstreams;
foreach my $line ( split /[\r\n]+/, $_mutoolShowOutput ) {
## Regular expression magic to grab what you want
if ($debug) {
say "Line: " . $line;
}
if ($line =~ /^(\d+)$/ ) {
$_objectstreams = $1;
}
if ( $line =~ /^(\d+)\s+(\d+)$/ ) {
$_objectstreams = $2;
}
}
if ($debug) {
say "Object streams: " . $_objectstreams;
}
return $_objectstreams;
}
Once that was fixed, it was able to create the .vrt files. I'm not seeing where it updated the PDF with the corner information, but perhaps it never did that?
Hi @ssokol
I beleive your issue is similar to the one I opened some years ago.
https://github.com/jlmcgraw/GeoReferencePlates/issues/2
In one of my comments I also mention the regex that does not seem to be matching anymore.
Unfortunately I gave up on trying to fix it and it seems @jlmcgraw is not maintaining this repo anymore.
Hi @JanC
I have not run a full test, but the fix I added to getNumberOfStreams()
seems to have made it work properly for me. It is now finding the ground control points and creating the .vrt files as expected. I suspect it is able to use data from the streams rather than from the raw text dump (not sure - have not dug that far into it).
I'll run a full test later today and if it works I'll fork the repo and post the fixed version. At some point it might be fun to recreate this in some more modern language - either Go (my current go-to) or Python.
Cheers,
-S
that's great!
Yeah a Python would be definitely more maintainable but I think that would be a lot a work
Just ran a limited test on US FAA airport diagrams for the state of Texas (where I'm based). With my changes to the getNumberOfStreams()
function the georeference_airport_diagrams_via_db.pl script works with a number of exceptions:
It fails on files that do not contain text information. So far as I've found, these are all plates provided by the US military for military-only or joint-use airports. The files generally contain the necessary information in raster form (i.e. in the "image" component of the .pdf) but not in metadata. The files also do not contain discrete streams with the necessary line and icon data. It may be possible to manually georeference, but I've not done any testing to see if these are to scale.
It fails on files in which the diagram is rotated to fit (i.e. where the diagram is a landscape image). The georeference process appears to work properly. The system identifies control points and is able to generate the .vrt files. However, the check process fails the result. I've not checked (yet) to see if the output could still be used with just a change in the order of the corner values.
It occasionally (only once that I found) fails when it is not able to find enough control points. The APD for AUS (Austin Bergstrom Intl.) failed this way and I was able to correct it by manually adding a control point.
Given my requirements, I don't need to worry about the exclusively military airports as my users won't be landing there except in emergency situations (and in those cases, they can probably get progressive taxi assistance). The cases I do need to address are the few joint-use airports (i.e. airports that are shared by a civil operator and a military operator), the failures due to orientation, and the oddball failures due to control point capture issues.
Fortunately, airport diagrams don't change all that often. The few that won't automatically process can be reviewed quickly enough for changes.
Hi Jesse,
Sorry to bother you with this, but my regex skills are almost nonexistent, my limited perl experience is 20 years out of date, and I seem to have run into a change in the format of the text in the airport diagram PDF documents that has broken the georeference system.
Both
findLatitudeTextBoxes2
andfindLongitudeTextBoxes2
are failing to find the required text. My assumption is that the FAA made some slight change in how it encodes the values which has broken the regexs that do the hard work here. I've included the debug output for one chart (it's for KGTU - Georgetown Municipal in Georgetown Texas). Any idea what need to be changed to find the text and the lines?Here are the lines that should work:
I'm not sure when the FAA changed things up - I'm just now starting to add charts and plates to my stuff. I greatly appreciate any pointers to get this working.
Best Regards,
Steve