I'm also against (for now) to support 3d views. It's just going to add another level of complexity and not that many softwares can draw 3d views easily. You would have to change the whole document structure and layer strucuture to support this.<br>
<br>What I would like to know is how complicated our symbols will be able to be. Are we going to support dash-dotted lines? Will we able to use a .bmp, .jpg ou .ico as a symbol? Support for font symbols as well? Supoort for multi-layered symbols (as ArcGIS, where you can have as many symbol layers as you want)?<br>
<br>This is where there is major complexity.<br><br>What do you guys think?<br><br>George<br><br><div class="gmail_quote">On Mon, Apr 12, 2010 at 6:09 PM, Landon Blake <span dir="ltr"><<a href="mailto:lblake@ksninc.com">lblake@ksninc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Tyler wrote: " Thinking about your "level" comment, I wonder if<br>
<div class="im">providing a 3D bounding box would be worthwhile, acting similar to the<br>
"section box" I've seen in some design software."<br>
<br>
</div>We could use a 2D or 3D bounding box, but it may raise a couple little<br>
problems.<br>
<br>
By only specifying a top-left corner horizontal position and level you<br>
can calculate the bounding box of your map frame using the size of the<br>
map frame in paper space. If you provide a bounding box in addition to<br>
this, you could have a situation where the bounding box didn't match the<br>
map frame extents in model space, which you need to calculate anyways.<br>
(Software applications could decide for themselves how to handle this<br>
conflict, by centering the bounding box in the map frame, for example.)<br>
<br>
There is also the trick of figuring out what level (floor of a building<br>
for example) corresponds to a 3D bounding box.<br>
<br>
Are there other benefits to using including a bounding box for a map<br>
frame instead of calculating the map frame extents in model space using<br>
the top-left coordinate and map frame dimensions in paper space?<br>
<br>
Landon<br>
Office Phone Number: (209) 946-0268<br>
Cell Phone Number: (209) 992-0658<br>
<div><div></div><div class="h5"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:carto-bounces@lists.osgeo.org">carto-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:carto-bounces@lists.osgeo.org">carto-bounces@lists.osgeo.org</a>] On Behalf Of Tyler Mitchell<br>
(OSGeo)<br>
Sent: Monday, April 12, 2010 10:25 AM<br>
To: <a href="mailto:carto@lists.osgeo.org">carto@lists.osgeo.org</a><br>
Subject: Re: [Carto] Revised Version of MRI XML File<br>
<br>
+1 looking good. Some good suggestions too in your PDF. Thinking about<br>
<br>
your "level" comment, I wonder if providing a 3D bounding box would be<br>
worthwhile, acting similar to the "section box" I've seen in some design<br>
<br>
software.<br>
<br>
Tyler<br>
<br>
On 04/12/2010 10:14 AM, Landon Blake wrote:<br>
> I have integrated the suggestions on the Map Rendering Input file that<br>
I<br>
> got on the mailing list and produced a new MRI sample file as a<br>
result.<br>
> I have attached the revised file to this e-mail. I have also attached<br>
a<br>
> PDF document listing the structural changes to the file and some of<br>
the<br>
> suggestions/questions for a preliminary specification that started to<br>
> pop into my head as I was working on the new file.<br>
><br>
> Let me know what you think.<br>
><br>
> If we are headed in the right direction I can upload the revised MRI<br>
> file to the SVN folder I set up and maybe start work on a short form<br>
of<br>
> a preliminary file specification.<br>
><br>
> Landon<br>
><br>
><br>
><br>
> *Warning:<br>
> *Information provided via electronic media is not guaranteed against<br>
> defects including translation and transmission errors. If the reader<br>
is<br>
> not the intended recipient, you are hereby notified that any<br>
> dissemination, distribution or copying of this communication is<br>
strictly<br>
> prohibited. If you have received this information in error, please<br>
> notify the sender immediately.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Carto mailing list<br>
> <a href="mailto:Carto@lists.osgeo.org">Carto@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/carto" target="_blank">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
<br>
_______________________________________________<br>
Carto mailing list<br>
<a href="mailto:Carto@lists.osgeo.org">Carto@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/carto" target="_blank">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
<br>
<br>
Warning:<br>
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.<br>
_______________________________________________<br>
Carto mailing list<br>
<a href="mailto:Carto@lists.osgeo.org">Carto@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/carto" target="_blank">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>George R. C. Silva<br><br>Desenvolvimento em GIS<br><a href="http://blog.geoprocessamento.net">http://blog.geoprocessamento.net</a><br>