mgis-develop — core developer mailing list

[Mgis-develop] How to access specific shapefile records?

[<sha...@co...>]

Hello all,

I don't know if this list is active or not, but I have just stumbled on MonoGIS.  I have been in need of a stable and efficient means of accessing shapefiles using c# and this seems to be quite powerful with spatial indexes and advanced geometry comparison methods.

My issue is that I need a means of accessing shapefile records without a full file scan.  Is there a means of doing this and avoiding the creation of intermediate indexed files in the process?  My experience with shapelib is python based and I know that it is possible to access records by index, I just cannot figure out how in MonoGIS.

Thanks,

Shawn
Sent via BlackBerry by AT&T

Re: [Mgis-develop] My hello world here

[Michael P. <mp...@gm...>]

Hi Martin,

sorry for responding so late. Your offer is very interesting, however this
year I decided to concentrate fully on my current job. So, I really have not
much time left to spent on monoGIS. There are other projects, like SharpMap,
which have a more active development right now. I would suggest to enter
that comunity. As I have seen that you like GTK you may also want to contact
Scott Ellington, the main developer of Appomattox (
http://salmonsalvo.net/Appomattox).
If you are still interested in developing on top of monoGIS I may see to
give you SVN access and some support via mail.

Kind regards,

Michael.
2008/5/20 martin (OpenGeoMap) <ma...@op...>:

> Hi all:
>
> I would like  join to monogis project.
>
> I am a land surveyor from Madrid working in a technology departament
> from a photogrammetry and lidar company (stereocarto.com).
> In the company i am working all day with ruby, c#, visual basic, c++, ....
> My task in the company is changing for only use  c#/mono/.NET/COM,
> microstation, ARCgis and autocad APIs.
>
>
>
> I have experience in GTK+ using the C API. My project in my university
> was a complete software for land surveying.
>
> I have experience in gtkmm, ruby/gnome, and i am begining with GTK# and
> VALA.
>
>
> I want learn and perhaps contribute here.
>
> My first step was take a look your source code, and i like it very much.
>
> Things i can contribute in the future here :
>
> - Mono/gtk#
> -.NET/winforms
> - opengl/directx
> - projections,  coordinate systems, etc,...
> - Orient object programming
>
> My tools are:
> - Visual Studio 2005
> - Monodevelop 1.0
>
> --
> If you need a religion perhaps you can choose GTK:
> http://www.gtk.org/language-bindings.html
> http://live.gnome.org/GnomeLove
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mgis-develop mailing list
> Mgi...@li...
> https://lists.sourceforge.net/lists/listinfo/mgis-develop
>

[Mgis-develop] My hello world here

[martin (OpenGeoMap) <ma...@op...>]

Hi all:

I would like  join to monogis project.

I am a land surveyor from Madrid working in a technology departament 
from a photogrammetry and lidar company (stereocarto.com).
In the company i am working all day with ruby, c#, visual basic, c++, ....
My task in the company is changing for only use  c#/mono/.NET/COM,  
microstation, ARCgis and autocad APIs.



I have experience in GTK+ using the C API. My project in my university 
was a complete software for land surveying.

I have experience in gtkmm, ruby/gnome, and i am begining with GTK# and 
VALA.


I want learn and perhaps contribute here.

My first step was take a look your source code, and i like it very much.

Things i can contribute in the future here :

- Mono/gtk#
-.NET/winforms
- opengl/directx
- projections,  coordinate systems, etc,...
- Orient object programming

My tools are:
- Visual Studio 2005
- Monodevelop 1.0

-- 
If you need a religion perhaps you can choose GTK:
http://www.gtk.org/language-bindings.html
http://live.gnome.org/GnomeLove

Re: [Mgis-develop] plz help me

[mina y. <ya...@gm...>]

On 12/20/07, mina yaychi <ya...@gm...> wrote:
>
> Hi, i work in GIS field. In my project i study opensource tools for
> example (Sharpmap, monoGIS,NTS,... ), now i want known that all subfunctions
> algorithm for example: algorithm for convert spatial reference, algorithm
> for simplify geometry, ... . Is there one document for this purpose.
>
> thankx
>

[Mgis-develop] plz help me

[mina y. <ya...@gm...>]

Hi, i work in GIS field. In my project i study opensource tools for example
(Sharpmap, monoGIS,NTS,... ), now i want known that all subfunctions
algorithm for example: algorithm for convert spatial reference, algorithm
for simplify geometry, ... . Is there one document for this purpose.

thankx

[Mgis-develop] WFS Client

[Nate J. <n8...@gm...>]

Hello All,
I have been looking at writing an OGC WFS client and I've been looking for
some good open source libraries to help me in that endeavor.  I really like
the way MonoGIS is designed and implemented, but I have not seen any WFS
client support in it.  I was wondering if it is possible that I have
overlooked this or if anyone out there has done any work with MonoGIS and
WFS.  I did notice the GMLReader class and I can see how that could be very
useful in implementing a WFS client, but I haven't seen any fuller support.
Thanks in advance for all the help.  This really is a quite impressive
library.
~Nate Jones

Re: [Mgis-develop] About MonoGIS

[Paul, M. <mic...@ta...>]

Hi,
 
this type of question is always difficult to answer. I will try to give my
personal and somewhat biased point of view:
- both projects are open-source and implemented in C#. 
- SharpMap has been almost entirely designed and programmed by Morten
Nielsen, who is working at ESRI since end of 2006. To my knowledge he is not
involved any more in the day-to-day development of SharpMap. But there
exists are small but strong developer comunity which keeps developing new
versions and provides excellent documentation and support. So, SharpMap is
still moving on and improving each month or so,
- MonoGIS has been developed by TAO, a small spanish software company, not
by one particular person. 
- MonoGIS itself does count neither with thorough documentation, nor with a
stable developer comunity providing support for newbies or interested
persons. 
- one has to understand that for our company MonoGIS just represents the
core technology which is necesarry to implant the added-value projects a
customer is willing to pay for. Therefore, it constantly invests into
MonoGIS adding new functionality and providing support for its own
customers. But it certainly will not invest in providing end-user support or
driving a big developer comunity. To T-Systems MonoGIS is a high-quality
tool which is necessary to implant its added-value projects a customer is
willing to pay for. Answering emails and forum posts is something that is
within the main interest of our company (MonoGIS is not sold) and it depends
on some individuals. The time necessary for this is usually not included
within our work time and so do not expect too much support if you have any
doubts.
- MonoGIS is currently installed int about 40-45 production environments
(web applications), I have no clue how many installation SharpMap does have
but I would think that the number will be significantly smaller.
- to some extent, MonoGIS includes a richer feature set than SharpMap (e.g.
write-support, certified OGC WMS server, etc.). To be fair, the upcoming
SharpMap 2.0 minimizes this particular difference and I even expect that
SharpMap may overcome the MonoGIS funcionality in the future.
 
To keep it in a nutshell, if you are a student, newbie to GIS and C# or
simply poking around with new technologies I would strongly encourage you to
use SharpMap. It's community shall guide you with any problems you have and
there are also available various tutorials and getting started documents. If
you are searching for an open-source GIS library suitable to be used within
your professional projects at work, I would suggest to consider MonoGIS. The
already existing installations significate a guarantee to anyone that
MonoGIS won't disappear during the next years (not talking about robustness
or maintainability). Certainly, you will have to be prepaired to a big
learning curve at the beginning as you will have to answer many questions
yourself, studying the source code itself. Nevertheless, regarding to myself
I can only say we still are seeing only the advantages of having developed
and using MonoGIS within our own company in respecto to using other existing
solutions such as MapGuide Open Source, MapServer or similar.
 
