How to build?

Topics: SharpMap v2.0
Jan 7, 2008 at 9:40 AM
Hi

I'm trying to build the latest revision of version 2.0 (279). I retrieved the trunk from code.google.com and I also retrieved the trunk for GeoAPI.net from codeplex. Are they supposed to work together, or should I get another version of GeoAPI?

SharpMap won't compile because of mismatches with the GeoAPI namespaces, like GeoAPI.Coordinates and GeoAPI.Indexing.

I'm using VS 2005.

Thanks
Pierre-Andre
Jan 7, 2008 at 11:22 PM
Hi,
I had the same problem sometime back. Believe me, it can be very frustrating, especially if no-one else is complaining and you are alone (I asked myself, am I that dumb?). But I managed to get mine working. I still don't know how I did it but I am willing to share my buildable files with you if you don't mind. if so, your email..
Jan 8, 2008 at 6:37 AM
Hi
Thanks for the response. I eventually got the revision tagged as Beta1Updates got that to build. That should do for now. I will take you up on your offer if I run into further problems, thanks.

I think the problem is that I don't fully understand the dependencies that SharpMap has on GeoAPI and other external references. There is a directory with external references in source control, but the GeoAPI assembly thats in there is definitely not up to date as its missing a number of namespaces and classes.

If I may make a suggestion: How about a howto-build text file included in the project. It can contain a few pointers such as GeoAPI revision and proj.net revision etc that are needed to build.


Jan 13, 2008 at 11:37 PM
I also can't compile it, would be nice to have all required dependencies in SharpMap 2.0 trunk, at least as binaries.

Currently it requires (references as ../GeoAPI, ../NTS) to download GeoAPI (which version?) and NTS (again, which version?).

I tried to compile v2 with last NTS and GeoAPI but it looks like they are incompattible with trunk of SharpMap v2:

Sources:
======

SharpMap trunk, rev.280
GeoAPI-14982
NetTopologySuite-1.7.1-RC1

Errors:
=====

SharpMap.MapPresenter2D expects GeoAPI.Coordinates but in the above GeoAPI it is already called GeoAPI.Geometries

When I try to reference last version there are another errors, e.g.:
ICoordinate.IsEmpty is not available anymore.

Another error is due to the interface which does not exist at all: IExtents.

It looks like not all sources are checked in.


Suggestions:
=========

1. Put GeoAPI sources into SharpMap Google SVN - will be easier to develop/refactor SharpMap and GeoAPI simultaneously. Or at least include correct binaries in Externals.
2. Provide at least smallest HOWTO / README in trunk/ explaining how to build it, which version of external libraries are required and where they can be found.
3. Only chek-in sources if they can be compiled (!).
Coordinator
Jan 14, 2008 at 11:25 AM
Hi there everyone,
AFAIK SharpMap, GeoApi, Proj.net, NTS, NPack are all being refactored side by side prior to the beta2 release of Sharpmap. While many of the project owners are active here it should be recognised that all of the projects were originally independent of each other, grew organically and may have other os projects (mssqlspatial springs to mind) which depend on them. GeoApi which i think is the newest of the projects is being retrofitted into all the other projects as an interface library.. Refactoring them all may take some time...

While this is the case the only buildable version of Sharpmap is beta1 and beta1 updates. You may be able to get the latest svn code to build by modifying the src but you are probably regressing the code back to beta1. Either way chances are all your effort will have been wasted when the real beta2 version is released and the namespaces revert to the ones you hacked.. I have been down this route before..

On a side note can any of the SharpMap coordinators comment on timescales for beta 2 or an intermediate buildable release? cheers jd



gvd wrote:
I also can't compile it, would be nice to have all required dependencies in SharpMap 2.0 trunk, at least as binaries.

Currently it requires (references as ../GeoAPI, ../NTS) to download GeoAPI (which version?) and NTS (again, which version?).

I tried to compile v2 with last NTS and GeoAPI but it looks like they are incompattible with trunk of SharpMap v2:

Sources:
======

SharpMap trunk, rev.280
GeoAPI-14982
NetTopologySuite-1.7.1-RC1

Errors:
=====

SharpMap.MapPresenter2D expects GeoAPI.Coordinates but in the above GeoAPI it is already called GeoAPI.Geometries

