I need to export to shape files. How do I cause Manifold to create the projection file? When I do the export, there is no PRJ file (projection file).

The only way I know of (other than scripting for exporting large numbers of shapefiles) is to right click on the drawing to be exported, click on 'Assign projection' and then to click the disk icon. Finally select prj from the 'Save as type' drop down.

That looks like it worked. The contents look like a normal PRJ file.

I had to make some changes to exactly match the file name body, and had to add PRJ as the file extension.

My user will let me know tomorrow if it works for his needs.

Thanks.

That sounds about right, same steps I do. Not sure why export shp would not do prj too...

Yes, it would be a nice default behavior. And the matching of export file name body, and append the PRJ extension.

Sounds like a suggestion to sales.

Yes, it's a big pain in the bum. I've been meaning to get around to suggesting the same thing.

Preferably, Manifold should always save a .prj on shapefile export, as well as an .xml. (Any software that can interpret the xml should just ignore the .prj, which doesn't contain full information for some projections.)

If it doesn't do that, then as Tom Sullivan suggests, it could at least:

(1) Suggest the active component name in the Save As box (not Projection.xml)

(2) Automatically change the suffix (e.g. from .xml to .prj) if the file type is changed.

I've also been meaning to do this :) I just sent this one:

I'd like to request some modifications to the shapefile/PRJ file export. It would be very nice if PRJ were created automatically for every manual or scripted export of shapefiles. My requests follow, 1-3 from most important to least.

1. Please modify the behaviour of shapefile export to always generate an auxiliary .PRJ file, as per the manual save from the projection dialog/s.

2. Set up the auto-create-PRJ-on-export as a user-defined option in /Tools/Option and in the object model - so that auto-creation of PRJ could be disabled.

3. Modify the manual save for PRJ files to automatically update the file extension from .xml to .prj

Be sure to add your own vote, in your own voice, following these suggestions: http://www.manifold.net/info/suggestions.shtml

BTW, it would be easy enough to script this into a custom-toolbar button that exported the currently open drawing and auto-created the PRJ. As I write this I realize it would solve some issues I've had with surface export too, so I may follow this up.

cuda shuda wuda

PRJ is a hack that has not been formally documented, so there is really no "standard" for .prj to which Manifold can legitimately write as a default. There is enough "tower of babel" stuff going on in GIS without Manifold adding to it by creating what would, in effect, be some Manifold-defined .prj quasi-standard.

The only consistent way to use shapefiles is to save unprojected data as the format was originally designed to do.

I realize that a lot of folks just want to store projected data in shapefiles all the same, and that there is considerable informal usage of .prj ("informal" in the sense that people are winging it given the lack of a hermetic standard) - but that also causes a lot of hassles for users exactly because of the inexact nature of prj. You may be willing to take on those occassional hassles or may not even see any hassles because your own usage is always internally consistent. But when Manifold starts writing something as a default the company ends up seeing every last psychotic variation that can possibly be encountered as a result of no real standard existing for .prj.

No doubt if a real standard ever emerged for .prj the company would be happy to support it.

I can see this as justification of not automatically including prj in shp export (as an extra reminder to folks: "is this really what you want?". But a saving dialouge that does not automatically include the correct file name extension seems like nothing more than an oversight.

Darn Manifold and their principles. I'll put together that custom-script button.

BTW, there's no guarantee that enough votes couldn't get us what we want - don't necessarily let Dimitri put you off asking. I'd go for the angle of it not being default, but that you could provide auto-PRJ-creation by setting an option.

cuda shuda wuda

Just cast my vote for automatic PRJ creation

A script would be awesome. I've already submitted a suggestion a few months ago when I had to get a Client's ArcPad device working. Now there's a pain the #$%^&.

Dimitri, you are entitled to your opinion. Quite frankly, it's complete bullshit. Customers want what they want, regardless of whether you think it's right or not.

Those of use who use Manifold often have to interact with the the great unwashed in the rest of the world. That means we have to share projected shapefile data, whether you think it's a good idea or not..

If you want us to use Manifold, you have to make it easy for us.

You're entitled to your opinions about what's "right." However, most of the rest of us have to deal with what is.

"What is" is that the way manifold requires us to go through various menus to get to a PRJ file is a pain in the ass. You want us to buy your product? Make it easy for us to use it in the Real World. It doesn't matter what you think is "right," it only matters whether we can use your software and still interact with our customers. We Manifold users don't get to dictate user expectations. We only get to interact with our users. If we can't exchange files with our users, then many of us can't use Manifold, no matter how much we like it for other purposes.

The way you generate PRJ files in Manifold is a kludge, plain and simple. It could be made much easier by simply putting a checkbox on the "export" dialog to "export a PRJ file." It doesn't seem to be a whole lot of code. But the way it works right now is serious penance if one chooses to interact with other people who haven't themselves drunk the Manifold Kool Aid.

Ralphie,

Remember, the Projection object has a ToTextPrj method. That means you can write a script to do it automatically. I just wrote a VBScript that will export a shapefile, and export an associated PRJ. The script is 11 lines long.

So, while I like your suggestion about a checkbox, I have to say that it is enormously easy to write out shapefiles and projections for multiple drawings. That is why I always keep forcing my students to script in Manifold. If faced with a problem, always think about if there is a quick solution to code it in. There are two benefits:

1. you will have the answer you need

2. the other guy won't have the answer, and can now pay you to implement it for him :-)

In fact, by not having that little button in there, you might look at it as having Manifold set you up for a little cottage industry to export shapefiles with associated PRJ files. So, a certain percentage of people who own Manifold won't be able to do that. But, with a 11 line VBScript, you are away laughing. So, in some ways, that insulates you even further from the "unwashed", because they are all looking for a button to do things, and you could have a 11 line script to do it.

I always liken this stuff to "Forrest Gump", when his Shrimp Boat was the only one that didn't get destroyed in the storm. If you are the only one who's taken the time to write a PRJ file automatically after an export, then you are in far better shape than someone who is waiting on Manifold to do it, before they attempt to take on that kind of work from their clients.

Just my two cents.

Ralphie,

Whether or not there is a standard for PRJ files is not a matter of "opinion," it is a matter of technological reality.

If you disagree with that, it is very easy for you to correct me: If you think there is a standard for PRJ files, please post to this thread a URL which defines that standard.

Regarding looking out for customers: that is exactly what this is all about, and Manifold's determination to look after the best interests of most customers and unwillingness to make life rough for many people in order to provide a fake "solution" to a limited subset of users.

Customers want all sorts of things depending on the customer and, frankly, some of what is routinely asked is driven by highly local situations that are not in the best interest of most. Sometimes that's driven by lack of experience or education, in that people don't understand that the local thing they are asking for is not in most people's interests or they don't understand that what they are asking for is not really a "solution," but sometimes one encounters requests for local changes where the requestor clearly doesn't give a hoot if that change inconveniences everyone else.

A good example of the "lack of education" subtype would be when the state legislature of one of the states voted to make "pi" a round 3.000 to simplify arithmetic. Well intentioned, but not something that should have been done! A GIS example would be when folks ask to be able to cut and paste from multiple UTM zones into a single zone "without distortion" perhaps with Manifold "automatically making changes." People only ask that when they don't really understand what projections are or how they should be used. If Manifold altered the operation of UTM zones to accommodate such requests we'd be ruining the accurate nature of projections.

PRJ files are not usually an accuracy thing (although they can be when different coordinate systems are wrongly assigned similar names by different people), but they are a highly undocumented thing that cause frequent trouble for people who use them for exactly the reason that they are not documented. We don't want to add to that trouble, and we do have a reputation for accuracy, quality and exact reliability in the matter of standards that we would like to maintain.

There is also the not insignificant matter of competition in winning the hearts and minds of millions of people discovering GIS who are coming into this area from Microsoft Office and similar mainstream markets. We don't want to be put into a position of misleading them on the one hand, and on the other hand we also don't want to pass up the competitive advantage of having all those people realize the degree to which ESRI stuff like shapefiles are so obsolete.

I don't feel very strongly about this either way, personally. There is the tactical problem if we jumped into the PRJ kludge as an default option how we would emphasize for all the newbies what an utterly stupid thing it was to use PRJ given the fatal ambiguity of it as a non-standard. What are we supposed to do, pop up a dialog that warns people "caution - what you are asking is a kludge: please try to use shapefiles as they were originally designed" before we allow them to write a PRJ?

To date, the feeling has been that writing PRJ's causes more troubles for a wider range of people than it solves for a smaller range of people. If anything, there is a strong case to be made that the greatest interests of the largest number of people would be best served if Manifold only wrote shapefiles as unprojected data, all the time. That would be consistent with the ideal sought for in some other formats to read virtually everything but to write only to well-defined standards where whatever Manifold writes can at all times be assured to be absolutely accurate and exactly, unambiguously defined. You may not value that unambiguous accuracy but many other folks do.

In fact, as GIS matures it is a clear trend in all communities, perhaps especially in long-term ESRI communities, that users are demanding unambiguous specification of coordinate systems. The demand for that is driving just about everything being done for new generation products not just within GIS vendors like ESRI and Manifold but also other entrants like spatial DBMS players.

That brings up my last but not least point, in that Manifold's mission is to create the very best GIS possible at the lowest possible cost. Our mission is not to clone ArcView or to provide a lower cost replacement for obsolete ESRI software. We're sure happy to facilitate interchange with legacy environments to enable people to utilize data created by dinosaur-ware and to enable transitions in environments where ESRI products continue to be used. But we won't take on the mission of trying to fix all possible mistakes or bad choices arising from living fossil stuff. I don't think that PRJ usage is a life or death living fossil thing, so that's why I personally don't feel very strongly about it either way. But, there is something to be said for saying, look, there is a role for education and solid profesisonal practise here and if anything is a kludge it is using PRJ in the first place. Sooner or later there comes a time to move on from there and just perhaps now is the time to do a good job of reading a huge zoo of PRJ variations but not add to the confusion by writing them.

To continue on the theme of old interchange formats, it seems to me that shapefiles and dxf are the common interchange formats because they were developed by the dominant vendors of the time, ESRI and AutoCAD. Both formats are old and very limited.

At some point in the future wouldn't it make some sense for Manifold to create an interchange format that other GIS/CAD could relatively easily support? Maybe a good time would be after Manifold label capabilities are improved since neither .shp or .dxf seem to handle labels well.

Mike,

I am inclined to agree with you about creating a modern interchange format for drawings, and hell, why not other data types too. But, and it is a very big but, producers of campetitor products will likley not see it as being their interest to adopt new file formats created by the upstart. Unless this occurs, they will not be much use.

Yup, it would probably take several things to happen: 1) a good format that provides great functionality that other vendors could incorporate, 2) provided by a somewhat dominant vendor, and 3) a fair amount of time and a bit of luck. It might be worth Manifold to start thinking about it since they might be someday in a position to pull it off. Let's hope anyway.