Finally, I use to terminate this type of mails with the encouragement to
anyone to carefully analyze and find the best solutions that fits his
particular needs. There is not any solution out there that fits all possible
needs, even more if it is an open-source solution. May be, existing SharpMap
or MonoGIS versions fit your needs, may be finally you decide to use another
solution based on a different technology (like geoserver). If you are
working in a big software project, the most probable thing is that you find
out that you'll have to enhance some of the already existing libraries like
GeoTools, SharpMap or MonoGIS to fit all of your needs. As I already know
perfectly MonoGIS, I usually tend to further enhance MonoGIS. May be you'll
find out the same. If this case remember the open-source character of
MonoGIS and if you implement any enhancements to either of the mentioned
open-source projects please be so kind to provide all of us with these. 
Not too much time ago I got to know a very interesting project, which copied
MonoGIS' source code to implement a new, somewhat cleaner library. At that
time, everyone just was interested in finishing his particular work and move
on with life. That provided to be big error, as this way the library formed
part of a bigger project implemented in a closed-source environment and now
even is intelectual property of some company. The funny thing is that the
same people which made these changes now work on a similar project for a
competing company of the first one. So, what will they have to do? Copy
source-code, making some minor changes, adding new functionality and:
copying the same limitations and bugs of the first implementation. When we
originally published MonoGIS we hoped that these things ended, but as you
see most people erroneously associate open-source with free (of costs).

Michael Paul
---------------------------------------------------------- 
T-Systems ITC Iberia 
d-Core: Architecture & Innovation
Systems Integration 
---------------------------------------------------------- 

 

  _____  

De: Faihou Che [mailto:fai...@gm...] 
Enviado el: lunes, 13 de agosto de 2007 5:53
Para: mp...@us...
Asunto: About MonoGIS



Hi mpaul

 

Both "mono GIS" and "Sharp Map" are open source project.  What are the
advantages of mono GIS on Sharp Map?

 

Best regards

 

Faihou

8/13/2007

Re: [Mgis-develop] [Fwd: [PATCH] QuadTree indexing support]

[Scott E. <sco...@gm...>]

Hi All,