When I try to reference last version there are another errors, e.g.:
ICoordinate.IsEmpty is not available anymore.

Another error is due to the interface which does not exist at all: IExtents.

It looks like not all sources are checked in.


Suggestions:
=========

1. Put GeoAPI sources into SharpMap Google SVN - will be easier to develop/refactor SharpMap and GeoAPI simultaneously. Or at least include correct binaries in Externals.
2. Provide at least smallest HOWTO / README in trunk/ explaining how to build it, which version of external libraries are required and where they can be found.
3. Only chek-in sources if they can be compiled (!).


Coordinator
Jan 16, 2008 at 9:07 AM
Hi all -

Thanks for the interest... I'm glad to see there was experimentation even when the code was in such an awful, unstable state.

Fortunately, things are emerging from the long, dark tea-time of the GeoAPI/NTS/Beta 2 refactor. There will be an announcement today or tomorrow about the state of things... watch for it!

I like the suggestion of a HOWTO for a v2.0 check-out / build. I'm finishing a rather large merge of a number of parallel streams of development, and when this is complete and I have a solid, reproducible build, I will make such a page.

@gvd: I appreciate the good suggestions. I had plans to put a built GeoAPI in the ExternalReferences, but have been lacking time. The HOWTO/README is underway, but I didn't think of putting it in source control until now (thanks for the tip). The messiness of the source tree was mostly laziness / rushing. Sorry about that. I tried to mitigate it by having stable Beta 1 tags, but I was aware that I committed quite the transgression by breaking the trunk like I did. I'll behave more cooperatively in the future. No, really. ;)
Jan 16, 2008 at 8:20 PM
Hi codekaizen, thanks for HOWTO, will try to build everything soon. I hope it will come to some workable solution so that it can be production-ready. Community is here to contribute as well :).
Coordinator
Jan 17, 2008 at 9:56 AM
Hi everyone, Thanks codekaizen et al.. I have successfully managed to build the latest sources(NPack, SharpMap, NTS, Proj.Net, GeoAPI) but needed a couple of tweaks.
1) none of the test projects compile so unload them
2) as Magnum said in another thread some of the file names are mangled by source control (I cant remember which) if you see missing files in the project(yellow alert symbol) browse to the project location - the "`" has been replaced by "%60" in the file name - correct it and your good to go.

At the moment I'm having a stab at building mssqlspatial against geoapi and NTS.. Its been a long night.. (only 14 Errors to go...) I will resubmit when It works..

Perhaps someone can clarify in NTS 1.7.x there was a property geom.EnvelopeInternal - Is this a direct eqivalent to geom.Extents in GeoAPI?

Anyway thanks again everyone..
Coordinator
Jan 17, 2008 at 3:43 PM
@JohnDiss -

I'm working on getting the tests to compile and run now, and will notify when this is done.

Recent checkins to the SvnBridge fix the character mangling issue. You get to build it yourself, however, since there is no release as of this posting.

You're analysis is correct: the NTS Geometry.EnvelopeInternal property was removed and is now accessed via IGeometry.Extents. This was changed to make the concept of an extents stand out clearly, as separate from geometry, so the word "envelope" was changed to "extents" to reinforce this separation.

Let me know how the MsSqlSpatial work goes... I'm glad someone is looking at this!
Jan 18, 2008 at 12:40 AM
Edited Jan 18, 2008 at 12:42 AM
We've been grabbing all your stuff. We've kept poking away on the test stuff, etc. But I might be missing something. Doesn't NTS need a Coordinate class of some type? I created a Coordinate2D class, implementing all of the required interfaces for it to be a TCoordinate, and that got us going. But what should I have been doing?
Coordinator
Jan 18, 2008 at 2:58 AM
You're right - it does need a coordinate class. That will come from SharpMap (I'm working on it right now, actually), and get injected when SharpMap supplies the coordinate factory to NTS.
Jan 18, 2008 at 9:12 AM

We use GeoAPI, NTS, and ProjNet independent of SharpMap. If there is no placeholder Coordinate class in NTS, I'll just need to copy that class into one of my own NameSpaces then? Well, looks like I'll need a coordinate sequence factory and coordinate factory too, right? Not sure I wouldn't use the ones in SharpMap... just seems like a strange dependency to introduce into the non-graphical parts of this total system.
Coordinator
Jan 18, 2008 at 9:43 AM
@Magnum4610, I'm in a similar position, I have created a stub ICoordinate implementation in MsSqlSpatial which i will replace later but, I'm wondering if it would be helpful to have a concrete implementation of ICoordinate and associated factories in GeoAPI.