I don't believe I suggested giving us an automatic PRJ file as a default option.

Nor do I see my role as one of educating the great unwashed who still expect PRJ files when I send them a shapefile, which is usually what people ask for.

What I DID suggest is to put a checkbox on the SHP export dialog that asks if we want to make a PRJ file while we're at it.

Since this is something that many of us are asked to do fairly often, I simply want a checkbox that allows me to create the PRJ file at the time I export the SHP file, without having to wade through yet another set of dialog boxes (change projection, hit the little disk icon, switch from the default choice of XML, then make sure I name the file the same as the other shape components without making any typos.) I still make the decision myself whether to export projected data. If it's what the people on the other end want, that's what they're going to get. There's nothing hard about what we have to do now, but it's extra steps in the workflow In my opinion, they're unnecessary steps.

I have no great love of projected shapefiles, and personally would rather send people data in WGS84 Lat-Lon rather than UTM NAD whatever. Even if I do that, they're going to ask me what happened to the PRJ file. It's easier just to make one than lecture them. But it would be easier still if it could be done in fewer steps.

It is somewhat assuming away the problem by assuming that providing a checkbox solves the problem of interchange with the great unwashed. Tha's assuming away problems (or, perhaps, just shifting the blame for problems) because since there is no PRJ standard whatever Manifold writes by default as a result of that checkbox will cause trouble in many cases.

