Opened 12 years ago

Closed 6 years ago

#4369 closed enhancement (invalid)

Enhancements to OGR DXF Driver

Reported by: srock Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SF Version: svn-trunk
Severity: normal Keywords: DXF
Cc:

Description (last modified by Alan Thomas)

I have here some enhancements for the DXF driver of OGR.

Here is a summary of what I have done:

TranslateTEXT

  • The width-scaling of the text ("Relative X scale factor") is now stored as style string (param_name: "w")

TranslateDIMENSION dealt with in #7120

  • The text angle is calculated with atan instead of atan2. This prevents the text beeing written upside down.
  • The arrowheads are now scaled according to the arrow head size given in the header section of the DXF-file.
  • Added support for radius and diameter dimension types.
  • If we do not inlined blocks, only the reference to the according block (where the dimension picture is stored) is captured on a point feature. It is therefore not necessary to compute new lines and arrows for each different dimension type. (In relation to this also the new feature attribute "BlockReference" is important, see below!)

New DXF-Entities are supported:

  • TranslateLEADER dealt with in #7111
  • TranslateSOLID (at this point only the a border around the solid is drawn, i.e. no filling!) dealt with in #5380

PrepareLineStyle

  • A layer color value of "0" in DXF files means that the color of the entity is determined by the superior block. In case we do not inlined blocks this information ("BYBLOCK") is passed as style string of the pen color instead of the RGB-color code. (i.e. PEN(c:BYBLOCK) instead of for example PEN(c:#FF0000) ) dealt with in #7099 (in a different way - the colour of the block is propagated onto those objects on layer 0 within the block, instead of storing BYBLOCK and making the end user select the right colour, which might be impossible if there are no other objects on the layer on which the block is inserted)

Added new attributes for features:

  • "PaperSpace" -> Absent or "0" means model space, "1" means paper space. split out to #7121
  • "Invisible" -> Indicates the object visibility: "0" = visible, "1" = invisible split out to #7121
  • "BlockReference" -> This is now used in combination with "BlockName" in case we do not inlined blocks. Before it was not possible to find the entities which belonged to a certain block reference (if one block was part of another block), because the block reference (to another block) was overwritten (in GetNextUnfilteredFeature) with the name of the block the reference was part of. Now the names of the blocks (defined in the BLOCKS Section of the DXF file) is stored in "BlockName" and the reference to a block (these references are part of an INSERT or a DIMENSION) are stored in "BlockReference".dealt with in #7106 using different field names

ACTextUnescape

  • In this function some DXF escape sequences are translated and stored into a resulting string. At the moment not all possible sequences are translated. Some of the possible sequences have to do with the formating (of somtimes only parts) of the text, like color codes, italic, font descriptions, etc. I think that it is not always useful to remove these kind of informations. (For instance I am using most of the formating informations in a DXF viewer. Without the formating information I could not display the text in the correct way.) Therefore I have introduced the new config option "DXF_TRANSLATE_ESCAPE_SEQUENCES". Setting this option to FALSE prevents the translation. In the future maybe it would make sense to translate only those escape sequences, which deal e.g. with UTF8. (I think I have found the meaning of all the escape sequences possible in DXF files. I could post them here or on gdal-dev mailing list if someone is interested.) split out to #7122

I think that were all or at least the most important changes I have made. Because this is my first ticket, I hope I made no serious mistake and the changes in the patch are GDAL-conform. I would be pleased if the changes would be incorporated into trunk and finally into the next GDAL release.

---

Answer to the first test, where the angle is missing:

That was my mistake. In all the dxf-files I had tested, there was a DXF-Group-Code of 42, where the actual measurement value was written. Therefore I used this value for the dimension label below the comment

// Do we need to compute the dimension value?

But as I now found in the AutoCAD DXF-reference, this code is only optional. I fixed this problem in the patch "gdal-ogr-dxf-20111212_.patch".

Answer to the second test:

In TranslateINSERT I added:

/* -------------------------------------------------------------------- */
/*      if the subfeature is a text, then adjust                        */
/*		- text angle                                                    */
/*		- text height                                                   */
/*		- text width-factor (Stretch)                                   */
/* -------------------------------------------------------------------- */
            int iType = poSubFeature->GetGeometryRef()->getGeometryType();
            OGRStyleMgr *poStyle = new OGRStyleMgr();
            poStyle->InitFromFeature(poSubFeature);

            if ( wkbFlatten(iType) == wkbPoint && poStyle->GetStyleString()!=NULL )
            {
                const char *str;
                OGRStyleLabel *poLabel = (OGRStyleLabel*) poStyle->GetPart(0);
                GBool bN;
                double dfAngle	 = poLabel->Angle(bN);
                poLabel->SetUnit(OGRSTUGround);
                double dfSize	 = poLabel->Size(bN);
                double dfStretch = poLabel->Stretch(bN);
                if (dfStretch==0.0) dfStretch = 1.0;
                poLabel->SetAngle	(dfAngle   + oTransformer.dfAngle / PI * 180.0);
                poLabel->SetSize	(dfSize    * oTransformer.dfYScale);
                poLabel->SetStretch	(dfStretch * oTransformer.dfXScale / oTransformer.dfYScale);
                poSubFeature->SetStyleString(poLabel->GetStyleString());
                str = poLabel->GetParamStr(OGRSTLabelFontName,bN);
            }

            delete poStyle;

This could be the source of the problem. In the line

poSubFeature->SetStyleString(poLabel->GetStyleString());

I copy the style string. Today I realized that in the method "OGRStyleTool::GetStyleString" of the file "ogrfeaturestyle.cpp" the style string is generated without quotation marks! I'm not sure if this is correct. The solution would be either to remove my change above, or to change the behaviour of GetStyleString. Or maybe there is a better solution for fixing the "subtle things".

Attachments (2)

gdal-ogr-dxf-20111205.patch (42.4 KB ) - added by srock 12 years ago.
gdal-ogr-dxf-20111212_.patch (22.0 KB ) - added by srock 12 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by Even Rouault, 12 years ago

This belongs to FrankW's area of expertise, but I did try to read the patch and was stopped by its unreadability as a patch. I guess there must have issues with your text editor messing with end of line characters, or something like that, but if you look at http://trac.osgeo.org/gdal/attachment/ticket/4369/gdal-ogr-dxf-20111205.patch, you'll see that is impossible to know if you have indeed rewritten everything, or if your changes are more local. I also observe strange indentations, perhaps due to the use of tab characters ?

by srock, 12 years ago

Attachment: gdal-ogr-dxf-20111205.patch added

in reply to:  1 comment:2 by srock, 12 years ago

Description: modified (diff)

Replying to rouault:

This belongs to FrankW's area of expertise, but I did try to read the patch and was stopped by its unreadability as a patch. I guess there must have issues with your text editor messing with end of line characters, or something like that, but if you look at http://trac.osgeo.org/gdal/attachment/ticket/4369/gdal-ogr-dxf-20111205.patch, you'll see that is impossible to know if you have indeed rewritten everything, or if your changes are more local. I also observe strange indentations, perhaps due to the use of tab characters ?

I'm sorry, there was indeed a problem with tab characters and end of line characters. I removed all tab characters and changed the end of line characters to UNIX format. I think now it looks better. I have uploaded the fixed patch again as a replacement for the previous one. I have also corrected some typos in the description above.

comment:3 by warmerdam, 12 years ago

Status: newassigned

An impressive set of changes. I'll try to review and integrate them tonight.

I'd like to see additional information on text escape sequences captured as close to the translation code as possible.

comment:4 by warmerdam, 12 years ago

In ogrdxflayer.cpp I see:

    // Why don't add these fields in "AddStandardFields" ??
    // That seems more consistent to me, so I removed them here.
    /*
    if( !poDS->InlineBlocks() )
    {
        OGRFieldDefn  oScaleField( "BlockScale", OFTRealList );
        poFeatureDefn->AddFieldDefn( &oScaleField );

        OGRFieldDefn  oBlockAngleField( "BlockAngle", OFTReal );
        poFeatureDefn->AddFieldDefn( &oBlockAngleField );
    }
    */

The answer is that these fields are not appropriate in a blocks layer as things were setup. I didn't see any obvious reason why this change was needed as part of your patch so I have reverted it.

comment:5 by warmerdam, 12 years ago

As I'm trying to work through the ogr_dxf.py test script I'm getting some differences that don't seem kosher.

  TEST: ogr_dxf_8 ... fail
    line 285: Got unexpected style string:
LABEL(f:"Arial",t:"0.0000",p:5,a:43.3,s:2.5g)
instead of:
LABEL(f:"Arial",t:"54.3264",p:5,a:43.3,s:2.5g).

In the above test, it seems as if the angle with which the dimension is supposed to be labelled is lost.

  TEST: ogr_dxf_9 ... fail
    line 323: Got unexpected style string:
LABEL(f:Arial,s:0.5g,t:Text Sample1¿λ
"abc",a:45,c:#000000,p:5,w:1.000000)
instead of:
LABEL(f:"Arial",t:"Text Sample1¿λ
\"abc\"",a:45,s:0.5g,p:5,c:#000000).

In the above difference there seems to have been some decay of the quoting logic for the text in a LABEL.

Any thoughts on these? I have made a few changes. The above mentioned one about blockscale/angle and also I moved PaperSpace and Invisible to the end of AddStandardFields() to avoid renumbering existing fields.

in reply to:  4 comment:6 by srock, 12 years ago

Replying to warmerdam:

In ogrdxflayer.cpp I see:

    // Why don't add these fields in "AddStandardFields" ??
    // That seems more consistent to me, so I removed them here.
    /*
    if( !poDS->InlineBlocks() )
    {
        OGRFieldDefn  oScaleField( "BlockScale", OFTRealList );
        poFeatureDefn->AddFieldDefn( &oScaleField );

        OGRFieldDefn  oBlockAngleField( "BlockAngle", OFTReal );
        poFeatureDefn->AddFieldDefn( &oBlockAngleField );
    }
    */

The answer is that these fields are not appropriate in a blocks layer as things were setup. I didn't see any obvious reason why this change was needed as part of your patch so I have reverted it.

No, this part is not needed for the patch, it just confused me that the fields were not added in "AddStandardFields" and I thought that would be a mistake.

in reply to:  5 comment:7 by srock, 12 years ago

Description: modified (diff)

Replying to warmerdam:

As I'm trying to work through the ogr_dxf.py test script I'm getting some differences that don't seem kosher.

  TEST: ogr_dxf_8 ... fail
    line 285: Got unexpected style string:
LABEL(f:"Arial",t:"0.0000",p:5,a:43.3,s:2.5g)
instead of:
LABEL(f:"Arial",t:"54.3264",p:5,a:43.3,s:2.5g).

In the above test, it seems as if the angle with which the dimension is supposed to be labelled is lost.

  TEST: ogr_dxf_9 ... fail
    line 323: Got unexpected style string:
LABEL(f:Arial,s:0.5g,t:Text Sample1¿λ
"abc",a:45,c:#000000,p:5,w:1.000000)
instead of:
LABEL(f:"Arial",t:"Text Sample1¿λ
\"abc\"",a:45,s:0.5g,p:5,c:#000000).

In the above difference there seems to have been some decay of the quoting logic for the text in a LABEL.

Any thoughts on these? I have made a few changes. The above mentioned one about blockscale/angle and also I moved PaperSpace and Invisible to the end of AddStandardFields() to avoid renumbering existing fields.

by srock, 12 years ago

comment:8 by warmerdam, 12 years ago

Description: modified (diff)

comment:9 by warmerdam, 12 years ago

I have restored the original description with a good deal of effort. Please try not to remove this useful reference information.

in reply to:  9 comment:10 by srock, 12 years ago

Replying to warmerdam:

I have restored the original description with a good deal of effort. Please try not to remove this useful reference information.

I'm so sorry, somehow I filled in the wrong field. I was also trying to restore the original, but you you where faster.

comment:11 by Jukka Rahkonen, 8 years ago

Did the development stop or is there just a pause?

comment:12 by Alan Thomas, 6 years ago

Description: modified (diff)
Resolution: invalid
Status: assignedclosed

Many of these issues have recently been solved. For the remaining issues, I've split this ticket into several new tickets which can then be handled individually.

In view of the fact that the reporter has disappeared, there is no longer anything to do here, so I am closing this ticket.

Note: See TracTickets for help on using tickets.