Changes between Version 2 and Version 7 of Ticket #4369
- Timestamp:
- Dec 12, 2011, 9:02:00 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #4369
- Property Status new → assigned
-
Ticket #4369 – Description
v2 v7 1 I have here some enhancements for the DXF driver of OGR. 1 Answer to the first test, where the angle is missing: 2 2 3 Here is a summary of what I have done: 3 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 4 {{{ 5 // Do we need to compute the dimension value? 6 }}} 7 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". 4 8 5 TranslateTEXT6 - The width-scaling of the text ("Relative X scale factor") is now stored as style string (param_name: "w")7 9 8 TranslateDIMENSION 9 - The text angle is calculated with atan instead of atan2. This prevents the text beeing written upside down. 10 - The arrowheads are now scaled according to the arrow head size given in the header section of the DXF-file. 11 - Added support for radius and diameter dimension types. 12 - 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!) 10 Answer to the second test: 13 11 14 New DXF-Entities are supported: 15 - TranslateLEADER 16 - TranslateSOLID (at this point only the a border around the solid is drawn, i.e. no filling!) 17 18 PrepareLineStyle 19 - 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) ) 12 In TranslateINSERT I added: 13 {{{ 14 /* -------------------------------------------------------------------- */ 15 /* if the subfeature is a text, then adjust */ 16 /* - text angle */ 17 /* - text height */ 18 /* - text width-factor (Stretch) */ 19 /* -------------------------------------------------------------------- */ 20 int iType = poSubFeature->GetGeometryRef()->getGeometryType(); 21 OGRStyleMgr *poStyle = new OGRStyleMgr(); 22 poStyle->InitFromFeature(poSubFeature); 20 23 21 Added new attributes for features: 22 - "PaperSpace" -> Absent or "0" means model space, "1" means paper space. 23 - "Invisible" -> Indicates the object visibility: "0" = visible, "1" = invisible 24 - "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". 25 26 ACTextUnescape 27 - 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.) 28 29 I think that were all or at least the most important changes I have made. 30 Because this is my first ticked, I hope I made no serious mistake and the changes in the patch are GDAL-conform. 31 I would be pleased if the changes would be incorporated into trunk and finally into the next GDAL release. 24 if ( wkbFlatten(iType) == wkbPoint && poStyle->GetStyleString()!=NULL ) 25 { 26 const char *str; 27 OGRStyleLabel *poLabel = (OGRStyleLabel*) poStyle->GetPart(0); 28 GBool bN; 29 double dfAngle = poLabel->Angle(bN); 30 poLabel->SetUnit(OGRSTUGround); 31 double dfSize = poLabel->Size(bN); 32 double dfStretch = poLabel->Stretch(bN); 33 if (dfStretch==0.0) dfStretch = 1.0; 34 poLabel->SetAngle (dfAngle + oTransformer.dfAngle / PI * 180.0); 35 poLabel->SetSize (dfSize * oTransformer.dfYScale); 36 poLabel->SetStretch (dfStretch * oTransformer.dfXScale / oTransformer.dfYScale); 37 poSubFeature->SetStyleString(poLabel->GetStyleString()); 38 str = poLabel->GetParamStr(OGRSTLabelFontName,bN); 39 } 40 41 delete poStyle; 42 }}} 43 44 This could be the source of the problem. In the line 45 {{{ 46 poSubFeature->SetStyleString(poLabel->GetStyleString()); 47 }}} 48 49 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".