Anyway MsSqlSpatial now builds with the updated libs.. ILMerge on the other hand has thrown a wobbly so I have disabled that part of the build..

I have temporarily moved some of the old NTS functionality out to extension methods e.g IGeometry.Length(), IGeometry.Area() etc as these are not defined in the GeoAPI interfaces... (could somebody comment on whether they are likely to reappear?).

I have added a dependency on SharpMap to access the ShapefileProvider and allow import and export of shapefile data. This makes me wonder if the SharpMap.Data / SharpMap.Data.Providers interfaces and implementations could be moved into seperate libraries? This would allow the IO functionality to be used more easily accross projects that do not have any need for rendering..

Jan 18, 2008 at 11:54 AM
Edited Jan 18, 2008 at 11:58 AM
Personally, I would rather have the coordinate implementation in NTS... the implementation assembly, than in the GeoAPI Interfaces assembly. There must be a good reason that codekaizen wants them in SharpMap. I'm sure he'll let us know later today.

I strongly support moving all of the Shapefile stuff out into a separate assembly. For our own purposes, we have already done that with the NTS shapefile stuff. Moved it over into a separate namespace/assembly so that we could use it in non-graphical applications while SharpMap and NTS migration was afoot.

I had not noticed that we lost length and area on IGeometry. Looking at the interfaces, ILineString inherits from ICurve, and ICurve has a Length property. And IMultiLineString has an explicit length property. ISurface has an area, and IPolygon inherits from that, so that should be covered. However, I don't see a way to get the area of a MultiPolygon or MultiSurface. Maybe we can get Area added to those interfaces.

I was never really comfortable with Length and Area being properties of IGeometry. They were not in the OpenGIS spec.