As an FYI, this QuadTree is not working correctly.  It is producing
incorrect results and I don't have the time right now to debug it.

Scott

On Thu, 2006-08-31 at 12:08 +0000, Scott Ellington wrote:
> Here is a link to the patch as it is blocked for being too big:
> 
> http://salmonsalvo.net/upload/monoGIS.quadtree.patch
> 
> ---ORIGINAL MESSAGE---
> 
> Hello,
> 
> Attached is a very large patch which includes a port of SharpMap's
> QuadTree class.  I had to rework things a little to make room for it.
> The IndexedDataProvider stuff still defaults to RTree, but you can
> change it to QuadTree by setting the DefaultIndexType property.
> 
> A note on performance:
> 
> The building of the index is substantially faster with QuadTree, but
> searching for intersections is slower than RTree.
> 
> RTree:
> 
> Indexing: 32.862842s
> Drawing: 22.549744s
> 
> QuadTree:
> 
> Indexing: 6.784629s
> Drawing: 33.364306s
> 
> (source data: http://www.tngis.org/coverages/303d_streams.zip )
> 
> So for Appomattox, QuadTree is a better fit.  While, web apps may prefer
> RTree. 
> 
> Additional Notes:
> 
> - I have not tested with web caching
> - I also moved all indexing stuff into an Indexing namespace in
> MonoGIS.Spatial
> 
> please review and commit.  thanks,
> Scott

Re: [Mgis-develop] Shapefile loading comparisons

[Scott E. <sco...@gm...>]

Hi Michael,

No it does not.  That could be an issue as well.  But consider that the
SHPLib provider took 33 seconds while the managed SHP provider took 110.
They both load the same data into NTS at substantially different
performance.

Scott

On Thu, 2006-09-07 at 10:31 +0200, Michael Paul wrote:
> Hi Scott, 
> 
> just one question: 
> the SharpMap performance test included the conversion from SharpMap
> geometries to NTS geometries? I mention this as we identified various
> performance bottlenecks within NTS geometry creation. 
> 
> Regards,
> 
> Michael.
> 
> 2006/9/1, Scott Ellington <sco...@gm...>:
>         Hi all,
>         
>         In my continuing quest to improve performance in Appomattox
>         (and thus
>         monoGIS), I have turned my attention to loading of Shapefiles.
>         
>         Firstly, I have created a web page for documenting performance
>         issues 
>         within monoGIS:
>         
>         http://www.appomattox-project.org/MonoGIS_Performance_Considerations
>         
>         Now that I have addressed the slowness of spatial indexing, I
>         have made 
>         my way to the loading of the Shapefile data into monoGIS
>         geometries.
>         Currently, Appomattox loads all shapefile data directly into
>         memory
>         during loading.  This provides good performance later on but
>         is a hit in
>         the beginning.
>         
>         In the above page, I document some tests on loading data with
>         monoGIS's
>         shapefile providers vs. SharpMap's.  To summarize the results:
>         SharpMap's is almost 3 times faster than monoGIS's SHPLib and
>         more than 
>         8 (!) times faster than monoGIS's managed SHP provider.
>         
>         >From this, I suggest monoGIS port SharpMap's provider, and
>         eventually
>         remove the current SHP providers.  I will look into this as
>         time
>         permits.
>         
>         more to come,
>         Scott
>         
>         
>         -------------------------------------------------------------------------
>         Using Tomcat but need to do more? Need to support web
>         services, security?
>         Get stuff done quickly with pre-integrated technology to make
>         your job easier 
>         Download IBM WebSphere Application Server v.1.0.1 based on
>         Apache Geronimo
>         http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>         _______________________________________________
>         Mgis-develop mailing list
>         Mgi...@li...
>         https://lists.sourceforge.net/lists/listinfo/mgis-develop
> 

[Mgis-develop] Shapefile loading comparisons

[Scott E. <sco...@gm...>]

Hi all,

In my continuing quest to improve performance in Appomattox (and thus
monoGIS), I have turned my attention to loading of Shapefiles.  

Firstly, I have created a web page for documenting performance issues
within monoGIS:

http://www.appomattox-project.org/MonoGIS_Performance_Considerations

Now that I have addressed the slowness of spatial indexing, I have made
my way to the loading of the Shapefile data into monoGIS geometries.
Currently, Appomattox loads all shapefile data directly into memory
during loading.  This provides good performance later on but is a hit in
the beginning.

In the above page, I document some tests on loading data with monoGIS's
shapefile providers vs. SharpMap's.  To summarize the results:
SharpMap's is almost 3 times faster than monoGIS's SHPLib and more than
8 (!) times faster than monoGIS's managed SHP provider.

>From this, I suggest monoGIS port SharpMap's provider, and eventually
remove the current SHP providers.  I will look into this as time
permits.

more to come,
Scott

[Mgis-develop] [Fwd: [PATCH] QuadTree indexing support]

[Scott E. <sco...@gm...>]

Here is a link to the patch as it is blocked for being too big:

http://salmonsalvo.net/upload/monoGIS.quadtree.patch

---ORIGINAL MESSAGE---

Hello,

Attached is a very large patch which includes a port of SharpMap's
QuadTree class.  I had to rework things a little to make room for it.
The IndexedDataProvider stuff still defaults to RTree, but you can
change it to QuadTree by setting the DefaultIndexType property.

A note on performance:

The building of the index is substantially faster with QuadTree, but
searching for intersections is slower than RTree.

RTree:

Indexing: 32.862842s
Drawing: 22.549744s

QuadTree:

Indexing: 6.784629s
Drawing: 33.364306s

(source data: http://www.tngis.org/coverages/303d_streams.zip )

So for Appomattox, QuadTree is a better fit.  While, web apps may prefer
RTree. 

Additional Notes:

- I have not tested with web caching
- I also moved all indexing stuff into an Indexing namespace in
MonoGIS.Spatial

please review and commit.  thanks,
Scott

[Mgis-develop] [Fwd: [PATCH] QuadTree indexing support]

[Scott E. <sco...@gm...>]

Here is a link to the patch as it is blocked for being too big:

http://salmonsalvo.net/upload/monoGIS.quadtree.patch

[Mgis-develop] [PATCH] QuadTree indexing support

[Scott E. <sco...@gm...>]

Hello,

Attached is a very large patch which includes a port of SharpMap's
QuadTree class.  I had to rework things a little to make room for it.
The IndexedDataProvider stuff still defaults to RTree, but you can
change it to QuadTree by setting the DefaultIndexType property.

A note on performance:

The building of the index is substantially faster with QuadTree, but
searching for intersections is slower than RTree.

RTree:

Indexing: 32.862842s
Drawing: 22.549744s

QuadTree:

Indexing: 6.784629s
Drawing: 33.364306s

(source data: http://www.tngis.org/coverages/303d_streams.zip )

So for Appomattox, QuadTree is a better fit.  While, web apps may prefer
RTree. 

Additional Notes:

- I have not tested with web caching
- I also moved all indexing stuff into an Indexing namespace in
MonoGIS.Spatial

please review and commit.  thanks,
Scott

[Mgis-develop] Spatial Indexing: SharpMap vs. monoGIS

[Scott E. <sco...@gm...>]

Hi,

I got the latest release of SharpMap working on Linux to do some
performance comparisons on their spatial indexing vs. monoGIS's.  Below
are the results:

(Note: I used MonoGIS's SHPLib Provider because I got an exception on
this data using SHP which I logged as a bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1548192&group_id=111827&atid=660537 )

Test 1) midsized shapefile (18038 polygons)

data: ftp://ftp.dep.state.fl.us/pub/gis/data/countyshore_areas.zip

SharpMap: 2.3s
monoGIS: 9s

Test 2) larger shapefile (56581 lines)

data: http://www.tngis.org/coverages/303d_streams.zip

SharpMap: 6.2s
monoGIS: 28s

As you can see, there is a difference in performance.  The performance
penalty with monoGIS becomes more severe with more shapes.

Now there may be some inefficiencies in monoGIS's indexing, or it could
just be that a QuadTree is just faster than an RTree.  As time provides,
I am going to look into moving this code into monoGIS.

thanks,
Scott

[Mgis-develop] various notes

[Scott E. <sco...@gm...>]

Hi Michael,

I got around to working with the files you released for monoGIS 0.7.
Here are a few comments:

1) the binary release
(http://prdownloads.sourceforge.net/mgis/monoGIS-bin-0.7.zip?download )
does not include the monoGIS.dll.config file for Linux users.

as for the WMS Sample,

2) In WMS.aspx, the namespace 'monoGIS' needs to be capitalized (linux
case-sensitivity):

