[Carto] Students: Get Paid to work on thisproject(isthisstillthethread about high resolution printing??)

Tyler Mitchell (OSGeo) tmitchell at osgeo.org
Tue Apr 13 18:41:01 EDT 2010


Blender sure hasn't changed much :)  But if my children can handle it so 
can you!  I find it cumbersome for building design which is what I 
mainly wanted it for, but my 8 year old keeps showing me how easy it is 
for him ;-)  It's so deep and excellent I enjoy it for all our other 
design projects though.

I had a few pretty simple design projects that I tried also in Sketchup 
but guess that I need more tutorials because it was auto snapping way 
too much stuff together for me.  My last experience was thoroughly 
frustrating.  I was going from a 2D drawing of a 3 story building and 
once I got the 2nd story done, I got pretty stuck.  I'm sure that's 
mostly just me :)

On the proprietary side I just finished a 30 day trial of Revit 
Architecture - what a breath of fresh air.  A model-based app that 
understands what walls, doors, etc. are and allows them to be brought 
together really quickly.  My one child likes it better than Blender, so 
now I've got to find a good education discount ;-)

Tyler

On 04/13/2010 02:58 PM, Landon Blake wrote:
> Thanks for the suggestion Alex. It has been a couple years since I
> looked at Blender. I remember the user interface being sort of
> difficult, but maybe that has changed.
>
> I'm really focused on finding a good 3d-model/3d map viewer, more than I
> am on a 3D authoring tool.
>
> Maybe I need to give Blender another look. I am hopefully going to get
> some feedback on Blender from Tyler.
>
> Landon
> Office Phone Number: (209) 946-0268
> Cell Phone Number: (209) 992-0658
>
>
>
> -----Original Message-----
> From: carto-bounces at lists.osgeo.org
> [mailto:carto-bounces at lists.osgeo.org] On Behalf Of Alex Mandel
> Sent: Monday, April 12, 2010 5:51 PM
> To: carto at lists.osgeo.org
> Subject: Re: [Carto] Students: Get Paid to work on
> thisproject(isthisstillthethread about high resolution printing??)
>
> Blender is and open source option that can do some similar things as
> Sketchup and has potential to integrate with OSSIM(Both use
> Openscenegraph). I looked into it a couple of years back but didn't have
> time to pursue. Lot's of possibilities since it's python scriptable and
> is used for 3D animation, walkthroughs, video games etc.
>
> Alex
>
> Landon Blake wrote:
>> Bob,
>>
>> I just started looking into this myself the last few weeks. I'm really
> interested in learning how to use SketchUp to produce 3D models from our
> survey and engineering data. I did check out a 3D PDF generator plug-in
> for SketchUp. It worked, but it was a little crude. I almost think the
> viewer for Sketch-Up made by Google might be a better way to go.
>>
>> I'm going to work on an OBJ importer for SketchUp. Then I hope to
> write some AutoLISP code that will export simple drawing entities in OBJ
> format. I'll keep you posted as things develop.
>>
>> I'm still interested in open source alternatives for a 3D model
> viewer. Maybe World Wind might do the trick. I need to look into this
> more.
>>
>> Landon
>> Office Phone Number: (209) 946-0268
>> Cell Phone Number: (209) 992-0658
>>
>>
>> ________________________________________
>> From: Bob Basques [mailto:Bob.Basques at ci.stpaul.mn.us]
>> Sent: Tuesday, April 06, 2010 12:43 PM
>> To: Dane Springmeyer; Landon Blake; Tyler Mitchell (OSGeo)
>> Cc: carto at lists.osgeo.org
>> Subject: RE: [Carto] Students: Get Paid to work on
> thisproject(isthisstillthe thread about high resolution printing??)
>>
>> Landon,
>>
>> Didn't think it pertinent here, but I'm the CAD Manager at the City
> (85+ seats) for AutoDesk Products,  Lot and lots (and lots) of
> experience there.  Bit AutoLISP guy, lot's and lot's of Web service
> integration for our can users with respect to importing of data, raster
> and vector.
>>
>> Question, you got any experience with 3D-PDF generation, this is my
> new obsession recently.
>>
>> bobb
>>
>>
>>
>>>>> "Landon Blake"<lblake at ksninc.com>  wrote:
>> I suppose I should throw my capabilities out on the list as well. This
> may help us start to form teams as things get cooking.
>>
>> I'm pretty good with Java, OK with Python and Ruby, could learn C, and
> I am scared to death of C++. I can code CSS and XHTML.
>> I would like to learn Perl and Javascript. I've got some pretty
> extensive experience writing parsers. I work regularly with Inkscape and
> AutoCAD. I'm pretty familiar with those file formats. I've also know how
> to use some common Java libraries for working with DXF, SHP, and PDF.
>>
>> I'm certainly interested in cooking up at least part of the rendering
> engine as a desktop application in Java. I could use another language,
> but I've got a chunk of code in Java already.
>>
>> Landon
>> Office Phone Number: (209) 946-0268
>> Cell Phone Number: (209) 992-0658
>>
>>
>> ________________________________________
>> From: Bob Basques [mailto:Bob.Basques at ci.stpaul.mn.us]
>> Sent: Tuesday, April 06, 2010 11:58 AM
>> To: Dane Springmeyer; Landon Blake; Tyler Mitchell (OSGeo)
>> Cc: carto at lists.osgeo.org
>> Subject: RE: [Carto] Students: Get Paid to work on this
> project(isthisstill the thread about high resolution printing??)
>>
>> Landon (an others),
>>
>> I suppose I should throw out my personal preferences and  competencies
> here . . .
>>
>> I really like the idea of the print-canvas approach whether Web based
> (my preference initially) or desktop based.  Keep in mind that even the
> web based approach will require an "element" handler of some sort, which
> for the most part would likely end up inside of a desktop app.  My
> preference towards the Web route is mostly based on the notion that
> chunks of the process need to be separated out based on their respective
> functions, which makes things easier to hand off to the next guy, and to
> build components that are standalone(ish) in nature.
>>
>> I'm pretty good with PERL on the server side, along with lots or time
> spent in Databases of all sorts.  I'm basic on the web side, other than
> knowing where to look for the answers when I need them.  I'm no expert
> in JS for example, but have written my fair share, I'm better at finding
> and integrating the experts to make the whole work.  I'm also interested
> in other forms of client side interfaces like Flash for example.
>>
>> bobb
>>
>>
>>
>>>>> "Landon Blake"<lblake at ksninc.com>  wrote:
>> Bob,
>>
>> I'm not a web developer by any stretch of the term, so I didn't get
> everything in your message. I did however like the concept of a canvas
> where the user can assemble common layout elements. This sounds like a
> way to make map layout a no brainer. Whether this component of the
> map-making project was on the web or in a desktop app, I like it!
>>
>> I sort of think your white board or canvas component could almost be
> the visual editor for the input file that would specify the conversion
> parameters needed by the rendering engine.
>>
>> It sounds like one of our challenges will be finding common ground
> among our diverse group. We will have some web guys, some desktop guys,
> some Java guys, some Python guys...
>>
>> It sounds like we could at least get started on a spec. I wonder if we
> could create two "modules" in our project. One for a web app, and one
> for a desktop app. As we worked on the apps we could start talking about
> what each app would need the spec to look like. That would ensure a
> well-rounded spec.
>>
>> This is just a suggestion, of course.
>>
>> Landon
>> Office Phone Number: (209) 946-0268
>> Cell Phone Number: (209) 992-0658
>>
>>
>> ________________________________________
>> From: Bob Basques [mailto:Bob.Basques at ci.stpaul.mn.us]
>> Sent: Tuesday, April 06, 2010 11:42 AM
>> To: Dane Springmeyer; Landon Blake; Tyler Mitchell (OSGeo)
>> Cc: carto at lists.osgeo.org
>> Subject: RE: [Carto] Students: Get Paid to work on this project
> (isthisstill the thread about high resolution printing??)
>>
>> All,
>>
>> Well, basically, I've always thought along the lines of a Web app
> (engine) for the processing.  I'm a bit biased in this regard, but it
> shouldn't preclude building out a standalone version of some sort of
> engine either.
>>
>> Anyway on to the ideas.
>>
>> My thought was to use a print canvas sort of approach, where an online
> interface was used to assemble a print layout (could this be the
> specification side of the conversation so far) and send that to the
> engine for printing.  The reason I think  this user interface is
> important is more for the sales side of things, but I'm a big proponent
> of usability, and push/drag system on a web based whiteborad sort of
> interface seems like the right way to go.
>>
>> Using a URL based (raster images would be a good start) approach to
> collecting print elements seems like a no brainer, where a separate web
> based engine could handle URL collection duties for display in the Print
> canvas, and the user has all the tools needed in the interface to push,
> drag, scale, etc, and in a visual form.  Using the Print Canvas
> approarch will allow for a very strict method of pushing the elements to
> the rendering engine as well.  It will act as a sort of pre-rendering
> filter of sorts.
>>
>> It may sound like I'm trying to jump to the end before doing the
> middle, but I've been thinking about this a for a few years and even did
> some early concept work once upon a time.
>>
>> The bigger benefit I see to this approach (and still keeping inside of
> the ideas discussed) is that things can be implemented in phases, raster
> first, vector (3D??), and the input and rendering are completely
> separated with regard to development streams.  If a project want to use
> the print canvas engine to render directly, they can, or let the users
> interact with the layout instead, either will work just fine.
>>
>> I don't believe that this things need to get hung up on the
> specification side too much either, most elements would/could be
> collected via a URL resource for example, and already be in some sort of
> standard form.   The new stuff for layout, can be integrated into this
> new print canvas / render engine and stay project specific, right?
>>
>> So, am I rambling, or does any of this make sense?
>>
>> bobb
>>
>>
>>
>>>>> "Landon Blake"<lblake at ksninc.com>  wrote:
>> I shared my ideas Bob. Let's hear about your approach.
>>
>> Landon
>> Office Phone Number: (209) 946-0268
>> Cell Phone Number: (209) 992-0658
>>
>>
>> ________________________________________
>> From: carto-bounces at lists.osgeo.org
> [mailto:carto-bounces at lists.osgeo.org] On Behalf Of Bob Basques
>> Sent: Tuesday, April 06, 2010 11:24 AM
>> To: Dane Springmeyer; Tyler Mitchell (OSGeo)
>> Cc: carto at lists.osgeo.org
>> Subject: Re: [Carto] Students: Get Paid to work on this project
> (isthis still the thread about high resolution printing??)
>>
>> All,
>>
>> Is this still the thread about high resolution printing?
>>
>> If so, I have a different approach that might be worth offering. . . .
>>
>> bobb
>>
>>
>>
>>>>> "Tyler Mitchell (OSGeo)"<tmitchell at osgeo.org>  wrote:
>> Dane Springmeyer wrote:
>>> Because there is not a third student focusing on the OSGEO side I
> think
>>> was is not being addressed is the interoperability/standards
>>> specification piece. Big picture this is likely better addressed
> outside
>>> of a code-based GSOC project and rather by the wider community.
>>
>> I think you're hitting the nail on the head here.  With my "user of
>> several apps" hat on, I mainly care about the specifications side of
>> things.  Knowing that any "engine" app is already going to be focused
> on
>> improving quality, features, etc. the question from a larger, OSGeo
>> ecosystem perspective does really fall into the standards doesn't it?
>>
>> What I would like to avoid is inventing a new spec, only to find that
>> another app already has a well thought out model in place.  I'd much
>> rather clone an existing model, API, whatever and then see what is
>> missing from our overall needs.  I'm most familiar with MapServer's
>> model, but was able to get a good glimpse into Mapnik when playing
> with
>> Quantumnik.  That kind of interoperability in a client app is quite
>> encouraging to see.
>>
>> In the end, I'd like to take Application X and transform its config
>> files into the engine's model.  Thereby making this project also a bit
>> of a universal translator.. but I think I'm getting ahead of myself.
> :)
>>
>> So, how do we get a good handle on potential specs to work from?  I
>> broke it down into three components:
>> * rendering stuff
>> * map layout details
>> * output formats/resolution etc.
>>
>>
>> Tyler
>> _______________________________________________
>> Carto mailing list
>> Carto at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/carto
>>
>>
>> Warning:
>> 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.
>> _______________________________________________
>> Carto mailing list
>> Carto at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/carto
>> _______________________________________________
>> Carto mailing list
>> Carto at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/carto
>
> _______________________________________________
> Carto mailing list
> Carto at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/carto
>
>
> Warning:
> 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.
> _______________________________________________
> Carto mailing list
> Carto at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/carto



More information about the Carto mailing list