If someone doesn't know what they are doing, why would they expect a PRJ when you send them a shapefile? Why not simply send them a shapefile containing unprojected lat-lon WGS84 data? There's no need for education there.

Most people who have heard the term "shapefile" don't know what PRJs are. In fact, most people don't even know that "a" shapefile is normally at least three files - that's why just about everyone who has done data interchange using shapefiles has gone through the experience of having some well-intentioned beginner say "oh, I sent you that shapefile" when what happened was they sent only the .shp file and not the .shx or .dbf files. Likewise most applications that work with shapefiles have no idea what PRJs are either, since most such applications were written by programmers with no GIS experience who designed their code from ESRI's published shapefile standard.

As a practical matter, the only people who really use PRJs are those who are using shapefiles to interchange projected data, typically with obsolete ArcView installations (ESRI in recent years has been promoting "geodatabases" instead of shapefiles). Those fall into two classes, broadly speaking: those who really know what they are doing and those who don't. The latter tend to be the biggest group because those folks who really know what they are doing tend to avoid using shapefiles for projected data exactly as you described being your personal preference. The expert group you're not going to have to explain anything to.

That means your main constituency for PRJ files are folks who are using shapefiles to exchange projected data but who really don't know what they are doing. That's a rough group to interchange with as a practical matter because such folks are forever encountering problems involving projections that they often blame on others. Your best hope to deal with such folks is to give them unprojected data. If they really insist on a PRJ, make one PRJ as a model for lat/long WGS84 data and repeatedly use it in such cases.