I'm not familiar with the syntax of the IMultiPolygon interface, but there is a lot I'm not familiar with yet in .Net :(
Coordinator
Jan 18, 2008 at 12:45 PM
Having the coordinate implementation in NTS would be Ok for me but it would kind of enforce the dependency on NTS (i think the SharpMap devs are trying to remove this existing dependency) whereas there is always a dependency on GeoAPI. Maybe what we are getting at is a completely seperate assembly neither NTS, SharpMap or GeoAPI?

I see what you mean about the Length/Area stuff but I need to implement it on IGeometry just to prevent breaking changes to MsSqlSpatial - I guess I'll just return 0 if it is not appropriate on a given geometry...

BTW do you have a working set of concrete implementations of the factories / ICoordinate that I can use for testing?

I'm fairly new to GIS so correct me if I'm wrong but isn't the area of a multipolygon just the sum of the areas of each polygon? If so then it can be calculated by iterating through each IPolygon in IEnumerable<IPolygon> an interface which IMultiPolygon implements


Magnum4610 wrote:
Personally, I would rather have the coordinate implementation in NTS... the implementation assembly, than in the GeoAPI Interfaces assembly. There must be a good reason that codekaizen wants them in SharpMap. I'm sure he'll let us know later today.

I strongly support moving all of the Shapefile stuff out into a separate assembly. For our own purposes, we have already done that with the NTS shapefile stuff. Moved it over into a separate namespace/assembly so that we could use it in non-graphical applications while SharpMap and NTS migration was afoot.

I had not noticed that we lost length and area on IGeometry. Looking at the interfaces, ILineString inherits from ICurve, and ICurve has a Length property. And IMultiLineString has an explicit length property. ISurface has an area, and IPolygon inherits from that, so that should be covered. However, I don't see a way to get the area of a MultiPolygon or MultiSurface. Maybe we can get Area added to those interfaces.

I was never really comfortable with Length and Area being properties of IGeometry. They were not in the OpenGIS spec.

I'm not familiar with the syntax of the IMultiPolygon interface, but there is a lot I'm not familiar with yet in .Net :(

Jan 18, 2008 at 1:38 PM
Edited Jan 18, 2008 at 1:39 PM


I see what you mean about the Length/Area stuff but I need to implement it on IGeometry just to prevent breaking changes to MsSqlSpatial - I guess I'll just return 0 if it is not appropriate on a given geometry...


I think you are going to see a lot of other breaking changes, anyway. So I'm not sure how big a deal it would be.


BTW do you have a working set of concrete implementations of the factories / ICoordinate that I can use for testing?


No, not really. I've just let VS do default implementations as place holders, and then poked in a little stuff in order to get a full compile and the ability to generate a geometry factory, etc.


I'm fairly new to GIS so correct me if I'm wrong but isn't the area of a multipolygon just the sum of the areas of each polygon? If so then it can be calculated by iterating through each IPolygon in IEnumerable<IPolygon> an interface which IMultiPolygon implements


Yes, you can iterate the members, but if a MultiPolygon has an Area, then you should be able to get it directly (internally, it would iterate the members). The IMultiLineString has Length, and it could have been derived by iterating the member LineStrings, too. OpenGIS Spec says MultiPolygon should have an Area property. I'm sure it's just a temporary oversight. What I don't know is if we are supposed to just jump in an fix something like that when we find it.

Coordinator
Jan 18, 2008 at 10:36 PM
Actually, I'm up in the air about where to put the concrete implementation of ICoordinate. I have tried putting them in GeoAPI, NTS and SharpMap at this point, and I guess I just don't have enough perspective on the usage to understand how people will use GeoAPI w/o NTS or NTS without SharpMap to make it clear. One reason I'm unclear is that the Coordinates implementation could be completely independent of any of these projects. For example, one story I'd like to see support for is using SharpMap with a DirectX renderer. If I am going to use the DirectX renderer, I'll probably want to implement ICoordinate on top of a CustomVertex type, so all point data can just live in a IDX9VertexBuffer.

So, long answer short - I need to hear more about this, and your comments are all quite valuable. I'll re-read and consider them tonight.
Coordinator
Jan 18, 2008 at 10:48 PM
@Magnum4610 -

Good call about IMultiPolygon/IMultiSurface getting area - I just missed it, and will add it.

I never liked the Length/Area properties on Geometry, either, but I can see why they were there - they unified and simplified a number of operations when reasoning about the geometry instances. However, I prefer to use type conditionals when doing this. It makes the code a bit longer, but you don't have to assert defitinitions (like Points and Lines have an area, but it is 0) which then have to be remembered by the end-developers. I think it is easier and more natural (coming from a .Net perspective) to remember that only areal types have area. This somewhat breaks down with dynamically typed languages, though...

Coordinator
Jan 18, 2008 at 10:50 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Jan 18, 2008 at 11:46 PM
Edited Jan 18, 2008 at 11:55 PM
@Codekaizen - I think my preference is to have the concrete ICoordinate in a seperate assembly. That way it can be replaced by a different implementation in any project but the "quick and easy"dev route doesn't introduce any uneccesary dependencies - In my case I would like to avoid putting SharpMap into the MsSqlSpatial library project. (I dont mind it going into the console as I'm using the shapefile provider there)

BTW my work with MsSqlSpatial has got to a point where it all compiles and should do everything it used to but with a couple of tweaks (for instance installing the assembly from byte[] instead of filepath - allowing you to install over the network). Still having trouble with ILmerge though..
I have also brought the Postgres provider to up to speed - is there any where I can feed these back?

cheers jd


codekaizen wrote:
Actually, I'm up in the air about where to put the concrete implementation of ICoordinate....
So, long answer short - I need to hear more about this, and your comments are all quite valuable. I'll re-read and consider them tonight.

Jan 19, 2008 at 12:55 AM
I vote for a separate assembly, too.
Developer
Jan 19, 2008 at 12:27 PM
If any of you have downloaded the latest from SVN (Build 289) something appears to have got into the project files. On Wednesday CodeKaizen said he was going to produce notes on building beta 2.

"Fortunately, things are emerging from the long, dark tea-time of the GeoAPI/NTS/Beta 2 refactor. There will be an announcement today or tomorrow about the state of things... watch for it!"

Do you know when we are going to get this.
We all appreciate the work you are doing, but it can be quite frustrating attempting to keep up with the changes and the contents of the SVN not always compling.



Coordinator
Jan 19, 2008 at 12:34 PM
Er, sorry... it's here: Building SharpMap v2.0.

I forgot to put the announcement on this thread.