<%@ Page Language="C#" Inherits="MonoGIS.OGC.WMS.WMS" %>

3) In wms.config, attribute 'width' for element 'Layer' is of type
'int', while in DisplayStyle.LineStyle, Width is a float.  I believe the
wms attribute should be a float as well.  This causes problems for
Appomattox's 'Publish to WMS' command because we create the wms.config
file and set the width to something like '0.5'.  Thus, it doesn't work.

4) in the WMS sample, you include Geotools.dll and NetTopologySuite.dll
in the bin/ directory.  Since those are no longer used, you can remove
them and lessen the download by almost 1MB.

5) I noticed you had a tool in this called monoGIS.Converter.exe.  I
think it would be worthwhile to include this in the main monoGIS
distribution as it seems handy.

After I got WMS working, I noticed one thing:  The WMS map will be
distorted if the image extents are not the same ratio as the map
extents.  That is, say the map's ratio of width to height is 2:1, then
the image must be the same.  For example, take a look at the two
attached images.  One is from appomattox the other WMS.  Notice how the
wms one is scrunched up.

I'm not sure how this fits in with the WMS standard, but I have some
code in Appomattox.Map (in the Extents.Set property) which adjusts the
Extents Envelope to fit the ratio of the image if you want to use that.

Scott

[Mgis-develop] depictors page

