[GRASS-user] writing MicroStatioin DGN files

gisfisch · January 12, 2024, 9:07am

Hello list,

I try to write MicroStation V7 DGN files in GRASS 7.8.7. using v.out.ogr.

The same has been working for me without problems since years in GRASS 7.0.

Now I get the following messages:

v.out.ogr -s input=mymap@tempwork output=C:\Users\Documents\mydgn.dgn format=DGN

ERROR 6: CreateField() not supported by this layer.

ERROR: Unable to create column

The DGN file is created, but there are no data written to it.

Please help, because writing those files is critical for my workflow.

Thank you and best regards, Uwe

neteler · January 12, 2024, 5:13pm

On Fri, Jan 12, 2024 at 10:12 AM gisfisch--- via grass-user
<grass-user@lists.osgeo.org> wrote:

Hello list,

I try to write MicroStation V7 DGN files in GRASS 7.8.7. using v.out.ogr.

The same has been working for me without problems since years in GRASS 7.0.

Now I get the following messages:

v.out.ogr -s input=mymap@tempwork output=C:\Users\Documents\mydgn.dgn format=DGN

ERROR 6: CreateField() not supported by this layer.
ERROR: Unable to create column <Type>

The DGN file is created, but there are no data written to it.

Please help, because writing those files is critical for my workflow.

I have made a test with the North Carolina sample dataset:

GRASS nc_spm_08_grass7/user1:~ >
v.out.ogr input=roadsmajor type=line output=/tmp/roadsmajor.dgn format=DGN --o
ERROR 6: CreateField() not supported by this layer.

ERROR: Unable to create column <cat>

==> so, add -s flag to supress "cat".

v.out.ogr input=roadsmajor type=line output=/tmp/roadsmajor.dgn
format=DGN --o -s
ERROR 6: CreateField() not supported by this layer.

ERROR: Unable to create column <MAJORRDS_>

Apparently that column is also disliked.

Googling shows:
https://lists.osgeo.org/pipermail/gdal-dev/2006-February/008089.html
"The CreateField() messages are expected with DGN output. The
DGN format has a fixed schema and doesn't support user defined
fields.
"

Looking further in the OGR DGN driver docs shows:
https://gdal.org/drivers/vector/dgn.html

"Creation Issues

2D DGN files may be written with OGR with significant limitations:

- Output features have the usual fixed DGN attributes. Attempts to
create any other fields will fail.
- ...
- A seed file must be provided (or if not provided,
$PREFIX/share/gdal/seed_2d.dgn will be used). Many aspects of the
resulting DGN file are determined by the seed file, and cannot be
affected via OGR, such as initial view window.
- ...
"

I assume that in your case the attribute table names need to follow
this fixed DGN attributes scheme.

HTH,
Markus

--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://neteler.org/blog

gisfisch · January 12, 2024, 11:32pm

Markus,

thank you very much for your answer.
In your example, you used any GRASS map with any columns. They can obviously not be written to DGN (eg. MAJORRDS_).
Please note that in my workflow, the DGN is imported into GRASS, then processed and then written back. So the GRASS map must have the correct DGN colums because it was created from DGN by GRASS itself.
When I import a DGN and use db.select right after that, I get:

cat|Type|Level|GraphicGroup|ColorIndex|Weight|Style|EntityNum|MSLink|Text|ULink
1|17|1|0|2|2|0|||423|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0871", "0x0000" ], "type": "ODBC" } ] }
2|17|1|0|2|2|0|||424|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0872", "0x0000" ], "type": "ODBC" } ] }
3|17|1|0|2|2|0|||426|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0873", "0x0000" ], "type": "ODBC" } ] }

Then, when I use v.out.ogr -s to skip the cat column, the driver complains about the Type column. But that one is undoubtedly part of the fixed DGN schema, as you can see above.
I understand that writing any random colums can not work, but I try to write exactly the DGN schema.

Please let me emphasize again that it worked fine for years in GRASS 7.0.
I assume there is a bug in the younger GRASS versions. Or has anybody succeeded in writing out DGNs?

Best regards, Uwe

-----Ursprüngliche Nachricht-----
Von: Markus Neteler <neteler@osgeo.org>
Gesendet: Freitag, 12. Januar 2024 18:14
An: gisfisch@t-online.de
Cc: grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] writing MicroStatioin DGN files

On Fri, Jan 12, 2024 at 10:12 AM gisfisch--- via grass-user <grass-user@lists.osgeo.org> wrote:

Hello list,

I try to write MicroStation V7 DGN files in GRASS 7.8.7. using v.out.ogr.

The same has been working for me without problems since years in GRASS 7.0.

Now I get the following messages:

v.out.ogr -s input=mymap@tempwork output=C:\Users\Documents\mydgn.dgn
format=DGN

ERROR 6: CreateField() not supported by this layer.
ERROR: Unable to create column <Type>

The DGN file is created, but there are no data written to it.

Please help, because writing those files is critical for my workflow.

