I only changed the focal length to 207 mm, and I don't see any problem with the result:
http://turingmachine.org/~dmg/temp/rip2.jpg --dmg On Mon, Dec 6, 2010 at 2:29 AM, Olivier Croquette <[email protected]> wrote: > Thanks for the numerous answers. I didn't know Bruno's tutorial yet, > so I tried to follow it. I came a bit further, but it actually didn't > solve this unusual problem. To make it clear what it is, I have put > some sample maps online. > > They come from the french cadastre. The limits between the different > areas within a town (AI and AK in the sample) are typically > geographical features (river, road...) or property borders. There is > no overlapping between the maps of the different areas, only common > borders. > > The goal is too load this data in JOSM, the editor for OpenStreetMap. > I can already load the single sheets in JOSM, and I also geo- > referenced them one by one. But the georeferencing is not perfect, and > I have discrepancies of several meters at many borders. > My idea is now to stitch first the single maps in a bigger one, that I > then georeference, leading to full consistency within the big map > (e.g. the town). > > Here are 2 sheets (among the 24) : > http://ocroquette.fr/a/hugin/ > > I don't think stitching the pictures will work, because of : > > - the size : for this town, there are 24 sheets, about 3000x3000, e.g. > the final map will have at least 200 Megapixels > - transparency : original files are transparent PNG, and the > overlapping areas do not contain information that is blend-able > (typically, a piece of map of a sheet overlaps with metadata or border > lines of another sheet), so I would need support for transparency as > input and output > > So trying to stitch them as a panorama is the bad approach. I am now > thinking about just using the GUI to create control points and the > PTOptimizer to optimize the georeferencing. Hugin makes it easy with > the "Edit script before optimizing" button in the Optimize panel. I > have copied the script to a file, and I ran PTOptimizer on it. While > the input format is well documented (http://wiki.panotools.org/ > PTOptimizer), the output is not. > > Sample lines : > o f0 r0 p0 y0 v10 a0.000000 b0.000000 c0.000000 g0.000000 t0.000000 > d0.000000 e0.000000 u10 -buf > o f0 r67.3424 p0 y0 v13.6204 a0.000000 b0.000000 c0.000000 g0.000000 > t0.000000 TrX0.066214 TrY-0.033346 TrZ-0.265726 d0.000000 e0.000000 > u10 +buf > C i0 c0 x1704.48 y532.368 X1704.25 Y532.207 D0.561154 Dx0.459291 > Dy0.322407 > C i1 c0 x1704.02 y532.046 X1704.25 Y532.207 D0.561154 Dx0.459291 > Dy0.322407 > > I will now dive into this and see how I can integrate it in my > existing OSM workflow. If anyone has some documentation about the > output of PTOptimizer, I would be glad to see it and add it to the > Wiki. > > Thanks all for your help ! > > Best regards > > Olivier > > -- > You received this message because you are subscribed to the Google Groups > "Hugin and other free panoramic software" group. > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at http://groups.google.com/group/hugin-ptx > > -- --dmg --- Daniel M. German http://turingmachine.org -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