[Scott E. <sco...@gm...>]

Hello,

Since the monoGIS wiki has gone the way of the dinosaurs, I have rescued
the proposal I wrote for depictors from Google cache and loaded it into
the Appomattox wiki:

http://www.appomattox-project.org/MonoGIS_Depictors

Scott

Re: [Mgis-develop] monoGIS 0.8 Wishlist

[Scott E. <sco...@gm...>]

Oh I built it a while back :)

I had to patch a couple of things to get it working and I sent those to
Morten who promptly committed them.  If you look at the FAQ
(http://sharpmap.iter.dk/faq.aspx#2b ), I think I'm the guy who made the
"reports".

The basics worked, but I did not test everything.

Scott 

On Mon, 2006-08-21 at 17:57 -0400, Abe Gillespie wrote:
> I haven't heard anyone trying to build the entire thing with Mono yet.
>  You might be the first!  I'm not sure how easy it'll be as it relies
> heavily on .Net 2.0.  I thought maybe just yanking the ShapeFile.cs
> code would help you.
> 
> Good luck!
> -Abe
> 
> On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> > Hey,
> >
> > Yeah I mentioned that to Michael.  He went ahead and based the monoGIS
> > provider off the one that comes in NetTopologySuite.  At least part of
> > the problem is the spatial indexing speed issue I mentioned, but I am
> > convinced we can load the data from the file faster than we are.
> >
> > I can't comment if the SharpMap implementation is faster, it is tough
> > getting it building on Mono/Linux.
> >
> > thanks,
> > Scott
> >
> > On Mon, 2006-08-21 at 15:46 -0400, Abe Gillespie wrote:
> > > Hey Scott,
> > >
> > > Concerning bullet 2 - I've been using SharpMap lately.  There is a
> > > completely managed ShapeFile reader in the project.  Check out the
> > > source for /Data/Providers/ShapeFile.cs.
> > >
> > > Hope that helps.
> > > -Abe
> > >
> > > On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> > > > Hi,
> > > >
> > > > The purpose of this email is to document the improvements that I would
> > > > like to see in the next version of monoGIS.
> > > >
> > > > As I have learned, the two most important issues to me are the two major
> > > > priorities of the next release: rendering performance and depictors.
> > > > For those of you who don't know, depictors will be a new mechanism for
> > > > describing the display of data (i.e. symbology).  It should allow
> > > > complex symbology and theming.
> > > >
> > > > Other things:
> > > >
> > > > 1) Spatial Indexing Performance:
> > > >
> > > > Creation of spatial indexes is still somewhat slow.  Larger datasets
> > > > (i.e. > 50MB) can sometimes take many minutes.  I think by profiling we
> > > > can optimize this.  uDig and mapserver both have speedy spatial
> > > > indexing, perhaps we can learn something by examining how they do it.
> > > >
> > > > 2) Managed SHP Provider
> > > >
> > > > This is not a high priority, but it would be nice to be able to switch
> > > > to the managed SHP provider and be able to drop the SHPLib dependency.
> > > > For this to happen we would need to improve the performance of loading
> > > > data.  As I documented in a previous email, there is a substantial drop
> > > > as compared to SHPLib.
> > > >
> > > > 3) new Data Provider: GIS Web Services?
> > > >
> > > > I don't know a lot about this technology or the standards, but if there
> > > > exists a way to access GIS data from web services, that would be nice to
> > > > have.
> > > >
> > > >
> > > > -------------------------------------------------------------------------
> > > > Using Tomcat but need to do more? Need to support web services, security?
> > > > Get stuff done quickly with pre-integrated technology to make your job easier
> > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > > _______________________________________________
> > > > Mgis-develop mailing list
> > > > Mgi...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mgis-develop
> > > >
> >
> >

Re: [Mgis-develop] monoGIS 0.8 Wishlist

[Abe G. <abe...@gm...>]

I haven't heard anyone trying to build the entire thing with Mono yet.
 You might be the first!  I'm not sure how easy it'll be as it relies
heavily on .Net 2.0.  I thought maybe just yanking the ShapeFile.cs
code would help you.

Good luck!
-Abe

