|
From: Miles P. <mil...@gm...> - 2008-06-14 19:36:21
|
Very cool, thanks guys! I didn't realize that geotools provided such a
nice high-level wrapper.
I think I have some fiddling time next week so I'll see what I can
whip up. You should be able to get POJOs, Repast, Ascape, Interfaces,
Test Cases, from that.
One question perhaps for Nick that I forgot.. is there anything in
the .rs .xml, especially display xmls that could help to set up a nice
basic initial graphic setup -- I mean in terms of say spatial
resolution, gird, other hints like that.. I prob. won't get to tha one
right away, but again if there is a nice example for something that
works well.
I'm not sure what if any other metadata is buried in the shape file.
Does it make any sense for example to try to pull basic colors out of
the shape file? Again, for later but we could pretty easily create
default styles that again could be used to setup the right colors for
the visualization.
On Jun 13, 2008, at 2:39 AM, Dave Murray-Rust wrote:
> Hi Miles, Nick,
>
> I haven't looked into metaABM yet, so I'm not certain whether it
> would work for our organisational needs (although I think it's a
> tremendously exciting idea!). In the mean time, I can happily give
> you my shapefile parsing code (which simply pulls attribute names
> and types out of a shapefile), and the code fragments I have in my
> ContextBuilder relating to reading the shapefiles.
>
> My ContextBuilder stuff is very simple; after creating appropriate
> geographies, I have a block to load each shapefile, e.g.:
>
> GeographyParameters geoParams = new GeographyParameters();
> Geography geography =
> GeographyFactoryFinder
> .createGeographyFactory( null ).createGeography( "Geography",
> context, geoParams );
> try
> {
> File file = new File( "data/Farms_All2.shp" );
> ShapefileLoader loader = new ShapefileLoader<Farm>( Farm.class,
> file.toURL(), geography, context );
> while ( loader.hasNext() )
> {
> Farm farm = (Farm) loader.next();
> //Callback point
> System.out.println( "Got a farm: " + farm + ": " +
> farm.getFARM() );
> }
> } catch (Exception e)
> {
> System.err.println( "Problem loading farms: " + e );
> e.printStackTrace();
> }
>
> My parser is attached, again it's very simple.
>
> I think what I'll do right now is create a simple eclipse plugin
> which generates POJOs from shapefiles, and then hope that I can
> convert myself and everyone to metaABM. If there's anything useful I
> can do for the metaABM development I'll be interested, and I'll
> definitely take up the offer of metaABM mentoring if it looks like a
> good option for what we want to do.
>
> Thanks very much for suggestions and support!
>
> Cheers,
> dave
>
> On 11 Jun 2008, at 21:22, Miles Parker wrote:
>
>>
>> Guys, this is _exactly_ what the .score system was originaly
>> designed to do, and what the metaABM system provides. There is a
>> direct mapping from metaABM -> score, so you can do all of your
>> work in metaabm and then use the older score representation as an
>> intermediate step. metaABM also generates all the basic descriptors
>> and so on for the model.rs directory. We use the
>> openArchitectureWare system which is becoming part of the core
>> Eclipse environment and is extremely powerful, flexible and robust,
>> though arguably not quite as easy to tweak as velocity. It is a
>> simple set of plugins with dependencies on just the oAW plugins.
>>
>> The idea behind score/metaabm is to have an intermediate
>> representational layer between various artifacts, design tools,
>> languages, etc.. and various targets such as Simphony, other ABM
>> platforms, specialized systems, etc.. metaABM already generates
>> complete Simphony models from the high-level representation, You
>> also get HTML docs generated automatically (Tom H. did the first
>> run at this). We also provide a "Method" construct that allows one
>> to insert Java code into the skeleton from the model. With the 1.1
>> release which I am about to announce to this list :), there is much
>> better support for protected regions and generation of skeleton
>> structures, so that you can use the metaABM behavior
>> representations and/or your own implementations.With the Metascape
>> IDE, you can even create JUnit test case stubs, Interfaces, etc...
>>
>>
>> All of that is to suggest a course of action that I was really
>> hoping to be able to do but had no hope of getting to in the short
>> term -- that is a key part of what you suggest; getting shape files
>> into the metaABM system automatically. If one could do that, you'd
>> have the code generation part done 'for free'.
>>
>> I have already done such a thing to import arbitrary Java and class
>> files, so the basic approach is sketched out. The Ecore framework
>> which MetaABM is built upon provides that ability to very easily
>> programmatically define models, which are then persisted, just as
>> if a use had created them. For example to create an attribute, you
>> just do:
>>
>> SAttribute attr = MetaABMFactory.eINSTANCE.createSAttribute();
>> ...
>> agent.getAttributes().add(attr);
>>
>> What is missing is the part that gets the metadata from the shape
>> files. I also have to do some work on the GIS target for Simphony
>> side. What I can offer is...
>>
>> If you can get together the basic code to parse the Shape file
>> parsed, I can build the metaABM part, and integrate it into the IDE.
>> If you can identify any missng pieces from the GIS part of the
>> existing metaabm design I can add them into the metadata model.
>> If you can get together a general pseudo-code representation of
>> what the Context builder part should look like, I can update the
>> template to match.
>>
>> This wouldn't take a whole lot of time and would add a _lot_ of
>> capability. Whaddya think?
>>
>>
>> SO the basic idea would be
>>
>> On Jun 11, 2008, at 9:18 AM, Dave Murray-Rust wrote:
>>
>>> Nick,
>>>
>>> Great, I've used velocity previously, so that sounds good.
>>>
>>> I'm thinking of explicitly generating source files from shapefiles
>>> rather than on the fly geneneration for exactly the reasons you
>>> give -
>>> it's much easier for code completion etc.
>>>
>>> I was thinking that it might make sense to create abstract classes
>>> which were then subclassed to add functionality, so that if
>>> shapefiles
>>> change and regeneration is necessary, it's relatively easy to keep
>>> the
>>> handwritten code separate, although this does reduce the
>>> possibilities
>>> for inheriting other functionality. I'll have a play around and see
>>> what seems sensible.
>>>
>>> Cheers,
>>> dave
>>>
>>>
>>> On 11 Jun 2008, at 16:27, Nick Collier wrote:
>>>
>>>> Dave,
>>>>
>>>> I think this is very good idea. We haven't planned on implementing
>>>> such a thing. How are you thinking of this? A utility that
>>>> generates
>>>> the java source from a shapefile, or something more complicated? If
>>>> you are thinking about generating java source then you might want
>>>> to
>>>> look at the velocity template engine. We use this in simphony
>>>> already. With it you can define templates, like:
>>>>
>>>> #foreach($prop in $properties)
>>>> public $prop.type get{$prop.name}() {
>>>> ...
>>>> }
>>>>
>>>> ...
>>>> #end
>>>>
>>>> then you pass the velocity the template and in this case your
>>>> properties and it will generate the file for you.
>>>>
>>>> See http://velocity.apache.org/engine/devel/user-guide.html for
>>>> more.
>>>>
>>>> If you want to do more complicated on the fly class / object
>>>> creation, we use javaassist for that:
>>>>
>>>> http://www.csg.is.titech.ac.jp/~chiba/javassist/
>>>>
>>>> The on the fly generation becomes more complicated in that the
>>>> class
>>>> won't exist at compile time, so if you refer to these agents in
>>>> your
>>>> code and expect it to compile the agent's type will have to be some
>>>> interface or something that is known at compile time.
>>>>
>>>> As for packaging / distribution, if its the former source code
>>>> generator then I think a stand alone utility that we would be happy
>>>> to include with repast and link to on the website would be
>>>> excellent.
>>>>
>>>> Nick
>>>>
>>>>
>>>> On Jun 11, 2008, at 11:03 AM, Dave Murray-Rust wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've just been creating some agents from shapefiles, and while in
>>>>> general it's great that this is possible, it gets a little fiddly
>>>>> creating all the correct parameters for the agents matching the
>>>>> parameters in the shapefile (I spent a few hours debugging the
>>>>> fact
>>>>> that an ID was a long in one file and an int in another etc). It
>>>>> seems
>>>>> like it should be relatively easy to create a code generation
>>>>> utility
>>>>> which takes a shapefile and spits out agent classes.
>>>>>
>>>>> Before I get into this, though, I'd like to make sure that any
>>>>> work I
>>>>> do is as useful as possible, so I'm wondering:
>>>>>
>>>>> - Would this be useful to other people?
>>>>> - Is it something that the core team are planning?
>>>>> - How would you like to see it implemented? I guess the most
>>>>> natural
>>>>> solution would be addition to the repast plugin, but there is also
>>>>> the
>>>>> possibility of a standalone plugin, batch scripts etc.
>>>>> - How much use for relational concepts would people have, such as
>>>>> being able to say "The ownerID in this shapefile relates to the
>>>>> ID in
>>>>> this other shapefile" and have links automatically created when
>>>>> shapefiles are loaded?
>>>>> - Is there a particular code generation strategy or tool which
>>>>> would
>>>>> fit well with RepastS?
>>>>> - If the best answer is to extend the RepastS plugin, is this
>>>>> possible, and are there any docs which would help me get started?
>>>>>
>>>>> Thanks for any suggestions!
>>>>>
>>>>>
>>>>> --
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> Check out the new SourceForge.net Marketplace.
>>>>> It's the best place to buy or sell services for
>>>>> just about anything Open Source.
>>>>> http://sourceforge.net/services/buy/index.php
>>>>> _______________________________________________
>>>>> Repast-interest mailing list
>>>>> Rep...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>>
>>>>
>>>
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Repast-interest mailing list
>>> Rep...@li...
>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>
>>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
|