<br><br><div class="gmail_quote">2010/1/11 Lime, Steve D (DNR) <span dir="ltr">&lt;<a href="mailto:Steve.Lime@state.mn.us">Steve.Lime@state.mn.us</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all: What would devs think about adding a reasonable set of default symbols to MapServer? They&#39;d just be there to reference by name. It&#39;s a<br>
relatively simple change. Just define a static array of symbol defs (e.g. &quot;SYMBOL NAME \&quot;__ms_circle__\&quot; ...) and define a msUpdateSymbolFromString()<br>
function similar to the ones used already in mapfile.c. (this is probably a good idea anyway for use in mapscript). The string parsing makes it easy to<br>
define the defaults. I&#39;ve got it working locally and it&#39;s a nice convenience. Hardest part would be defining which are good defaults and what a good<br>
naming convention would be. If there&#39;s interest I can write up a quick RFC...<br>
<br></blockquote><div><br>Hi Steve,<br><br>We already have some conventions with regards to the OGR style mappings (for example mapping the marker symbols to a symbol with &#39;default-marker&#39; as a last resort). I think these names should anyway be defined by default in MapServer. However I&#39;m not sure how the name collisions would be handled in this regard. We should probably override the symbols with the same name by using the following priorities:<br>
<br>1. The symbol defined in the mapfile<br>2. The symbol defined in the symbolset file<br>3. The symbol defined my MapServer<br><br>Curently this issue is not handled and multiple symbols with the same name can co-exist in the symbolset, however only the first symbol of the same name is actually used during the symbol lookups. This would be annoying for those application which displays a symbol selector window for the user.<br>
<br><br>We could also consider supporting the default MapInfo symbols (line and area styles), however our symbol definition approach should somewhat be extended to implement all of those (lines and brush patterns). It would be a good solution to support grouping multiple symbols to define a new symbol which would allow to create more complex representations (like combining filled and non filled vectors)<br>
<br><br>Best regards,<br><br>Tamas<br><br></div></div><br>