On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> Hey,
>
> Yeah I mentioned that to Michael.  He went ahead and based the monoGIS
> provider off the one that comes in NetTopologySuite.  At least part of
> the problem is the spatial indexing speed issue I mentioned, but I am
> convinced we can load the data from the file faster than we are.
>
> I can't comment if the SharpMap implementation is faster, it is tough
> getting it building on Mono/Linux.
>
> thanks,
> Scott
>
> On Mon, 2006-08-21 at 15:46 -0400, Abe Gillespie wrote:
> > Hey Scott,
> >
> > Concerning bullet 2 - I've been using SharpMap lately.  There is a
> > completely managed ShapeFile reader in the project.  Check out the
> > source for /Data/Providers/ShapeFile.cs.
> >
> > Hope that helps.
> > -Abe
> >
> > On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> > > Hi,
> > >
> > > The purpose of this email is to document the improvements that I would
> > > like to see in the next version of monoGIS.
> > >
> > > As I have learned, the two most important issues to me are the two major
> > > priorities of the next release: rendering performance and depictors.
> > > For those of you who don't know, depictors will be a new mechanism for
> > > describing the display of data (i.e. symbology).  It should allow
> > > complex symbology and theming.
> > >
> > > Other things:
> > >
> > > 1) Spatial Indexing Performance:
> > >
> > > Creation of spatial indexes is still somewhat slow.  Larger datasets
> > > (i.e. > 50MB) can sometimes take many minutes.  I think by profiling we
> > > can optimize this.  uDig and mapserver both have speedy spatial
> > > indexing, perhaps we can learn something by examining how they do it.
> > >
> > > 2) Managed SHP Provider
> > >
> > > This is not a high priority, but it would be nice to be able to switch
> > > to the managed SHP provider and be able to drop the SHPLib dependency.
> > > For this to happen we would need to improve the performance of loading
> > > data.  As I documented in a previous email, there is a substantial drop
> > > as compared to SHPLib.
> > >
> > > 3) new Data Provider: GIS Web Services?
> > >
> > > I don't know a lot about this technology or the standards, but if there
> > > exists a way to access GIS data from web services, that would be nice to
> > > have.
> > >
> > >
> > > -------------------------------------------------------------------------
> > > Using Tomcat but need to do more? Need to support web services, security?
> > > Get stuff done quickly with pre-integrated technology to make your job easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > _______________________________________________
> > > Mgis-develop mailing list
> > > Mgi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mgis-develop
> > >
>
>

Re: [Mgis-develop] monoGIS 0.8 Wishlist

[Scott E. <sco...@gm...>]

Hey,

Yeah I mentioned that to Michael.  He went ahead and based the monoGIS
provider off the one that comes in NetTopologySuite.  At least part of
the problem is the spatial indexing speed issue I mentioned, but I am
convinced we can load the data from the file faster than we are.

I can't comment if the SharpMap implementation is faster, it is tough
getting it building on Mono/Linux.

thanks,
Scott

On Mon, 2006-08-21 at 15:46 -0400, Abe Gillespie wrote:
> Hey Scott,
> 
> Concerning bullet 2 - I've been using SharpMap lately.  There is a
> completely managed ShapeFile reader in the project.  Check out the
> source for /Data/Providers/ShapeFile.cs.
> 
> Hope that helps.
> -Abe
> 
> On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> > Hi,
> >
> > The purpose of this email is to document the improvements that I would
> > like to see in the next version of monoGIS.
> >
> > As I have learned, the two most important issues to me are the two major
> > priorities of the next release: rendering performance and depictors.
> > For those of you who don't know, depictors will be a new mechanism for
> > describing the display of data (i.e. symbology).  It should allow
> > complex symbology and theming.
> >
> > Other things:
> >
> > 1) Spatial Indexing Performance:
> >
> > Creation of spatial indexes is still somewhat slow.  Larger datasets
> > (i.e. > 50MB) can sometimes take many minutes.  I think by profiling we
> > can optimize this.  uDig and mapserver both have speedy spatial
> > indexing, perhaps we can learn something by examining how they do it.
> >
> > 2) Managed SHP Provider
> >
> > This is not a high priority, but it would be nice to be able to switch
> > to the managed SHP provider and be able to drop the SHPLib dependency.
> > For this to happen we would need to improve the performance of loading
> > data.  As I documented in a previous email, there is a substantial drop
> > as compared to SHPLib.
> >
> > 3) new Data Provider: GIS Web Services?
> >
> > I don't know a lot about this technology or the standards, but if there
> > exists a way to access GIS data from web services, that would be nice to
> > have.
> >
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Mgis-develop mailing list
> > Mgi...@li...
> > https://lists.sourceforge.net/lists/listinfo/mgis-develop
> >

Re: [Mgis-develop] monoGIS 0.8 Wishlist

[Abe G. <abe...@gm...>]

Hey Scott,

Concerning bullet 2 - I've been using SharpMap lately.  There is a
completely managed ShapeFile reader in the project.  Check out the
source for /Data/Providers/ShapeFile.cs.

Hope that helps.
-Abe