I have made a test with the North Carolina sample dataset:

GRASS nc_spm_08_grass7/user1:~ >
v.out.ogr input=roadsmajor type=line output=/tmp/roadsmajor.dgn format=DGN --o ERROR 6: CreateField() not supported by this layer.

ERROR: Unable to create column <cat>

==> so, add -s flag to supress "cat".

v.out.ogr input=roadsmajor type=line output=/tmp/roadsmajor.dgn format=DGN --o -s ERROR 6: CreateField() not supported by this layer.

ERROR: Unable to create column <MAJORRDS_>

Apparently that column is also disliked.

Googling shows:
https://lists.osgeo.org/pipermail/gdal-dev/2006-February/008089.html
"The CreateField() messages are expected with DGN output. The DGN format has a fixed schema and doesn't support user defined fields.
"

Looking further in the OGR DGN driver docs shows:
https://gdal.org/drivers/vector/dgn.html

"Creation Issues

2D DGN files may be written with OGR with significant limitations:

- Output features have the usual fixed DGN attributes. Attempts to create any other fields will fail.
- ...
- A seed file must be provided (or if not provided, $PREFIX/share/gdal/seed_2d.dgn will be used). Many aspects of the resulting DGN file are determined by the seed file, and cannot be affected via OGR, such as initial view window.
- ...
"

I assume that in your case the attribute table names need to follow this fixed DGN attributes scheme.

HTH,
Markus

--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software https://grass.osgeo.org https://neteler.org/blog

neteler · January 14, 2024, 12:45pm

Uwe,

On Sat, Jan 13, 2024 at 12:38 AM <gisfisch@t-online.de> wrote:

Markus,

thank you very much for your answer.
In your example, you used any GRASS map with any columns. They can obviously not be written to DGN (eg. MAJORRDS_).

I see - I am not familiar with the DGN format.

Please note that in my workflow, the DGN is imported into GRASS, then processed and then written back. So the GRASS map must have the correct DGN colums because it was created from DGN by GRASS itself.
When I import a DGN and use db.select right after that, I get:

cat|Type|Level|GraphicGroup|ColorIndex|Weight|Style|EntityNum|MSLink|Text|ULink
1|17|1|0|2|2|0|||423|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0871", "0x0000" ], "type": "ODBC" } ] }
2|17|1|0|2|2|0|||424|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0872", "0x0000" ], "type": "ODBC" } ] }
3|17|1|0|2|2|0|||426|{ "32047": [ { "size": 8, "raw": [ "0x1003", "0x7d2f", "0x0873", "0x0000" ], "type": "ODBC" } ] }

Then, when I use v.out.ogr -s to skip the cat column, the driver complains about the Type column. But that one is undoubtedly part of the fixed DGN schema, as you can see above.
I understand that writing any random colums can not work, but I try to write exactly the DGN schema.

Please let me emphasize again that it worked fine for years in GRASS 7.0.

GRASS GIS 7.0 was from Feb 20, 2015 A lot has happened since then.

I assume there is a bug in the younger GRASS versions. Or has anybody succeeded in writing out DGNs?

Note that GRASS GIS is offloading the write-out of the data to
GDAL/OGR. Does ogr2ogr conversion work with your data and a recent
GDAL version?

Overall: the only reasonable way to find out is - since we don't have
your data - to create a reproducible example with e.g. the North
Carolina sample data (essentially what I tried not knowing your
workflow).
Could you provide that?

Best regards,
Markus

gisfisch · January 15, 2024, 6:32am

Markus,

thanks again. I will try the export using ogr2ogr directly and let you know if that works.

best regards, Uwe

-----Ursprüngliche Nachricht-----
Von: Markus Neteler <neteler@osgeo.org>
Gesendet: Sonntag, 14. Januar 2024 13:45
An: gisfisch@t-online.de
Cc: grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] writing MicroStatioin DGN files

Uwe,

On Sat, Jan 13, 2024 at 12:38 AM <gisfisch@t-online.de> wrote:

Markus,

thank you very much for your answer.
In your example, you used any GRASS map with any columns. They can obviously not be written to DGN (eg. MAJORRDS_).

I see - I am not familiar with the DGN format.

Please note that in my workflow, the DGN is imported into GRASS, then processed and then written back. So the GRASS map must have the correct DGN colums because it was created from DGN by GRASS itself.
When I import a DGN and use db.select right after that, I get:

cat|Type|Level|GraphicGroup|ColorIndex|Weight|Style|EntityNum|MSLink|Text|ULink
1|17|1|0|2|2|0|||423|{ "32047": [ { "size": 8, "raw": [ "0x1003",
1|17|1|0|2|2|0|||423|"0x7d2f", "0x0871", "0x0000" ], "type": "ODBC" }
1|17|1|0|2|2|0|||423|] }
2|17|1|0|2|2|0|||424|{ "32047": [ { "size": 8, "raw": [ "0x1003",
2|17|1|0|2|2|0|||424|"0x7d2f", "0x0872", "0x0000" ], "type": "ODBC" }
2|17|1|0|2|2|0|||424|] }
3|17|1|0|2|2|0|||426|{ "32047": [ { "size": 8, "raw": [ "0x1003",
3|17|1|0|2|2|0|||426|"0x7d2f", "0x0873", "0x0000" ], "type": "ODBC" }
3|17|1|0|2|2|0|||426|] }

