I am designing a map in Mapbox Studio, using mapbox.mapbox-terrain-v2’s contour layer to determine the contour lines. This is based on the outdoors style.
In the outdoors style, the contour labels are oriented so that the text is displayed between -90° and 90° of horizontal, because Keep Text Upright is set. If I disable this, then the text becomes oriented at any angle. However, this text is oriented at exactly the opposite angle to what I would like: it always points downhill, not uphill. See first image below: note that the numbers are upright where the elevation increases from north to south.
What I am aiming for is to use the Ordnance Survey style of orienting numbers uphill (upright where the elevation increases from south to north), as in the second image below.
My current style can be seen here. I have tried using the text-rotate field, but this rotates each character individually, and there does not appear to be a function to reverse the string to counteract this. Additionally, this rotates about the top of each letter, meaning that the result is offset from the actual contour line, and text-translate + text-translate-anchor seem unable to resolve this.
As you noticed, using text-rotate on a symbol layer with placement: line rotates each character individually. So you would need to then reverse the string, which isn't possible within the expressions available.
However. There is one hacky workaround which may solve the problem for you. You can simply hardcode all the possible elevations with their reversals:
["match", ["get", "ele"],
750, "m057",
700, "m007",
650, "m056",
600, "m006",
550, "m055",
500, "m005",
""
]
Combined with a text-offset of 0,1.5, this actually looks alright:
I've published the style here
Related
Is it possible to draw a line similar to the example below and color it based on the previous value?
So to have the color red when the line is moving down and green when it goes up.
Can this be done with line type? Or does it need to be drawn with markLine or something else?
Any help is much appreciated!
https://echarts.apache.org/examples/en/editor.html?c=dynamic-data2
I don't think it is possible with the line chart, as the whole line uses the same color for all points. I suggest you use a scatter type chart where each point can have a different color. By setting symbol size to a small value and drawing values close together you can emulate visual line.
Here is an example based on the regression sample from echarts site:
I would like to expand a line to a wider polygon. Add 10 meter on both sides of the line for example.
Here is an example of what I would like
Take this line
And expand it to a wider polygon, like this
I did this manually, is there a way to do this automaticly?
Changing the KML or using a program?
Thanks
Vincent
Depending on how accurate you need this – this is not trivial.
One possible algorithm could be:
for each segment do
expand segment to rectangle with width 2r
targetShape.join(rectangle)
next
for each point do
expand point to circle with radius r
targetShape.join(circle)
next
targetShape.outerHull(precision)
Each single line in this routine is tricky and depends on your expectations.
You could leave out the circles and instead make the rectangles longer, but this wil not work on sharp turns.
All of this involves ugly calculations to figure orthogonal lines etc.
You could try it in an graphic tool, gimp or inkskape :-)
I am drawing text in a PDF page using iTextSharp, and I have two requirements:
1) the text needs to be searchable by Adobe Reader and such
2) I need character-level control over where the text is drawn.
I can draw the text word-by-word using PdfContentByte.ShowText(), but I don't have control over where each character is drawn.
I can draw the text character-by-character using PdfContentByte.ShowText() but then it isn't searchable.
I'm now trying to create a PdfTextArray, which would seem to satisfy both of my requirements, but I'm having trouble calculating the correct offsets.
So my first question is: do you agree that PdfTextArray is what I need to do, in order to satisfy both of my original requirements?
If so, I have the PdfTextArray working correctly (in that it's outputting text) but I can't figure out how to accurately calculate the positioning offset that needs to get put between each pair of characters (right now I'm just using the fixed value -200 just to prove that the function works).
I believe the positioning offset is the distance from the right edge of the previous character to the left edge of the new character, expressed in "thousandths of a unit of text space". That leaves me two problems:
1) How wide is the previous character (in points), as drawn in the specified font & height? (I know where its left edge is, since I drew it there)
2) How do I convert from points to "units of text space"?
I'm not doing any fancy scaling or rotating, so my transformation matrices should all be identity matrices, which should simplify the calculations ...
Thanks,
Chris
I want to display overlapping boxplots using Sigmaplot 12. When I choose the scale for the x-axis as linear then the boxes do indeed overlap but are much too thin. See figure below. Of course they should be much wider.
When I choose the scale of the x-axis to be "category", then the boxes have the right width, but are arranged along each single x-value.
I want the position as in figure 1 and the width as in figure 2. I tried to resize the box in figure 1 but when I choose 100% in "bar width" than it still looks like Figure 1.
many thanks!
okay, I found the answer myself. In Sigmaplot, there is often the need to prepare "style"-columns, for example if you want to color your barcharts, you need a column that holds the specific color names.
For my boxplot example I needed a column that has the values for "width". These had to be quite large (2000) in order to have an effect. Why ? I have no idea. First I thought it would be because of the latitude values and that the program interprets the point as "1.000"s, but when I changed to values without decimals, it didn´t get better.
Well, here is the result in color.
Have fun !
I am creating a Microsoft Word document using the OpenXml library. Most of what I need is already working correctly. However, I can't for the life of me find the following bit of information.
I'm displaying an image in an anchor, which causes text to wrap around the image. I used WrapSquare but this seems to affect the last line of the previous paragraph as shown in the image below. The image is anchored to the second paragraph but causes the last line of the first paragraph to also indent around the image.
Word Screenshot http://www.softcircuits.com/Client/Word.jpg
Experimenting within Word, I can make the text wrap how I want by changing the wrapping to WrapTight. However, this requires a WrapPolygon with several coordinates. And I can't find any way to determine the polygon coordinates so that they match the size of the image, which is in pixels.
The documentation doesn't even seem to indicate what units are used for these coordinates, let alone how to calculate them from pixels. I can only assume the calculation would involve a DPI value, but I have no idea how to determine what DPI will be used when the user eventually loads the document into Word.
I would also be satisfied if someone can explain why the issues described above is happening in the first place. I can shift the image down and the previous paragraph is no longer affected. But why is this necessary? (The Distance from text setting for both Left and Top is 0".)
The WrapPolygon element has two possible child elements of LineTo and StartPoint that each take a x and y coordinate. According to 2.1.1331 Part 1 Section 20.4.2.9, lineTo (Wrapping Polygon Line End Position) and 2.1.1334 Part 1 Section 20.4.2.14, start (Wrapping Polygon Start) found in the [MS-OI29500: Microsoft Office Implementation Information for ISO/IEC-29500 Standard Compliance]:
The standard states that the x and y attributes are represented in
EMUs. Office interprets the x and y attributes in a fixed coordinate
space of 21600x21600.
As far as converting pixels to EMUs (English Metric Units), take a look at this blog post for an example.
I finally resolved this. Despite what the standard says, the WrapPolygon coordinates are not EMUs (English Metric Units). The coordinates are relative to the fixed coordinate space (21600 x 21600, as mentioned in the quote provided by amurra).
More specifically, this means 0,0 is at the top, left corner of the image, and 21600,21600 is at the bottom, right corner of the image. This is the case no matter what the size of the image is. Coordinates greater than 21600 extend outside the image.
According to this article, "The 21600 value is a legacy artifact from the drawing layer of early versions of the Microsoft Office."