On 8/21/06, Scott Ellington <sco...@gm...> wrote:
> Hi,
>
> The purpose of this email is to document the improvements that I would
> like to see in the next version of monoGIS.
>
> As I have learned, the two most important issues to me are the two major
> priorities of the next release: rendering performance and depictors.
> For those of you who don't know, depictors will be a new mechanism for
> describing the display of data (i.e. symbology).  It should allow
> complex symbology and theming.
>
> Other things:
>
> 1) Spatial Indexing Performance:
>
> Creation of spatial indexes is still somewhat slow.  Larger datasets
> (i.e. > 50MB) can sometimes take many minutes.  I think by profiling we
> can optimize this.  uDig and mapserver both have speedy spatial
> indexing, perhaps we can learn something by examining how they do it.
>
> 2) Managed SHP Provider
>
> This is not a high priority, but it would be nice to be able to switch
> to the managed SHP provider and be able to drop the SHPLib dependency.
> For this to happen we would need to improve the performance of loading
> data.  As I documented in a previous email, there is a substantial drop
> as compared to SHPLib.
>
> 3) new Data Provider: GIS Web Services?
>
> I don't know a lot about this technology or the standards, but if there
> exists a way to access GIS data from web services, that would be nice to
> have.
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Mgis-develop mailing list
> Mgi...@li...
> https://lists.sourceforge.net/lists/listinfo/mgis-develop
>

[Mgis-develop] monoGIS 0.8 Wishlist

[Scott E. <sco...@gm...>]

Hi,

The purpose of this email is to document the improvements that I would
like to see in the next version of monoGIS.

As I have learned, the two most important issues to me are the two major
priorities of the next release: rendering performance and depictors.
For those of you who don't know, depictors will be a new mechanism for
describing the display of data (i.e. symbology).  It should allow
complex symbology and theming.

Other things:

1) Spatial Indexing Performance: 

Creation of spatial indexes is still somewhat slow.  Larger datasets
(i.e. > 50MB) can sometimes take many minutes.  I think by profiling we
can optimize this.  uDig and mapserver both have speedy spatial
indexing, perhaps we can learn something by examining how they do it.

2) Managed SHP Provider

This is not a high priority, but it would be nice to be able to switch
to the managed SHP provider and be able to drop the SHPLib dependency.
For this to happen we would need to improve the performance of loading
data.  As I documented in a previous email, there is a substantial drop
as compared to SHPLib.

3) new Data Provider: GIS Web Services?

I don't know a lot about this technology or the standards, but if there
exists a way to access GIS data from web services, that would be nice to
have.

[Mgis-develop] Appomattox 0.1 Released

[Scott E. <sco...@gm...>]

Hello,

After almost a year, Appomattox 0.1 has been released. For more
information and links to download (it works on both Windows and Linux),
please read the release notes:

http://www.appomattox-project.org/Release_Notes_-_0.1

Appomattox relies on the monoGIS libraries, and I would like to thank
the monoGIS team, especially Michael Paul, for their hard work.

Scott

[Mgis-develop] [PATCH] Memory issues

[Scott E. <sco...@gm...>]

Hi Michael,

In my struggles to improve memory management in Appomattox, I have made
some improvements/fixes to monoGIS.

Attached is a patch which:

1) fully implements IDisposable in MonoGIS.SHPLib.ShapeFile.  It also
implements a finalizer so that the unmanaged resources will always get
freed.

2) disposes of the cached data in a IndexedDataTable on a Dispose.  This
frees the memory immediately.  Check out the following tests:

Test 1: Dispose() of the cache

15:40:37 shapefile is disposed

15:40:26 | Resize | Grew heap from 66.2M to 74.2M
         |        | 61.2M in live objects
         |        | Heap went from 92.3% to 82.4% capacity
         |        |
15:40:38 | GC 27  | Collected 1725025 of 1805613 objects (95.5%)
         |        | Collected 58.7M of 62.4M (94.0%)
         |        | Heap went from 84.1% to 5.1% capacity
         |        |

-------------------------------------------------------------

Test 2: do not dispose() the cache

16:17:08 shapefile is disposed

16:16:58 | Resize | Grew heap from 66.2M to 74.2M
         |        | 61.2M in live objects
         |        | Heap went from 92.3% to 82.4% capacity
         |        |
16:17:10 | GC 27  | Collected 523347 of 1805592 objects (29.0%)
         |        | Collected 14.1M of 62.4M (22.5%)
         |        | Heap went from 84.1% to 65.1% capacity
         |        |

Notice that the GC collects 94% of the heap in test 1 as supposed to
22.5% in test 2.

Scott

Re: [Mgis-develop] SHPLib Provider on Windows?

[Scott E. <sco...@gm...>]

ok, I grabbed the shapelib.dll that came with monoGIS 0.6 and it worked.

thanks,
Scott