Then, when I use v.out.ogr -s to skip the cat column, the driver complains about the Type column. But that one is undoubtedly part of the fixed DGN schema, as you can see above.
I understand that writing any random colums can not work, but I try to write exactly the DGN schema.

Please let me emphasize again that it worked fine for years in GRASS 7.0.

GRASS GIS 7.0 was from Feb 20, 2015 A lot has happened since then.

I assume there is a bug in the younger GRASS versions. Or has anybody succeeded in writing out DGNs?

Note that GRASS GIS is offloading the write-out of the data to GDAL/OGR. Does ogr2ogr conversion work with your data and a recent GDAL version?

Overall: the only reasonable way to find out is - since we don't have your data - to create a reproducible example with e.g. the North Carolina sample data (essentially what I tried not knowing your workflow).
Could you provide that?

Best regards,
Markus

gisfisch · January 16, 2024, 10:11am

Markus,

the conversion to DGN works fine with OGR2OGR (using a GPKG as intermediate format, that means the data go DGN -> GRASS -> GPGK -> DGN).
No error messages, result looks fine, even the DGN symbology is preseved as desired.
That means, the problem must be in GRASS. How to solve?

best regards, Uwe

-----Ursprüngliche Nachricht-----
Von: Markus Neteler <neteler@osgeo.org>
Gesendet: Sonntag, 14. Januar 2024 13:45
An: gisfisch@t-online.de
Cc: grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] writing MicroStatioin DGN files

Uwe,

On Sat, Jan 13, 2024 at 12:38 AM <gisfisch@t-online.de> wrote:

Markus,

thank you very much for your answer.
In your example, you used any GRASS map with any columns. They can obviously not be written to DGN (eg. MAJORRDS_).

I see - I am not familiar with the DGN format.

Please note that in my workflow, the DGN is imported into GRASS, then processed and then written back. So the GRASS map must have the correct DGN colums because it was created from DGN by GRASS itself.
When I import a DGN and use db.select right after that, I get:

cat|Type|Level|GraphicGroup|ColorIndex|Weight|Style|EntityNum|MSLink|Text|ULink
1|17|1|0|2|2|0|||423|{ "32047": [ { "size": 8, "raw": [ "0x1003",
1|17|1|0|2|2|0|||423|"0x7d2f", "0x0871", "0x0000" ], "type": "ODBC" }
1|17|1|0|2|2|0|||423|] }
2|17|1|0|2|2|0|||424|{ "32047": [ { "size": 8, "raw": [ "0x1003",
2|17|1|0|2|2|0|||424|"0x7d2f", "0x0872", "0x0000" ], "type": "ODBC" }
2|17|1|0|2|2|0|||424|] }
3|17|1|0|2|2|0|||426|{ "32047": [ { "size": 8, "raw": [ "0x1003",
3|17|1|0|2|2|0|||426|"0x7d2f", "0x0873", "0x0000" ], "type": "ODBC" }
3|17|1|0|2|2|0|||426|] }

Then, when I use v.out.ogr -s to skip the cat column, the driver complains about the Type column. But that one is undoubtedly part of the fixed DGN schema, as you can see above.
I understand that writing any random colums can not work, but I try to write exactly the DGN schema.

Please let me emphasize again that it worked fine for years in GRASS 7.0.

GRASS GIS 7.0 was from Feb 20, 2015 A lot has happened since then.

I assume there is a bug in the younger GRASS versions. Or has anybody succeeded in writing out DGNs?

Note that GRASS GIS is offloading the write-out of the data to GDAL/OGR. Does ogr2ogr conversion work with your data and a recent GDAL version?

Overall: the only reasonable way to find out is - since we don't have your data - to create a reproducible example with e.g. the North Carolina sample data (essentially what I tried not knowing your workflow).
Could you provide that?

Best regards,
Markus

neteler · January 22, 2024, 7:47am

Uwe,

On Tue, Jan 16, 2024 at 11:11 AM <gisfisch@t-online.de> wrote:

Markus,

the conversion to DGN works fine with OGR2OGR (using a GPKG as intermediate format, that means the data go DGN -> GRASS -> GPGK -> DGN).
No error messages, result looks fine, even the DGN symbology is preseved as desired.
That means, the problem must be in GRASS. How to solve?

As already said:

On Sun, Jan 14, 2024 at 1:45 PM Markus Neteler <neteler@osgeo.org> wrote:

Overall: the only reasonable way to find out is - since we don't have
your data - to create a reproducible example with e.g. the North
Carolina sample data (essentially what I tried not knowing your
workflow).
Could you provide that?

Best regards,
Markus