Manifold Community Site: Style Questionhttp://www.georeference.org/forum/t138997Manifold Community Site threadhttp://www.georeference.org/forum/images/img-logo.pngManifold Community Site: Style Questionhttp://www.georeference.org/forum/t138997RE: Style Questionhttp://www.georeference.org/forum/t138997#138998<P>I have a small table consisting of three points, each with the same lat/long. When I try to plot them out in a drawing I can only get the first to display. I have setup thematic styles using a progressively larger point size and different colours. I have attached a screenshot of the problem. </P><P>I would expect that either all three would appear (with the first being contained by the second and the second inside the third) or only the last. Instead it shows the first point only, which is also the smallest.</P><P>Is this a bug or am I just doing something silly?</P><P>I have noticed this behaviour in 9.0.163.5 and 9.0.163.6.</P><p class='file'><b>Attachments:</b><br><a href='e46362F3133383939382F53637265656E73686F742E504E47/Screenshot.PNG'><img src='images/dwn-ftp.gif' align='absmiddle'></a> <a href='e46362F3133383939382F53637265656E73686F742E504E47/Screenshot.PNG'>Screenshot.PNG</a><br></p>pslinder1http://www.georeference.org/forum/t138997#138998http://www.georeference.org/forum/t138997#138998Tue, 24 Oct 2017 21:51:26 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#138999<P>As I understand it, there is no defined Z order for objects in the same drawing in 9-series products.</P><P>In Manifold 8, Z-order followed ID order, in reverse, so that the highest ID would always be drawn last.</P><P>This is not the case in SQL9, which is free to use multiple threads to fetch data and to draw data to screen. So although mfd_id looks like a linear series (often with gaps), series order is not available to control Z. So Z order in drawings is currently arbitrary in 9.</P><P>But if that is right, it is only one aspect of what you are seeing. Order is arbitrary, but why is only one point drawn? I would guess that the answer is Z culling, so that if there are multiple objects at the same location, only one object is drawn--the first or last object drawn hides any others--and that location is interpreted strictly, so that for points, formatted size is not material. Again just guessing.</P><P>So perhaps you will have to either use multiple drawings (whose relative Z order <B>is</B> defined), or use area objects. In the latter case not an overlapping stack of areas, but a set of rings, each net of the others, so that appearance is the same regardless of order. (Or almost--what about the border?)</P><P>Maybe this will change in future.</P>tjhbhttp://www.georeference.org/forum/t138997#138999http://www.georeference.org/forum/t138997#138999Tue, 24 Oct 2017 22:23:01 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#139007<P>text</P><P>There are two effects depending on how you use layers.</P><P>One effect is the rendering engine puts only one point exactly at the same spot. This is a matter of taste, but given the random z ordering it is probably as fair as putting the biggest point exactly on top.</P><P>The other effect to keep in mind is since the border and fill colors are identical you cannot see where one point ends and the other begins. If all three points are at the same location, even if the smaller ones are stacked on the bigger one it will look like a single round dot.</P><P><IMG class='cons' id='i139007x0_elt' onclick="showhideImageElt('i139007x0_elt')" SRC='http://www.georeference.org/forum/e46462F3133393030372F706F696E7473312E706E67/points1.png'></P><P>Above is with style using a black border on each point.</P><P><IMG class='cons' id='i139007x1_elt' onclick="showhideImageElt('i139007x1_elt')" SRC='http://www.georeference.org/forum/e46462F3133393030372F706F696E7473322E706E67/points2.png'></P><P>But, if colors are the same, points seem to disappear because you cannot see where one ends and the next point begins. This is along the same lines as the discussion in <A HREF='http://manifold.net/doc/mfd9/index.htm#example__how_not_to_format_a_drawing.htm'><B>this Example topic</B></A>. </P><p class='file'><b>Attachments:</b><br><a href='e46462F3133393030372F706F696E7473312E706E67/points1.png'><img src='images/dwn-ftp.gif' align='absmiddle'></a> <a href='e46462F3133393030372F706F696E7473312E706E67/points1.png'>points1.png</a><br><a href='e46462F3133393030372F706F696E7473322E706E67/points2.png'><img src='images/dwn-ftp.gif' align='absmiddle'></a> <a href='e46462F3133393030372F706F696E7473322E706E67/points2.png'>points2.png</a><br></p>Dimitrihttp://www.georeference.org/forum/t138997#139007http://www.georeference.org/forum/t138997#139007Wed, 25 Oct 2017 07:35:03 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#139026<P>This is not a bug.</P><P>Tim is correct - the order of objects is random and we use Z culling so out of N points in the same location we will only ever render one. All of it is intentional.</P><P>Are you having three points in the same location because you want to achieve some visual effect? If so, use a single point and create three drawings on the same table. In the future you will also be able to use more complex styles and possibly create the effect you want without multiple drawings.</P>adamwhttp://www.georeference.org/forum/t138997#139026http://www.georeference.org/forum/t138997#139026Wed, 25 Oct 2017 11:58:41 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#139033<P>Interesting. I am not sure I see the advantage of the intention. Why not draw all the points and order them based on the ranking in the styles? In many if not most cases I understand the futility of having multiple records at the same point but in some cases there may be valuable and sensible information that may be there and worth looking at. This is by the way how things worked (or seemed to) in Manifold 8. Very sensible.</P><P>I also have an additional feature request I would like to float here to get feed back on. As background, I work in the cellular industry and we often have multiple sectors at the same cell location (usually three). These can be seen on buildings or towers where there are three sets antennas (2 or 3 facing the same direction), each set is a sector, fed by a separate radio, pointing in a different direction (often 0, 120, 270 deg). We often need to analyze information for each sector separately not as an aggregate of all sectors at the cell site.</P><P>In the databases all of the sectors have the same lat/lon location. In this regard the location of the sector is important but just as important is the direction its antennas is pointing. In order to show and analyze the sectors it would be great if there were a set of icons that show direction and rotate not at the center of the Icon but at the bottom.</P><P>For instance a pie wedge whose rotation point is the peak of the pie wedge or an arrow whose rotation point is at the bottom of the shaft. Of course to do this Future would have to be willing to draw multiple points at the same location just like Manifold 8.</P><P>I love the ability in Future by the way to rotate Icons by 5 degs and would love to be able to do it by 1 deg or even down to 100ths of degs. It would be cool if rotation could be tied to a field just like color, size or shape.</P>pslinder1http://www.georeference.org/forum/t138997#139033http://www.georeference.org/forum/t138997#139033Wed, 25 Oct 2017 16:05:35 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#139034<P>The advantage of skipping points with the same coordinates is not spending time repainting the same pixels with slightly different colors with each next painted point overriding what was already painted. Since the user is going to see a random point on top anyway, it could just as well be the very first point encountered and all the rest could be skipped. Manifold 8 didn't skip points, but since it always used the same predictable order, there was no randomness and one could do various effects. However, this all breaks when the order stops being predictable and it isn't predictable with databases, and even outside of databases forcing the order to be predictable disallows using multiple threads, etc.</P><P>We are considering allowing to specify the order explicitly via a priority field. When we do so, we will likely allow rendering all objects at the same location, with an option to cut off at some value of the priority field. If there is a desire to impose a Z order, great, let's do this sanely. :-) Now that you described your scenario I better understand where you are coming from. Indeed it looks like having multiple points at the same location is a natural solution. We might add an option to stop skipping points with the same coordinates even without the imposed order, too.</P><P>An interesting request on point styles. I will add it to the wishlist, thanks!</P><P>You can tie the rotation to a field right now. For example, if you have rotation values in degrees in a field already, you can set rotation to use the values of that field, use two breaks, set 0 to 0 degrees, 360 to 360 degrees, and interpolate in between using the 'interpolate' fill mode.</P>adamwhttp://www.georeference.org/forum/t138997#139034http://www.georeference.org/forum/t138997#139034Wed, 25 Oct 2017 16:20:48 GMTRE: Style Questionhttp://www.georeference.org/forum/t138997#139038<BLOCKQUOTE><P><SPAN>In order to show and analyze the sectors it would be great if there were a set of icons that show direction and rotate not at the center of the Icon but at the bottom.</SPAN></P></BLOCKQUOTE><P>There probably is right now, in one of the zillions of symbol fonts that are out there. Look for a font with symbols that are like segments on a wheel, with just one segment colored in. Applying a font editor to something like Matonomannaka font to take one of the symbol wheels and knock out everything but one segement should be fairly simple. I tend to collect centered fonts because I like to stack them for a more custom look.</P>Dimitrihttp://www.georeference.org/forum/t138997#139038http://www.georeference.org/forum/t138997#139038Wed, 25 Oct 2017 20:01:50 GMT