Opened 18 years ago
Last modified 18 years ago
#1220 closed defect (fixed)
OGR SHP2DGN translation bug
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | OGR_SRS | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
Hello, I writed this .BAT to translate SPH to DGN: call C:\Programmi\FWTools1.0.0a7\setfw.bat ogr2ogr -skipfailures -f "DGN" -lco "C:\Programmi\FWTools1.0.0a7\data\seed_3d.dgn" exported.dgn %1 and, it works. But, the produced "exported.dgn" is wrong, for MicroStation SE, that reports the message panel: "End of file missing, attempt repair ?" at startup, and there is no way to open it. Instead, ArcExplorer2.0 opens it. If needed, I can send you my example files (tell me how and where :-) ) Thank you in advance for help Best Regards Roberto Angeletti (gis-vrml-kml programmer)
Attachments (2)
Change History (9)
by , 18 years ago
Attachment: | OgrShp2DgnBug.zip added |
---|
comment:1 by , 18 years ago
Eureka ! I found the problem. The two DGN seed files in the directory: C:\Programmi\FWTools1.0.0a7\data\ are corrupted ! I changed them with other working DGN, and problem is FIXED. But, please, control the SEEDs in the installer ! Best Regards Roberto Angeletti (gis-vrml-kml programmer)
comment:2 by , 18 years ago
Roberto, Sorry for your unnecessary pain. I discovered the 2d dgn seed file was not kept in CVS marked as binary, so it was going through cr/lf translation when pulled out on windows. I have corrected this, and the next fwtools release will be fixed. I also added a test to my regression tests for writing via the dgn driver that should point out probems like this. Thanks!
comment:3 by , 18 years ago
Hello Frank, I found another problem in Ogr2ogr, converting Shp2dgn. As you can see in the attached image, the WorkingUnits parameters from Seed file, are then reversed in converted file ! Could you, please, control this, also ? :-) Best Regards Roberto Angeletti (gis-vrml-kml programmer)
comment:4 by , 18 years ago
Roberto, What ogr2ogr commandline are you using? Looking in the code, it seems that units should be copied from the seed file properly *if* you specify a seed file using the SEED= layer creation option. But if not, we don't use the default seed files's units. Instead internal programmatic units are used which happen to be the ones you are seeing. I have fixed the internal defaults to use 1UOR = 1 cm, and 1m = 100cm since the current defaults of 100UOR = 1cm and 1m = 1cm is crazy. But in general if you want to force seed units to be copied from a seed you need to explicitly select the seed. This arrangement was mostly done because we override the seed units in the case of geographic coordinate systems.
comment:5 by , 18 years ago
Hello Frank, this is my .BAT : -------------------------------- call C:\Programmi\FWTools1.0.0a7\setfw.bat ogr2ogr -skipfailures -f "DGN" -lco "SEED=c:\gis\seed\topeye3d.dgn 3D=YES" exported.dgn %1 -------------------------------- and mine is a 3D seed with resolution 100 cm Per m and 1 Pos Units Per cm. That parameters are needed in my other applications. Thanks and Best Regards Roberto Angeletti (gis-vrml-kml programmer)
comment:6 by , 18 years ago
Hello again, Frank. I discovered (my) problem. I wronged "something" in the command line. -lco "SEED=c:\gis\seed\topeye3d.dgn 3D=YES" has no meaning. Instead, now I use: ogr2ogr -skipfailures -f "DGN" -dsco "SEED=c:\gis\seed\topeye3d.dgn" c:\gis\exported.dgn %1 that does what I need. Sorry, but documentation is not so clear (expecially for me that don't read it !) :-) Thank you ! Best Regards Roberto Angeletti (gis-vrml-kml programmer)
comment:7 by , 18 years ago
On investigation if you had used: -lco SEED=c:\gis\seed\topeye3d.dgn -lco 3D=YES things would have worked ok, however, the 3D=YES option is already forced by the selected seed so you are right, it was unnecessary. And the driver is setup such that "datasource creation options" are essentially used for each layer created, so there is no problem using either -lco or -dsco for this driver. This is not typically the case.
Note:
See TracTickets
for help on using tickets.
OgrShp2DgnBugFiles