Support for reading User Data Linkage data using DGNv8/DWG vector drivers #3089

jgrocha · 2020-10-21T16:09:27Z

What does this PR do?

This PR enhances the DGN and DWG/DGN v8 drivers. It allows to read data from User Data Linkage. For a briefly introduction, check User Data Linkage.

In Microstation, user data linkage were used to add additional information to geographic features. The following print screen (From Microstation v8) shows the user data linkage information.

The MSLink data is already read by these drivers. We are adding the ability to read also the User Data Linkage.

Application ID

Each developer/company can use their own Application ID to store and retrieve this additional data, because each element can have multiple user data linkages, for different applications.

For example, the Portuguese former IPCC Institute uses the Application ID = 6549 (0x1995), as seen in the picture above. The data itself (encoded as integer values), are the domain, subdomain, family and object type.

Since we can have multiple Application ID, in this PR we use the environment variable DGN_ULINK_TYPE to select the Application ID to retrieve.

For the mentioned IPCC cartographic data, we use the following call:

DGN_ULINK_TYPE=6549 ogrinfo (...)

or

DGN_ULINK_TYPE=6549 ogr2ogr (...)

ogrinfo

With this PR, the additional User Data Linkage can be read by the driver:

DGN_ULINK_TYPE=6549 ogrinfo 454_1_10k_MNT.dgn elements | grep "OGRFeature(elements):3471$" -A 12
OGRFeature(elements):3471
  Type (Integer) = 4
  Level (Integer) = 48
  GraphicGroup (Integer) = 0
  ColorIndex (Integer) = 4
  Weight (Integer) = 0
  Style (Integer) = 0
  EntityNum (Integer) = 5
  MSLink (Integer) = 88010104
  ULink (IntegerList) = (5:2010105,2010106,2010107,12010601,88010104)
  Style = PEN(id:"ogr-pen-0",c:#cccc00)
  LINESTRING Z (-78782.36 -120470.3 8.76,-78781.16 -120470.04 8.76)

The meaning of the ULink list depends on the Application ID.

Check for User Data Linkage

Building ODA generates a tool than can be used to dump a DGN file to text.

cd ODA21.6/base_8.3/bin/lnxX64_8.3dll
./ExDgnDump 454_1_10k_MNT.dgn out.txt
grep "Attribute Linkages (" -B 1 -A 4 out.txt

    > OdDgLineString3d Path: */OdDgDatabase/OdDgModel/
      > Attribute Linkages (2 items)
        Primary ID = 0x1995, data size = 4
        Primary ID = 0x1995, data size = 4
      < Attribute Linkages
      Common information for DGN elements:

Example

The autotest/ogr/data/dgnv8/test_dgnv8.dgn has User Data Linkage defined and can be used for testing.
The Application ID is 22226 (0x56d2). Since we only address integer User Data Linkage, not all User Data Linkage of the test file can be recovered with this PR.

Limitation

This PR just covers the use case that we found. It addresses the usage of the 8 byte ULink length (4 words; first is always 0x1003; second Application ID, third and fourth are the data). The following image illustrates our use case:

More information about user data linkages.

If other uses cases are identified, they can be easily implemented on top of this PR.

Tasklist

Environment

OS: Ubuntu 20.04
Compiler: gcc/g++ 8.x
ODA support is required

Credits

The implementation was done by @pdiasalmeida from Geomaster, Lda

rouault · 2020-10-21T20:27:39Z

Instead of selecting the user link type, why not report all that are found as JSON, that is in a field of type OFTString and subtype OFSTJSON. Something like
ULink = { "6549" : [2010105,2010106,2010107,12010601,88010104] }

jgrocha · 2020-11-02T15:19:34Z

I've changed the user data link output to JSON, for DGN and DGNV8 drivers.

By default, user data links are not reported. If DGN_ULINK_TYPE to any value other than -1, user data links are reported.

Examples for IPCC Portugal user data link data

IPCC Portugal user data link data

DNGV8

DGN_ULINK_TYPE=0 GDAL_SKIP=DGN ./apps/ogrinfo 454_1_10k_MNT.dgn Default

OGRFeature(Default):3556
  Type (Integer) = 4
  Level (Integer) = 48
  GraphicGroup (Integer) = 0
  ColorIndex (Integer) = 4
  Weight (Integer) = 0
  Style (Integer) = 0
  ULink (String(JSON)) = { "6549": [ "02010105", "02010106", "02010107", "12010601", "88010104" ], "24162": [ { "tableId": 5, "MSLink": 88010104, "type": "ODBC" } 
] }
  Style = PEN(id:"ogr-pen-0",c:#cccc00)
  LINESTRING Z (-78783.55 -120470.57 8.76,-78782.36 -120470.3 8.76)

DGN driver

DGN_ULINK_TYPE=0 ./apps/ogrinfo 454_1_10k_MNT.dgn elements

OGRFeature(elements):3472
  Type (Integer) = 4
  Level (Integer) = 48
  GraphicGroup (Integer) = 0
  ColorIndex (Integer) = 4
  Weight (Integer) = 0
  Style (Integer) = 0
  EntityNum (Integer) = 5
  MSLink (Integer) = 88010104
  ULink (String(JSON)) = { "24162": [ { "raw": "0F810005ED78053E00000000", "type": "unknown", "size": 16 } ], "6549": [ "02010105", "02010106", "02010107", "120106
01", "88010104" ], "32047": [ { "raw": "D91E0004", "type": "ODBC", "size": 8 } ] }
  Style = PEN(id:"ogr-pen-0",c:#cccc00)
  LINESTRING Z (-78783.55 -120470.57 8.76,-78782.36 -120470.3 8.76)

Other examples

Example usage and output (DGNV8 driver)

Using the attachment provided on ticket 1387

DGN_ULINK_TYPE=0 GDAL_SKIP=DGN ./apps/ogrinfo franck_without_enhanced_precision.dgn Default

(...)
OGRFeature(Default):192
  Type (Integer) = 4
  Level (Integer) = 3
  GraphicGroup (Integer) = 0
  ColorIndex (Integer) = 3
  Weight (Integer) = 0
  Style (Integer) = 0
  ULink (String(JSON)) = { "24721": [ { "tableId": 33, "MSLink": 2406, "type": "Oracle" } ] }
  Style = PEN(id:"ogr-pen-0",c:#ff0000)
  LINESTRING (659699.081 216466.475,659669.489 216455.323)
(...)

Example usage and output (DGN driver)

DGN_ULINK_TYPE=0 ./apps/ogrinfo franck_without_enhanced_precision.dgn elements

OGRFeature(elements):38
  Type (Integer) = 4
  Level (Integer) = 3
  GraphicGroup (Integer) = 0
  ColorIndex (Integer) = 3
  Weight (Integer) = 0
  Style (Integer) = 0
  EntityNum (Integer) = 33
  MSLink (Integer) = 2406
  ULink (String(JSON)) = { "24721": [ { "raw": "0F8100210966000000000000", "type": "Oracle", "size": 16 } ] }
  Style = PEN(id:"ogr-pen-0",c:#ff0000)
  LINESTRING (659699.081 216466.475,659669.489 216455.323)

rouault · 2020-11-04T18:04:42Z

gdal/ogr/ogrsf_frmts/dgn/ogrdgnlayer.cpp

+    if( !EQUAL(pszULinkType,"NONE") )
+    {
+        char * testULink;
+        iULinkType = (int) strtol( pszULinkType, &testULink, 10 );


The value of iULinkType seems to be compared only to -1. Shouldn't DGN_ULINK_TYPE be a boolean option tested with CPLTestBool ?

and we need doc in the .rst pages of the driver(s) to document it

actually do we still need that option ? Couldn't that be enabled systematically ?

No, we don't need that option.

rouault · 2020-11-04T18:05:15Z

gdal/ogr/ogrsf_frmts/dgn/ogrdgnlayer.cpp

+        oField.SetName( "ULink" );
+        oField.SetType( OFTString );
+        oField.SetSubType( OFSTJSON );
+        // oField.SetType( OFTIntegerList );


rouault · 2020-11-04T18:07:31Z

gdal/ogr/ogrsf_frmts/dgn/ogrdgnlayer.cpp

+            uLinkData.Add( std::to_string(nLinkType), CPLJSONArray() );
+            previousValues = uLinkData.GetArray( std::to_string(nLinkType) );
+        } 
+        char *pszAsHex = CPLBEBinaryToHex( nLinkSize - 4, pabyData + 4 );


why not using plain CPLBinaryToHex() ? It seems to me more standard to report the 4 high-order bits as the first hexadecimal character

Agree.

The order needs to be reverted, just for the data related with application id = 0x1995. For this application id, I know that the data order has to be reversed.

The order needs to be reverted, just for the data related with application id = 0x1995. For this application id, I know that the data order has to be reversed.

That doesn't make sense to me why you'd need to do that. It is also a bit odd to call something big-endian whereas we are talking about the ordering of the high and low 4 bits of a byte, whereas big-endian normally apply to multi-byte integers/float. If that function is really needed, I'd suggest to do just add a logic to permute bytes after calling CPLBinaryToHex() instead of adding something in the CPL namespace

@rouault I've checked data for other application ids again. It seems to me that we need to reverse the byte order for other application IDs, as well. I'm not sure if we have to do this for all application IDs, so this comment might be useful for future reference. We return the data as raw, but people might need to swap byte order.

Example using CAD file used on ticket 1387

For DB linkages, for example, application id = 24721, we have:

Using ODA's API:

{ "24721": [ { "tableId": 33, "MSLink": 2406, "type": "Oracle" } ] }

Using DGN driver, with raw hex, without reverse byte order:

{ "24721": [ { "raw": "810F21006409000000000000", "type": "Oracle", "size": 16 } ] }

Reversing the byte order, we have:

{ "24721": [ { "raw": "0F81 0021 0964 000000000000", "type": "Oracle", "size": 16 } ] }

With the reversed byte order, we can find the tableId: 0x0021 (decimal 33) and MSLink: 0x0964 (decimal 2406). The reversed order matches ODA's API behaviour.

What do you think?

oh.... I misunderstood what CPLBEBinaryToHex() do. I thought it switched the upper and lower bits of each byte. But it actually deals with 16-bit words in big-endian order. But I don't see the need for that function though . This is more a documentation issue. If it is documented that 2100 should be interpreted as 0x21 | (0x00 << 8) and 6409 as 0x64 | (0x09 << 8), then things are OK

My fault. I should have been more verbose. The BE in CPLBEBinaryToHex stands for Big Endian, but it is too short.

While little/big endian are related to CPU architectures, the same concept in strings is less obvious. That's why I added this CPLBEBinaryToHex(). But I don't have a strong opinion. If you prefer to dump it as it is, we can do it that way. I would prefer to have the output (the hex string) properly ordered.

Please let me know what do you prefer @rouault (and thank you for all the feedback).

When dumping raw content, I find it better that it is dump as it, without doing byte swapping. If the raw content is always a pair of 16-bit words (haven't checked what DGN says about that), then "raw" could be an array of decoded integers instead. If the interpretation of the content depends on the user link, then raw is fine.

Thank you for the feedback @rouault

I was using this reference:

A user data linkage is stored in an array of short (16-bit) words. Each array contains an application ID, an attribute ID, and a word count, followed by an arbitrary amount of linkage data.

It's up to you to figure out how to encode and decode your user data. You probably want to write one function that wraps raw data with your Application ID, and another that can extract the Application ID and raw data from a data linkage.

Definitely, the interpretation of the content depends on the user link.

If you don't mind, I'll follow different approaches for the DGN driver and for the DGNV8.

DGN driver

Dump the content as it is, without any interpretation or byte swapping.

DGNV8 driver

Dump the contents with interpretation, since we can use ODA API to get structured data for known application ids. There are known application ids like OdDgDBLinkage that we can take advantage. For the unknown ones, we still have to dump the contents as it is.

Documentation

I'll update the driver's documentation to reflect this.

Sound reasonable to you?

sounds good

rouault · 2020-11-05T17:12:29Z

gdal/port/cpl_string.cpp

@@ -2505,7 +2505,7 @@ char *CPLBinaryToHex( int nBytes, const GByte *pabyData )
 * @return hexadecimal translation, zero terminated.  Free with CPLFree().
 */

-char *CPLBEBinaryToHex( int nBytes, const GByte *pabyData )
+char *CPLBigEndianBinaryToHex( int nBytes, const GByte *pabyData )


I believe we decided to remove that and use CPLBinaryToHex() instead. You'd just have to indicate in the doc that the ordering of number is little endian.

Yes, you are right. I'm not using this CPLBigEndianBinaryToHex on the DGN driver.

I thought it might be useful else where and that's why I've kept it on CPL. I'm still using it on the DGNV8 driver. On the DGNV8, I'm trying to provide the data interpreted, as possible.

I can make it a local function on DGBV8 driver and remove it from CPL. Probably it does not make sense to have it in the CPL.

I'll remove it from CPL.

rouault · 2020-11-05T18:13:52Z

gdal/ogr/ogrsf_frmts/dwg/ogrdgnv8layer.cpp

@@ -853,7 +886,7 @@ std::vector<tPairFeatureHoleFlag> OGRDGNV8Layer::ProcessElement(
                    break;
                    case 0x1995: // 0x1995 (6549) IPCC/Portugal
                    {
-                        char *pszAsSwappedHex = CPLBigEndianBinaryToHex( (OdUInt32)pabyData.size(), (GByte*) pabyData.asArrayPtr() );
+                        char *pszAsSwappedHex = BigEndianBinaryToHex( (OdUInt32)pabyData.size(), (GByte*) pabyData.asArrayPtr() );


sorry to insist, but I still don't like the current output. For me it should be either an array of decoded integers [ 1234, 4567, ... ] (I'd lean towards that if the bytes are effictively always grouped by 16 bits) or a string with explicit 16-bit hexadecimal number "0xABCD 0xEF12" . "ABCDEF12" with this "big endian" order is higly unusual.

@rouault You don't give up, neither I do. That's good! I'll try to gather all my arguments, for a good discussion :-)

As explained in the description, this PR was submitted to solve a use case. The goal was to use GDAL in a workflow to transform old CAD based cartography into GIS based cartography. GDAL is the perfect tool for the job.

Context

Until recently, Portuguese official cartography was produced in CAD based systems, using a multi-codification system. Each element in CAD (features) have their type defined by a list of codes. As required by Bentley, these codes were recorded as user data linkages, under a well known application id. The application id used by IPCC (the former map agency) is 0x1995. Companies and developers were able to build applications knowing the information structure encoded in this specific user data linkages. The structure comprises the domain, subdomain, family and object.

The structure is (values in hex):

1st word 1 0 0 3

2nd word 1 9 9 5

3rd word domain subdomain

4th word family object

The Microstation print screen provided in the PR shows this user data linkage as displayed to the user, in the CAD environment.
Purpose of the PR

This PR was submitted to add the ability to read data from user data linkages from known application ids and report it and a new feature attribute. The idea was to identify the target application id as an environment variable and these drivers would use it to extract the information for that specific user data linkage.

This PR improves two drivers: the DGN and the DGNV8 driver. For the DGNV8 driver, we can take advantage of ODA API to retrieve data for known application ids. For DGN driver, we have to add the necessary logic to retrieve the information from the data, according to each application id.

For unknown applications ids, we are not able to retrieve the data. We just know the size, and from the DGN user data linkage format, that size is always a multiple of 4 words, but its contents can be anything.

This additional capability of these drivers does not affect any previous functionality. Only adds an additional capability to read known user data linkages.

PR improvement

Based on your suggestion, instead of just reporting one user data linkage type, these two drivers could report all user data linkage present.

For unknown application ids, that is not possible. The solution discussed here, which I agreed, was to output it as raw data, either as hex or integers. Any dump format for me is ok, because we really don't know what we are dealing with. We just know the size of the data, and that the size is multiple of 4 words. Is up to the driver's user to use this raw data to recover the information encoded on it.

First PR limitation

Based on your comments, I gave up on DGN driver. But I was so committed to moving forward, that I've accepted to make it happen just for the DGNV8 driver. Right now, I regret that decision, because all the users I know that might want to take advantage of this do not have access to the DGNV8 driver.

Reverting the PR goal

I'm sorry that that you don't like the output of the application id 0x1995, even for the DGNV8 driver.

For unknown application ids, I agree that we can use any kind of raw data that you like, but for application ids that we know how the structure is, it does not make any sense to me to report it in a different way. The "highly unusual order", as you call it, is the exact order that is displayed in the Microstation print screen, if you not have noticed. Users don't know any order other than this "highly unusual order".

Reporting its contents without attending its format, reverts the purpose of this PR. The purpose was to recover the data on that user data linkage.

Moving forward

Right now, after a few commits, I've lost completely the purpose of the PR. Is is not useful any more for the use case and for the users that would like to process old CAD based cartography.

Back to the origin

My humble suggestion is to go back to the very first commit and discuss the ability to support the user data linkage of the application id = 0x1995, if requested by the user, by providing a environment variable. Just that specific user data linkage, but attending its structure.

This support does not interfere any other drivers capability; does not add additional noise if the environment variable is not set, etc. Seems quite inoffensive for me, in terms of impact to the code. And since we don't have many option to deal wit hit, we don't have many things to discuss.

It does not solve all the unforeseen useful use cases, but solves one use case.

Can we restart this from the beginning? What do you think?

(Sorry for such a long comment)

Can we restart this from the beginning? What do you think?

On the contrary, I think we're quite close to what I'd wish. I like the output of Microstation with the 0x prefix. That's exactly what I suggested above: "0x3412 0x7856" as a string has no ambiguity whereas "34127856" is confusing, if the raw bytes where actually ordered as 0x12,0x34,0x56,0x78. Said otherwise if you present the user data link content as 16 bit words, this structure must clearly appear.
I'm only speaking about presentation of raw bytes. The more structured output for DGNv8 for known user data links is fine.

Thank you @rouault for the feedback.

ULink format

DGN ULink format

The Ulink is a JSON string, mapping application ids and its contents. The content is an array of words (16bits) in hexadecimal format.

{ "65": [ { "raw": [ "0x1007", "0x0041", "0x0802", "0x0001", "0x0053", "0x0000", "0x0000", "0x0000" ], "size": 16, "type": "unknown" } ] }

If the application id is known, the attribute type reports its.

{ "24721": [ { "raw": [ "0x1007", "0x6091", "0x0f81", "0x0021", "0x0964", "0x0000", "0x0000", "0x0000" ], "size": 16, "type": "Oracle" } ] }

DGNV8 ULink format

The ULink is a JSON string, mapping application ids and its contents. The content of the user data linkage is reported for some specific application ids.

{ "24721": [ { "size": 12, "tableId": 33, "MSLink": 2404, "type": "Oracle" } ] }

For unknown application ids, content is reported as raw 16bit words (exactly as in the DGN driver).

{ "65": [ { "size": 12, "raw": [ "0x0008", "0x0000", "0x0053", "0x0000", "0x0000", "0x0000" ], "type": "unknown" } ] }

Other examples

Test file franck_without_enhanced_precision.dgn

Example using CAD file used on ticket 1387

DGN driver output

OGRFeature(elements):39 Type (Integer) = 4 Level (Integer) = 3 GraphicGroup (Integer) = 0 ColorIndex (Integer) = 3 Weight (Integer) = 0 Style (Integer) = 0 EntityNum (Integer) = 33 MSLink (Integer) = 2404 ULink (String(JSON)) = { "24721": [ { "raw": [ "0x1007", "0x6091", "0x0f81", "0x0021", "0x0964", "0x0000", "0x0000", "0x0000" ], "size": 16, "type": "Oracle" } ] } Style = PEN(id:"ogr-pen-0",c:#ff0000) LINESTRING (659669.489 216455.466,659642.447 216461.671,659624.602 216463.187)

The ULink is a map between application ids and its contents. Since we dump the contents of the user data linkage data, the second word of the "raw" array (in hex) is equal to the object's key (in decimal). In the above case, the object key "27721" = "0x6091".

DGNV8 driver output

The same previous element, dumped with DGNV8 is:

OGRFeature(Default):193 Type (Integer) = 4 Level (Integer) = 3 GraphicGroup (Integer) = 0 ColorIndex (Integer) = 3 Weight (Integer) = 0 Style (Integer) = 0 ULink (String(JSON)) = { "24721": [ { "size": 12, "tableId": 33, "MSLink": 2404, "type": "Oracle" } ] } Style = PEN(id:"ogr-pen-0",c:#ff0000) LINESTRING (659669.489 216455.466,659642.447 216461.671,659624.602 216463.187)

Test file 454_1_10k_MNT.dgn

DGN driver output (just the ULink attribute)

ULink (String(JSON)) = { "6549": [ { "raw": [ "0x1003", "0x1995", "0x0203", "0x0104" ], "size": 8, "type": "IPCC\/Portugal" }, { "raw": [ "0x1003", "0x1995", "0x1001", "0x0404" ], "size": 8, "type": "IPCC\/Portugal" } ], "32047": [ { "raw": [ "0x1003", "0x7d2f", "0x712e", "0x0005" ], "size": 8, "type": "ODBC" } ] }

DGNV8 driver output (just the ULink attribute)

ULink (String(JSON)) = { "6549": [ { "size": 4, "domain": "0x02", "subdomain": "0x01", "family": "0x01", "object": "0x05", "key": "02010105", "type": "IPCC\/Portugal" }, { "size": 4, "domain": "0x02", "subdomain": "0x01", "family": "0x01", "object": "0x06", "key": "02010106", "type": "IPCC\/Portugal" }, { "size": 4, "domain": "0x02", "subdomain": "0x01", "family": "0x01", "object": "0x07", "key": "02010107", "type": "IPCC\/Portugal" }, { "size": 4, "domain": "0x11", "subdomain": "0x10", "family": "0x01", "object": "0x02", "key": "11100102", "type": "IPCC\/Portugal" }, { "size": 4, "domain": "0x88", "subdomain": "0x01", "family": "0x01", "object": "0x04", "key": "88010104", "type": "IPCC\/Portugal" } ], "24162": [ { "size": 12, "tableId": 5, "MSLink": 2010106, "type": "ODBC" }, { "size": 12, "tableId": 5, "MSLink": 2010107, "type": "ODBC" } ] }

…refix

rouault · 2020-11-09T12:09:31Z

I've tested it a bit and have added an extra commit in the DGNv8 driver: a62a92a

I was wondering if there was a particular reason for IPCC/Portugal being reported in a more structured way in the DGNv8 driver compared to the DGN one ? Ideally we'd have the same output

jgrocha · 2020-11-09T12:20:16Z

I've tested it a bit and have added an extra commit in the DGNv8 driver: a62a92a

Good! That's a good one.

I was wondering if there was a particular reason for IPCC/Portugal being reported in a more structured way in the DGNv8 driver compared to the DGN one ? Ideally we'd have the same output

I tried to keep the DGN output consistent for all application ids. The DGN dumps the content as 16 bit hexadecimal words. It adds the type for known application ids, but the contents is always the same array of words in hexadecimal.

rouault · 2020-11-09T12:34:23Z

I tried to keep the DGN output consistent for all application ids

yes, I noticed that. My point is: is there a good reason to not have the same output in both drivers ? That could simplify users' life if they get the same thing

jgrocha · 2020-11-09T13:07:18Z

I tried to keep the DGN output consistent for all application ids

yes, I noticed that. My point is: is there a good reason to not have the same output in both drivers ? That could simplify users' life if they get the same thing

No other reason that that. I'll make both outputs exactly the same.

Addition commit by Even

Support for reading MSLink data from DGN

5a81e51

Report DGN/DGNV8 all user data linkage as JSON

efccdab

jgrocha added 2 commits November 2, 2020 15:30

Document CPLBEBinaryToHex function

bd1a5dc

Explicit cast to MAKE_SANITIZE_HAPPY

0f8318c

jgrocha force-pushed the dgn-mslink branch from dca31ea to 0f8318c Compare November 3, 2020 20:25

Fix possible memory leaks

afd538f

rouault reviewed Nov 4, 2020

View reviewed changes

jgrocha added 3 commits November 4, 2020 20:53

Remove DGN_ULINK_TYPE option; output as raw hex

73446f2

Documentation regarding ULink support in DGN and DGNV8 drivers

68cf27e

Clean up

adbaec3

rouault reviewed Nov 5, 2020

View reviewed changes

Revert CPL string library

a8d91d7

rouault reviewed Nov 5, 2020

View reviewed changes

jgrocha marked this pull request as draft November 6, 2020 00:39

jgrocha added 3 commits November 8, 2020 00:16

Format raw data user data linkage data as hexadecimal words with 0x p…

6e0e0d8

…refix

Update the DGN and DGV8 documentation regarding MSLink and ULink

9ecda9d

Remove unused BigEndianBinaryToHex function

eb405cb

jgrocha force-pushed the dgn-mslink branch from 305351d to eb405cb Compare November 8, 2020 09:56

jgrocha marked this pull request as ready for review November 8, 2020 18:00

DGNv8: fix setting the string value for string linkage

a62a92a

jgrocha added 2 commits November 9, 2020 13:33

Make DGN and DGNV8 ULink output uniform for application id = 0x1995

6c333bb

Merge branch 'dgn-mslink' of github.com:jgrocha/gdal into dgn-mslink

352b886

Addition commit by Even

rouault merged commit 92df7a3 into OSGeo:master Nov 9, 2020

rouault added this to the 3.3.0 milestone Nov 9, 2020

jgrocha mentioned this pull request Feb 16, 2021

Expose OGR feature styles via a new "Embedded styling" renderer qgis/QGIS-Enhancement-Proposals#209

Open

jgrocha mentioned this pull request Feb 26, 2021

DGN driver: Text property reported as JSON instead of string #3496

Closed

jgrocha mentioned this pull request Dec 19, 2021

[DGNv8] Fix test data #5017

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for reading User Data Linkage data using DGNv8/DWG vector drivers #3089

Support for reading User Data Linkage data using DGNv8/DWG vector drivers #3089

jgrocha commented Oct 21, 2020 •

edited

Loading

rouault commented Oct 21, 2020

jgrocha commented Nov 2, 2020 •

edited

Loading

rouault Nov 4, 2020

rouault Nov 4, 2020

rouault Nov 4, 2020

jgrocha Nov 4, 2020

rouault Nov 4, 2020

rouault Nov 4, 2020

jgrocha Nov 4, 2020

rouault Nov 4, 2020

jgrocha Nov 4, 2020

rouault Nov 4, 2020

jgrocha Nov 4, 2020

rouault Nov 5, 2020

jgrocha Nov 5, 2020

rouault Nov 5, 2020

rouault Nov 5, 2020

jgrocha Nov 5, 2020

jgrocha Nov 5, 2020

rouault Nov 5, 2020

jgrocha Nov 6, 2020

rouault Nov 6, 2020

jgrocha Nov 8, 2020

rouault commented Nov 9, 2020

jgrocha commented Nov 9, 2020

rouault commented Nov 9, 2020

jgrocha commented Nov 9, 2020

1st word	1	0	0	3
2nd word	1	9	9	5
3rd word	domain		subdomain
4th word	family		object

Support for reading User Data Linkage data using DGNv8/DWG vector drivers #3089

Support for reading User Data Linkage data using DGNv8/DWG vector drivers #3089

Conversation

jgrocha commented Oct 21, 2020 • edited Loading

What does this PR do?

Application ID

ogrinfo

Check for User Data Linkage

Example

Limitation

Tasklist

Environment

Credits

rouault commented Oct 21, 2020

jgrocha commented Nov 2, 2020 • edited Loading

Examples for IPCC Portugal user data link data

IPCC Portugal user data link data

Other examples

Example usage and output (DGNV8 driver)

Example usage and output (DGN driver)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DGN driver

DGNV8 driver

Documentation

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Context

Purpose of the PR

PR improvement

First PR limitation

Reverting the PR goal

Moving forward

Back to the origin

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ULink format

DGN ULink format

DGNV8 ULink format

Other examples

Test file franck_without_enhanced_precision.dgn

DGN driver output

DGNV8 driver output

Test file 454_1_10k_MNT.dgn

DGN driver output (just the ULink attribute)

DGNV8 driver output (just the ULink attribute)

rouault commented Nov 9, 2020

jgrocha commented Nov 9, 2020

rouault commented Nov 9, 2020

jgrocha commented Nov 9, 2020

jgrocha commented Oct 21, 2020 •

edited

Loading

jgrocha commented Nov 2, 2020 •

edited

Loading

Test file `franck_without_enhanced_precision.dgn`

Test file `454_1_10k_MNT.dgn`