One reason Manifold does not provide such a checkbox is that when we force you to create the PRJ you take ownership of your decision to provide a PRJ. If Manifold were to do that automatically, Manifold would end up owning the grief resulting from a lack of a PRJ standard. It's understandable you don't want to have to educate your clients who are asking for PRJs, but likewise you should understand Manifold does not want to get scapegoated or on the hook for education either!

Here's how it goes: you have a client who wants a PRJ, so to shut them up you give them one using a Manifold checkbox. In some percentage of such cases there starts a "pointing fingers" issue because there is no PRJ standard, there is confusion or disagreement regarding what the PRJ should be and the ultimate party that gets scapegoated is Manifold, since their darned checkbox didn't do the trick. No thanks! :-)

This is not speculation on my part since we see it all the time just on intake of PRJs. But that's a much simpler situation to remedy because we have full control over our software. It is a much more difficult situation when creating something that will always work in other people's software, especially when you know by the nature of the task that the intended usage is a) obsolete, and b) not the sort of thing that experienced people tend to do and c) also enjoys the charming randomness of hundreds of packages that "work" with shapefiles but are clueless about PRJs. Not exactly the forward-looking march to a better GIS future we all envisioned back in grade school when we were dreaming about the happy day we would finally get to have GIS careers as adults!

Would it be useful to have some extended PRJ standard that was professionally and competently designed to eliminate the ambiguities of the current situation, to avoid the trouble it causes? Sure! Would it be cool if Manifold provided such a standard? Perhaps. But why should Manifold expend engineering effort to repair an ESRI kludge that has already been abandoned as obsolete by its original inventor? If we are going to invest effort into offering an alternative, why not create an alternative that makes more sense which is not tied to ESRI, or even to us, but instead is a contribution to some politically correct open source thing?

Alternatively, if we are going to be at the same time cynical and competitive there is another strategy for dealing with such difficulties: there is an entire group of problems arising from the survival of stone age technologies, like shapefiles and PRJ, into modern times. This includes things like helping ESRI folks transition all their AML scripts, helping MapInfo folks port their Map Basic stuff and similar. Some cynics would say the most effective way of dealing with that is to ignore it, to not waste one nanosecond on trying to make a silk purse out of a sow's ear, but instead to spend every waking moment on building a better system to eradicate the living fossils. I'm not that hard core but I can see how some people might be.

Last but not least, I'll leave the answer to your question up to you:

Is a checkbox too much to ask?