On Thu, 2006-07-20 at 11:08 +0200, Paul, Michael wrote:
> Hi Scott,
> 
> I have also confirmed that the official 1.2.9 binary does not expose this
> method. Examining the shapelib.dll that we  usually distribute with monoGIS
> the entry point is defined as well as a lot of other entry points which the
> official binary is missing. I remember that all we did was to compile
> Shapelib from source, just as it is done on Unix. As the Unix does not show
> the same error, I assume that the official binary is somewhat reduced
> version of shapelib. However, I will check this with Sergio, who compiled
> the one and only DLL we are using for 2 years. If he is not indicating
> anything other, what we have to do is to document how to compile shapelib
> from sources and publish our own precompiled binary. 
> 
> Another intersting fact is that the official precompiled binary of gdal
> (gdal_fw.dll) includes the entry point in question. We won't change our
> dependency because of this, but in the future we may opt for 'one serves
> all' solution making dependent the GDAL, OGR and SHPLib provider from the
> same Windows DLL. Also, the Shapelib version included within GDAL/OGR is
> newer and includes some bugfixes which does not seem to published within the
> latest Shapelib release (2001).
> 
> Michael.
> 
> 
> -----Mensaje original-----
> De: Scott Ellington [mailto:sco...@gm...] 
> Enviado el: miércoles, 19 de julio de 2006 18:23
> Para: Paul, Michael
> CC: MGIS-DEVELOP
> Asunto: SHPLib Provider on Windows?
> 
> As I was getting Appomattox working on Windows, I bumped into an issue
> loading shapefiles (via the SHPLib provider).  I went online and download
> the dlls from here:
> 
> http://dl.maptools.org/dl/shapelib/
> 
> I tried both the 1.2.8 and 1.2.9 windows binaries, and for both I get the
> following exception:
> 
> Unhandled Exception: System.EntryPointNotFoundException:
> DBFIsAttributeNULL
> in (wrapper managed-to-native)
> MonoGIS.Data.SHPLib.ShapeLibMgr:DBFIsAttributeNULL (intptr,int,int) in
> <0x0004a> MonoGIS.Data.SHPLib.ShapeFile:ReadAlpha (Int32 pos) in <0x0004f>
> MonoGIS.Data.SHPLib.ShapeFile:ReadNext () in <0x0004b>
> MonoGIS.Data.SHPLib.ShapeDataTable:get_Item (Int32 index) in <0x002b8>
> MonoGIS.Data.Memory.IndexedDataTable:get_Features () in <0x00066>
> MonoGIS.Data.Memory.IndexedDataTable:Fill
> (MonoGIS.Model.FeatureTable dt, System.String[] columnNames) in <0x0027b>
> Test:Main (System.String[] argv)
> 
> Am I missing something here?
> 
> thanks,
> Scott

Re: [Mgis-develop] SHPLib Provider on Windows?

[Paul, M. <mic...@ta...>]

Hi Scott,

I have also confirmed that the official 1.2.9 binary does not expose =
this
method. Examining the shapelib.dll that we  usually distribute with =
monoGIS
the entry point is defined as well as a lot of other entry points which =
the
official binary is missing. I remember that all we did was to compile
Shapelib from source, just as it is done on Unix. As the Unix does not =
show
the same error, I assume that the official binary is somewhat reduced
version of shapelib. However, I will check this with Sergio, who =
compiled
the one and only DLL we are using for 2 years. If he is not indicating
anything other, what we have to do is to document how to compile =
shapelib
from sources and publish our own precompiled binary.=20

Another intersting fact is that the official precompiled binary of gdal
(gdal_fw.dll) includes the entry point in question. We won't change our
dependency because of this, but in the future we may opt for 'one =
serves
all' solution making dependent the GDAL, OGR and SHPLib provider from =
the
same Windows DLL. Also, the Shapelib version included within GDAL/OGR =
is
newer and includes some bugfixes which does not seem to published =
within the
latest Shapelib release (2001).

Michael.


-----Mensaje original-----
De: Scott Ellington [mailto:sco...@gm...]=20
Enviado el: mi=E9rcoles, 19 de julio de 2006 18:23
Para: Paul, Michael
CC: MGIS-DEVELOP
Asunto: SHPLib Provider on Windows?

As I was getting Appomattox working on Windows, I bumped into an issue
loading shapefiles (via the SHPLib provider).  I went online and =
download
the dlls from here:

http://dl.maptools.org/dl/shapelib/

I tried both the 1.2.8 and 1.2.9 windows binaries, and for both I get =
the
following exception:

Unhandled Exception: System.EntryPointNotFoundException:
DBFIsAttributeNULL
in (wrapper managed-to-native)
MonoGIS.Data.SHPLib.ShapeLibMgr:DBFIsAttributeNULL (intptr,int,int) in
<0x0004a> MonoGIS.Data.SHPLib.ShapeFile:ReadAlpha (Int32 pos) in =
<0x0004f>
MonoGIS.Data.SHPLib.ShapeFile:ReadNext () in <0x0004b>
MonoGIS.Data.SHPLib.ShapeDataTable:get_Item (Int32 index) in <0x002b8>
MonoGIS.Data.Memory.IndexedDataTable:get_Features () in <0x00066>
MonoGIS.Data.Memory.IndexedDataTable:Fill
(MonoGIS.Model.FeatureTable dt, System.String[] columnNames) in =
<0x0027b>
Test:Main (System.String[] argv)

Am I missing something here?

thanks,
Scott