No, not if you follow the suggestions guidelines and tell Manifold exactly what you want that checkbox to do. No cheating - None of this "three wishes" stuff where your third wish is for an unlimited number of additional wishes. :-) None of this asking for stuff you can't define but then making your wish that Manifold defines your wish for you. If you state exactly what must be done it is very doable. If you want Manifold to engineer a solution to a problem arising from a lack of a standard, sure, we can do that as well, but that is not so simple a thing to ask and, in comparison to what other folks are asking for, might well indeed end up being too much to ask.

As always, keep in mind that other folks have other priorities and that following the advice on the suggestions page is a great way to assure your suggestion achieves the maximum impact you want it to have. If you've already contributed a suggestion stating your views on what a PRJ should be when issued by Manifold, perhaps you could contribute a copy of that email to this thread so that anyone else who wants to work on that can use your model as a starting point.

Dimitri, I think the lack of a standard for PRJ is a separate issue from what an annoyance it is to make one in Manifold.

If I haven't already submitted this (I don't remember) I will submit it though normal channels.

I didn't start the thread, I was just chiming in. Feature ideas are often vetted in this forum before people submit them.

I don't quite follow the point of all this. Manifold currently provides a prj export. All that is being asked is to (1) move its location, and (2) make it automatically put .prj behind the name, and (3) having moved the location make it recognize the name of where it is coming from.

If Manifold is so concerned about prj problems (I do not dispute the problems) why have it at all? Does having it several steps removed really allay the fears/frustration/anxiety/contempt that you express?

My thoughts exactly.

Yes, well put.

Dmitri's recommendation to avoid putting projected data in shapefiles has a lot of merit in theory,* but I doubt the choice he recommends often arises.

If a Manifold user is exporting a shapefile, it's most likely to be because he or she has previously imported a shapefile, supplied by someone else, and is now returning derived or related data to that person. If the data that went in had a .prj, then the expectation will be that a .prj will come out. And the current inconvenience of having to write one manually, or copy and rename an existing shapefile, for each drawing to be exported, is far more important than impurities in the .prj format.

*Though as Dmitri himself stressed not long ago, there's no such thing as pure Latitude / Longitude. For interchange with users whose software can't read a Manifold .xml projection file, a .prj has the merit of identifying the datum and ellipsoid, which can prevent ugly shifts of unprojected data in some cases.

I agree with this, the stupid PRJ thing just helps a *lot*. Even if it's just this:

OGR's PRJ from "+proj=longlat +ellps=WGS84"

GEOGCS["GCS_WGS_1984",DATUM["D_unknown\",SPHEROID["WGS84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]"

Manifold's PRJ from exporting PRJ from an import using the above:

"GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.000000,298.257224]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]"

Either one of those saves pain for longlat at both ends - as Tim says: how does assuming a shapefile is unprojected protect anyone from different datums?

At both ends you still have to verify that the transfer works, I don't care if the great unwashed don't know that, that's what "unwashed" means. It's the same problem for any projection metadata for any format, it could have been assigned incorrectly at either end.

I guess the real practical problem is that for some of Manifold's projections there simply aren't OGC (or whatever that stuff is) parameters for all the options.

cuda shuda wuda

Also, the header files for BIL surface export use the wrong sign for YDIM - so I don't see why this particular issue is one of protecting us from non-standards.

cuda shuda wuda

An observation, since this thread has been awakened- Manifold automatically creates a prj when exporting a surface as ESRI asc/grd.

Ah, that could have been interesting - but the surface PRJs are different:

From the ASC export:

Projection ORTHOGRAPHIC

Spheroid GRS80

Zunits

Units Meter

Xshift 0.0000000000

Yshift 0.0000000000

Parameters

6378137.000000

6356752.314245

00 00 00.0000

00 00 00.0000

0.000000

0.000000

That is another variant on this, with the "world file" geotransform parameters in one file. (It's weird by the way that projection metadata doesn't include these raster position values normally - only Manifold seems to combine the two. But then it's not clear how Manifold would handle the rotation values in that context).

From the projection dialog save option (for the surface):

PROJCS["unnamed",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.000000,298.257224]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Orthographic"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Longitude_Of_Center",0],PARAMETER["Latitude_Of_Center",0],PARAMETER["Scale_Factor",1],UNIT["Meter",1.0]]

cuda shuda wuda

Perhaps checking the box could bring up a dialoug stating we absolve Manifold of all wrongdoing before it does the export?

Yep, that's all I was asking for.

I would like to point out that not having the prj, even when using unprojected WGS84 data, can cause additional work for the receiver of the .shp file set. When the user opens the drawing in ArcGIS, the software says it is an unknown coordinate system and that the data cannot be projected. Now the user has to assign the coordinate system to the drawing before they can use it if they want it projected. I know it is easy to do, but our clients would rather be able to use the data immediately. As has been stated before, this is not a request for a new feature (Manifold can already export a prj), rather it is a request to make it a bit easier for those of us who have to make sure the data we create in Manifold can interchange with other software.

The process of building a spacial reference for all the known projections is already going on in the community and it collects PRJs (see ESRI WKT) and other file/string formats. This process don't needs ESRI or Manifold or another vendor to establish a new standard. It's simplicity, usability and illustration make it a new standard.

Yes, totally agree with you, Ralphie. I am one who usually bites his tongue even when it is the truth when I know the person who hears it can't actually hear the truth, but your opinion is pure rubbish, Dmitri. The tower of Babel, as you should well know, can and has been solved, and solved many times. In this day and age, it is solved, again, as you should well know, programatically using stack or heap call recursion. And you can't expect your clients not to be frustrated and sh*tty when you take money from them for a software product that is, at it's core, tied in its implementation via its interfaces for any given software release!

Anyway, I have a tech problem with interfacing to ArcGIS, which I am not yet going to even waste more of my time trying to ask the Manifold people for help on yet.

As for shapefile projections and tower of babel stuff, bloody well pander to your clients, Dmitri and provide a solution! You can stay stuck in the shifting towers mentality, but in my line of work, every problem I get given I solve! And if I can't solve it within either the systems I have available to me or under any current system known to man, I dig into my intuition and unlimited creative power and I solve it. So, you being the great programmer, as your talk suggests, will know to build sufficient abstraction into any codified implementation of what these good people are asking, with the correct balance of code client-server coupling and cohesion such that when your implementation does break (eg, a "tower" has to be moved outside of the rules, namely, the projection quasi standard or ESRI implementation, or any bloody external implementation, shifts again), it is a client-calling level code change that is relatively simple to modify!

And a word of warning, Dmitri: don't even think of firing up from your woundedness back at me. I know: you use obfuscated language and concepts to create subterfuge, trying to duck and cover from your responsibilities, but people here (and everywhere, for that matter) are not stupid! I suggest you put your distorted ego and sick pride back where it belongs and start listening and working with your paying customers. You've been told, matie! Question is, have you really heard?

Oh goody goody, let the show begin!

Thanks but no thanks justin.

I don't want to see valuable discussion of this feature buried in a flame war.

No, you're right, Ralphie. My apologies to Dmitri and everyone for losing my cool. It was wrong, sorry... I don't want to interfere with the progress you guys are trying to make. My anger and frustration came out of 5 weeks of building a GIS bike network for council here, and it was fine in Manifold, but no matter what I try, I cannot get it to be meaningful for my employers (who use ArcGIS 9.x) - meaning both the extents and the proportions (X/Y balance) is all out of whack.

Sorry.

Justin

Oh! and I thought it was a bad lot of prawns on the weekend barbie

Why don't you start a new thread and have a go at getting the problems sorted. There are a lot of very skilled cross-platform people here.

Justin,

Why can you not export your bike network data as a set of shape files wherein positional information is given by latitude and longitude pairs (as recommended in Manifold - Help). Then import it into ArcCrap and reproject to your required projection. I presume ArcCrap can perform reprojection. If necessary before importing into ArcCrap delete any files created by Manifold decribing the projection (or more correctly, the lack of it, used) so that ArcCrap is not confused and so forcing its user to specify these after import.

We can appreciate your frustrations, but these should be directed to ESRI, not Manifold. Back in the dark ages when ESRI was the only game in town, ESRI created the .prj file format for use with its also-obsolete shape file format and has never formally documented either of them. I presume .prj files produced by ESRI products can be read by other ESRI products and those of its partners without any issue (Is this true?). If so this is ESRI abusing its dominant position in the GI software market as a way of making you to use ESRI products rather than others.

Ok, thanks Nick. I will try that and see if it works.

Thanks for the suggestion Nick. I assumed (correctly?) that to "export your bike network data as a set of shape files wherein positional information is given by latitude and longitude pairs (as recommended in Manifold - Help)" meant to reproject the bike network data using Latitude and Longitude pairs, ie "Standard Projection >> Satellite View >> Latitude / Longitude", correct? If so, whenever I do that, my component, in this case, the cycleway network drawing, goes bananas within Manifold, or more accurately, the last time I tried, it turned into a bizzare straight line.

Anyway, and this is also for danb's benefit (thanks mate), I ended up solving the problem by not accepting the Manifold defaults for MGA94(56) but setting all components' local scale = 1.0 and local offset = 0.0, exporting the shapefile, importing it into ArcGIS, figuring out the differential in extents on both X and Y, then re-exporting the shapefile with the False Easting and False Northing adjusted in the component by the amount that the X, and the Y are out in the original exported extents.

Prawns sound yummy. Even better: prawns and bananas! I think I need to eat something..

Kind regards

Justin

If projection to Lat/Long goes bananas that is a strong hint that the projection you used was wrong, not neccessary only LocalOffset and LocalScale. Assigning (not changing) the correct projection to a newly imported Drawing is a critical step. That's why Manifold is pushing you to set it correct so you don't start to add objects, that might be hard to correct later.

jsljustin, I haven't read through all that proceeds your post here so I am probably way off the mark. Anyway, just in case, I have had problems with shapefile offsets and local scales where the shapefile has been created with an image component active.

This causes the drawing to inherit the projection parameters of the image and hence when you export to shapefile and import into another package, it will be offset from all the other map data. This one of the few things that really niggles me with Manifold and the solution I use can be found at: http://69.17.46.171/forum/t65067.6#65072

Hm, well, I see that as a cop-out kind of answer, Dmitri. The word-processor equivalent of that argument is that since there is no standard "doc" format (because Microsoft changes it every few years), it is similarly useless for other word processor developers to write export mechanisms that will allow data interchange. Which is of course nonsense.

A reasonably standard practise that CAD software developers follow is to pick an older, but not very old version of, say AutoCAD, and base their exports on that version. At least if Manifold could bend its stiff neck just enough to match how ESRI uses .prj files in say, its 8.x version, it would be a boon to those of us who have clients who want that prj file. I don't care if there are 20 flavours of prj files, all I want is one that works, one that is based on some recognizable version of an ESRI product.

I also support the inclusion of a simple export function as mdsumner or ralphie have described in this thread, particularly because it would be as simple as you made it sound.

I *want* Manifold to increase its user base, just as I want to keep up with the latest Manifold versions. Your answers regarding this request show me that Manifold still has not shed that "new kid on the block" pugnacity that made reading the manual hilarious. A little less attitude and a little more cooperation would be appreciated.

follow the thread and think also that manifold could create a standart but see microsoft and OOXML and OpenXML or java open source !! when microsoft have to remove is own implementation. manifold is not microsoft and microsoft and google create format that million of people use , standart or not ; what end user people want is that rock 's . post to sales@manifold some stupid request and has i see manifold is very GUI customizable and a rich API So why user that have good skill in script/visual studio don't create such tool and open a "paypal" account . i have a friend that work in SII and was amazing when say that each new manifold format ( *.Map) could not be open in older version. it is the best way to focus of new functionnality and avoid waste time to support for older version. if ESRI apply the same for prj file, all gis user ll have prj compatible not compare to standart but each other (esri price is not an argue to migrate old software to newwer version !! ) . prj seem ( not go in deep) like .doc format except the developper that work of import/Export for openoffice work for microsoft before .......( does some free software support prj !!!??) .

i think also of an other solution could that manifold offer a plug in to third gis software like this no problem. Think of that when see the number of software that offer import/export functionnality for kml file and sketch . In this case don't have to deal with standart and the software that need this plug in in this case ll not be implement by the owner of the gis software and think after read post that only one GIS ll need to be support . pay a ESRI developper ! could this be the solution because problem occur in the software that import data ( and version software could be an headeach) . what are the solutions that appear when people want a prj file : use FME or Blue Marble coordinate conversion tools. Create an import file plugin for ESRI is the same than create and export file under manifold so the solution could be resolve only by user (paypal ? ). all this problem create a new market for conversion tool !!! ( manifold is already the best even is a gis software) but does all this tool work with no problem ?

think if there such number of prj format it is also a waste of time for esri to support it ( even copy paste code have to be use ) . so all third gis software that support it waste their time, better is user waste their money to conversion tool ( does free software could be helpfull here ? so manifold could offer easy way to use instead implement it !! ) .

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

the real question is which projection ( epsg ? ) is standart nowodays and could it be associate with ( vector OR / AND raster OR/AND file date ) already exist format (standart) for resolve incompatibility that come from projection associate with shp files in many software use by non gis user

or support (paypal) database like postgis ( is the only one i see) to better support shp/prj storage / conversion tool ?

be a non gis professional that don't want to deal with projection problem only geometry and data .

don't know if search engine is best way to find informations but about free software think yes .

google-code-NCEAS knowledge BAse

hope my writing ll help to non focus on manifold software

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

programmer don't have to think how thing ll work but how the user ll use the tool !!!

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

As regards PRJ files and plugins: we already allow extending the base functionality of Manifold via scripts and add-ins, so if anyone wants to write their own version of PRJ export or invoke the built-in PRJ export (CoordinateSystem.ToTextPRJ) that we offer, they can already do this.

We do read and write PRJ files (read automatically during the import, read or write via explicit user action in the projection dialogs, read or write programmatically). We do our best to support as many variations of PRJ files as possible for reading and stick to what we think are most typical variations of PRJ files for writing, following the "be liberal in what you accept, be conservative in what you send" principle.

If you come across a PRJ file that we do not read correctly or find that a particular piece of third-party software that can normally read PRJ files does not seem to read a PRJ file that we have written, please send a note to tech support.

That said, the situation with PRJ files is sufficiently different from the situation with DOC files (many versions, but all strictly backwards-compatible) or, say, DXF files (largely the same) that there is little hope of creating code that would read all variations of PRJ files that are out there and consequently there is little hope of closing the issue of PRJ files for the foreseeable future. This is true for all GIS products, of course, not just Manifold.

A clarification for others who follow looking to export a .prj file: it's in the project pane where you "...right click on the drawing to be exported...". I tried right clicking on the map and on the component tab in the map, but the Assign Projection only comes up when you right click on the component in the project pane.

[Wow, the hierarchy in Manifold forum sometimes puts replies a distance from the original post. Anyways this reply was in reply to the 2nd post, by danb, in this thread.]

One way to deal with .prj files is to store copies as comments then export the comment when needed with the proper file name. Using this method you can "adopt" the .prj the end user expects to see. Of course you will have to be sure to associate the proper the .prj with .shp exports....

I've always thought it would be a good idea for Manifold to import a .prj if present and store it in a drawing's Comment attribute (or a specialized attribute for PRJ).

For those scripters out there a script to import .shp could stash the .PRJ data into the comment and export the comment as PRJ too.

How to keep this Text import bound to the corrosponding Drawing, Image, Surface or Table?

Could we have a optional Comments Component bound to any other Component type?

It could automatically be created (configurable by Options) on import and with a leading time stamp take all the infos that now go to the History Pane ... and more ... like a copy of the PRJ or TFW file used on import.

The automatically created data could be wrapped in XML tags but we should be allowed to add simple text for instance to note last changes or state of data validation or copyright notes or ... simply all metadata that come to mind.

This would be redundant to the component.notes property. Somebody might have used component.notes in an application and might not be happy to loose them. Why not - while updateing map-files for a next major version - copy component.notes to such generic Comments bound to the component and in the object model set up component.notes to point to the text property of the bound Comments Component?

How the Manifold handle the Datum?

When I check the coordinate system in Manifold, I did not find the information about Datum. I export the drawing from Manifold to ESRI shape, it gives me a shape without coordinate system information. When I check the *.xml, it stores something like coordinate system. But how to define the Datum in the information system?