Good morning all. I just had a look around to see if there is a solution to exporting a drawing to a shape file, including the projection. I saw an old flame war, and a solution that does not seem to work for me, but could not determine if Manifold is capable of exporting to shape with projection. Anybody know for sure?

When I follow the instructions that other users provided, assign projection, then export using "Save as File Type" drop-down lsit, my software does not provide me with such an option. I really need this capability, and I don't need to be told it is ancient technology or be given any other sermons about the superiority of the Manifold way. Any idea how to get that missing "File Type = Project" into the drop-down list?

I am using Manifold 7.x.

Best regards,

Russell Collier

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

Why doesn't the solution work for you? I've exported hundreds of shapefiles with associated .prj files. My only beef in that thread was that the method was clunky (too many mouse clicks), not that it doesn't work.

I'm using M8. Not sure if the .prj capability was in M7, but it's getting pretty long in the tooth by now.

I don't think you can export an entire project as a shapefile, though, just a drawing component. Maybe that's the problem you're having?

EDIT: Question resolved - thanks guys

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

Thanks for the quick reply. I have no idea why the solution doesn't work for me.That's why I asked. :)

I've wondered if version 7 lacks the capability as well. I've been thinking about upgrading to version 8, but need a big enough contract to justify the extra cost.

Nope, not trying to export the entire project, just a single drawing.

Am I SOL? The steps seem to be (after exporting to shapefile):

1) Right click in Project pane on single drawing, then Assign Projection to it.

2) Right click in Project pane on same drawing, then choose "export".

3) From drop-down list, choose "Projection" as file type, giving it the same name as the earlier export.

Is this right? Have I missed anything?

Best,

Russell

ps: I have the original .prj file from the original shapefile that this drawing was clipped out of. I could simply copy it a bunch of times, and then rename it to match export filenames, but this is a slower solution.

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

Yes, you are missing something. You have to do it in two steps

1) First, right click on the drawing and export it as .shp file

2) Next, right click on the drawing again, choose "Change Projection" , click the little disk icon in the Change Projection dialog for "Save to file" and choose prj as the file type, giving it the same name as the shp that you just exported. The default is XML.

You can't export the projection directly from the "export" dialog. You have to do it from the "Change Projection" dialog. That's why I said it was a little clunky.

I don't have Manifold in front of me but...

From the assign projection dialouge, save to file, pull down menu .prj, name same as shp export...

perhaps this is where you are having trouble: make sure you add .prj to the file name, it does not automatically add the file extension (not sure why). There should be no difference from 7 to 8.

Hi Russell,

From Help:

"Exporting a PRJ File

To create a PRJ file to accompany the shapefiles for those software packages that can use ESRI PRJ files, use the Edit - Change Projection dialog's toolbar to save the coordinate information into a PRJ file. Name the file using the same name as the other shapefiles with the extension .prj."

Should be the same for 7.x. Works fine, but more clicks as mentioned.

Cheers, Aaron

Okay, that did it. I see that both "Assign Projection" and "Change Projection" allow the projection to be saved using the "Save" icon at upper left of the dialog box.

The steps above that I outlined are in fact incorrect. Step number 2 should read:

2) Click the "Save" icon at upper left on the dialog box.

Thanks, abridge, the link was useful. Wish the utility was a little more straightforward, but we're deailng with religion here, so I won't hold my breath.

Thanks once again for your help.

Russell

ps: for anyone who needs the steps in one set, they are:

1) Right click in Project pane on single drawing, then Assign Projection to it.

2) Right click in Project pane on same drawing, then click on "Save" icon at upper left of dialog box.

3) From drop-down list, choose "Projection" as file type, giving it the same name as exported shapefile.

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

Yep, you can do it from the Assign Projection dialog also.

But I generally assign a projection as soon as I import the drawing (good habit to get into) so I rarely ever go to the Assign Projection dialog later in my workflow.

Yes, me too. For this contract, my clients use Arcview 3.2. I am processing a bunch of shapefile data for them in Manifold (it's easier in most respects), and then exporting back to shapefile. Their data comes with projection files included, so in this instance, the projection is already defined for all subsets I clip out for them.

A good habit, yes, and thanks for taking time to reply.

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

Hello. I'm new to Manifold and also working with ESRI software. I'm having the same problem on exporting Manifold drawings to ESRI shapefile and losing the projection data of my exported shapefile.

I tried what you did but still it doesn't work.

Please bear with me, I'm new with Manifold so I might have done something wrong or missed a step.

Here's what I tried:

1. I exported my existing Manifold drawing to shapefile. Then used change projection to save my drawing to a .prj file with the same name as my exported shapefile. ==> when i loaded the exported shapefile to ESRI's ArcMap, the projection is "undefined".
2. I created a new drawing in Manifold (just for testing) and exported it as shapefile. Then same steps above. Also got same results.

So what do I do?

eocampo - Are you using ArcGIS 9.3?

I just did a test, and I got an undefined projection with ArcGIS 9.3, just like you are experiencing. I then compared the Manifold created prj file with one created with ArcGIS 9.3. The format (order) of the info from Manifold is a bit different than the one produced by ArcGIS 9.3. I've used this with success in the past, but it was with ArcGIS 9.2

I tested the Manifold .prj with Global Mapper, and it read it correctly. Then I tested with ArcGIS 9.2, and it also read it correctly. It looks like ESRI changed the way it reads the .prj files in ArcGIS 9.3.

All arguments about projected vs. unprojected shapefiles aside, I , and I'm sure many other Manifold users have clients that request projected shapefiles as a final product. Since I wish to make them happy by giving them what they want, while simultaneously making me happy by being able to use Manifold to do the job, I would like Manifold to improve the shapefile export feature. How about a checkbox for exporting a matching .prj file and while we're at it, make prj files that are readable by ESRI products, which unfortunately, most people still use.

"Since I wish to make them happy by giving them what they want, while simultaneously making me happy by being able to use Manifold to do the job, I would like Manifold to improve the shapefile export feature. How about a checkbox for exporting a matching .prj file and while we're at it, make prj files that are readable by ESRI products, which unfortunately, most people still use."

Why?

The last time a Ichecked ESRI products were capable of efficiently projecting drawings exported in unprojected latitude longitude form, as shape files or in any other format.

Why expend a large amount of precious development time to achieve something so trivial (but ironically very difficult to achieve), just so a lazy or incompetant shape file end-user can avoid performing a few mouse clicks and keyboard strokes.

There was only ever a great need to be able to export projected shape files, when system resources were such that the time taken to reproject drawings was so long that reprojection was to be avoided unless absolutely necessary. Thankfully, those days are long past. Now, the only need for exporting projected shape files is if the end-user does not have ability to reproject the drawing. Most modern geographic software can perform this now, so now there is precious little need for projected shape file export for this reason too.

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

Why expend a large amount of precious development time to achieve something so trivial (but ironically very difficult to achieve), just so a lazy or incompetant shape file end-user can avoid performing a few mouse clicks and keyboard strokes.

Well remember some of us are those end-users who have the misfortune of using ESRI products and it means we have also to add a few mouse clicks in Manifold to reproject (or unproject) drawings to lat/long.

I do find a lot of Manifold created prj files do not get recognized by ArcGIS and I have to reassign them in ArcCatalogue, no great effort involved and I'm sure there's an ArcScript out there if I needed to do a large amount of SHP files en masse. Some see this not being automated in Manifold as major fault, i just see it as a minor inconvenience.

I do see why ESRI users may see this as an annoyance when they have to put up with a backward GUI and buggy software - they have enough to deal with it as it is!

If I argue with a customer, he won't be a customer for very long.

And I don't accept your assertion that putting a checkbox on the export drawing dialog would "expend a large amount of precious development time." The code to export prj files is already there.

Here we go again ...

I think Tim answered this perfectly with his reasoned response to the issue raised by emilio.

Though we can argue about this all day, if the facility is offered by the Manifold GUI, I for one feel it should export shapefiles with correct anchor points that locate features correctly in package X.

Ralphie,

From what Manifold reps have said, my understanding is that it is not the coding that takes the time, it is ensuring that the .prj file produced can be correctly read by everyone else.

The problem with the .prj file is that is that it this supposed standard has become anything but. Since Manifold does not control the shape file format, there is only one solution to this (that is if we are not to abandon shape files altogether) and that is export the drawing with unambiguous georeferencing. That is, export the drawing in unprojected latitude longitude form.

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

Well, as one of Manifold's users who also needs to use ESRI products, I suppose that qualifies me as one of your lazy and incompetent shapefile end-users.

I rather thought this would turn into another religious war, which is depressing.

I don't see what the problem is with shapefiles, why the priests of Manifold cannot accept this heresy. Why not admit that other GIS users must also use ESRI products and just settle on one Shapefile format - ESRI's? Why hide the steps for simple exporting away amidst much sneering and scoffing about the file format?

I just don't get it. The resistance inside Manifold and amongst its acolytes borders on zenophobia.

My export problems are solved, for which I thank the fellows who so graciously provided their time and knowledge.

I'd appreciate any new information that pertains to solving this export problem I encountered. I won't participate in any more useless discussion around what is obviously a real sore point among Manifold elite - the humble, ubiquitous shapefile.

Russell in Canada

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

I'd be pretty surprised if version 9 doesn't address our issues with shapefile an prj export, if only to shut us up. This is pretty small potatoes compared to the areas where Manifold is trying to push the envelope, but it is a significant issue for us mere mortals who must work with and export projected shapefiles to our lazy ESRI-using clients just about every day. I for one, wouldn't know a CUDA if I caught one, but wish Manifold the best in that regard.

My understanding based on previous and lengthy threads, is that ESRI itself does not have one clean standard to adhere to.

if only to shut us up.

No need to ever shut anyone up. On the contrary, Manifold encourages folks to write in suggestions making it clear exactly what they want.

Nobody at manifold gives much of a hoot about one format or another. After the first hundred or so they are all the same, with the only question being how users feel about different formats and what, as a matter of technology and operation by the spectrum of users interested in that format, are the positive or negative effects of a given format. That's what the suggestions intake process helps accomplish and why Manifold encourages people to write. There is even a tips page to encourage folks to do so with maximum impact. See http://www.manifold.net/info/suggestions.shtml

As is noted in the above link and has been well noted in the past, commentary in this forum by design has no influence whatsoever on the product planning process. Only suggestions sent in as recommended by the above have any impact.

It's also very helpful to encourage constructive suggestions (what everyone presumably wants) that the Suggestions tips process forces people to be specific about what they want if they hope to have any impact, especially when it comes to new formats. This is, after all, a very rare and highly valuable chance to provide direct input on how millions of dollars of engineering time should be used. Nobody should want that investment to be steered by people who don't think they have the responsibility to carefully think through what they are asking before they ask it. Especially when it comes to formats, those folks who take the time to carefully think through something will end up doing a more effective job of lobbying.

Folks who have strong feelings about PRJ should post the full text of the suggestions they sent in for that. I think that will be very educational to see that relatively few people feel strongly enough about this to have bothered to lobby for it as recommended by the Suggestions page.

About PRJ:

Discussions about PRJ tend to be muddied by global assumptions that are simply false. PRJ is fundamentally an ambiguous format that depends upon shared assumptions. If you disagree with that, please post your definition of PRJ and I'll point out to you which parts of that depend upon telepathy, that is, shared assumptions.

That's still OK for many uses, which is why some people use PRJ all the time and are happy about it. If you are working with the same ESRI package as someone else and you both make the same assumptions and don't take advantage of the tricky stuff PRJ allows you to do that breaks interoperability, well, it's no surprise the results will work fine. Many people within the ESRI community use PRJ all the time with perfect success. But few of them realize the degree to which their success at interchange does not apply to others.

Experienced folks know that there are plenty of instances where the ambiguity of PRJ causes chaos, both within exclusively ESRI usages (as in the case of different ESRI packages) and especially among those people who don't use ESRI software. That latter part is a big effect because most people who use shapefiles and who encounter PRJs are not ESRI users. Shapefiles are widely utilized by non-ESRI software, from GPS devices to coffee pots, it seems these days, and such non-ESRI software installations far outnumber ESRI software installations.

Anything Manifold might do has to work with all three communities: non-ESRI users of shapefiles/PRJ, ESRI users whose assumptions align and are happy with PRJ, and those whose assumptions do not align and thus have experienced problems even though they use exclusively ESRI software.

If you happen to fall into that group of folks who are using ESRI software with PRJ successfully, there's no resistance to helping you out from Manifold so long as what is done does not add to the chaos and pain experienced by other users. Can't have any of this robbing Peter to pay Paul stuff, after all.

What you'll find if you try to compose a suggestion as recommended by the Suggestions tips page is that you'll end up writing your own more precisely defined version of what folks loosely describe as "PRJ." For example, you'll provide a list of acceptable text strings that are allowed in PROJCS and other strings. None of this "make it up as you go along" will be allowed in the standard you specify.

In fact, if Manifold users who like PRJ and who want it (whatever it is) supported in Manifold want to come together to create their own, common "Well Known PRJ" standard (WKP... I like the ring of that) they'd be doing not only themselves a service but also a service to the many ESRI users and non-ESRI users who have suffered the pain and chaos of a poorly designed PRJ scheme.

Once you write up a WKP standard that numerous other Manifold users also support, your request to Manifold then becomes a very simple one: "Please add a checkbox to shapefile export that writes an accompanying PRJ file that conforms to the WKP standard. The checkbox should not be enabled if anything about the current projection system does not fit within the WKP standard."

That will still leave the issue that whatever you choose to write for a WKP standard will cause many people to hate you, because whatever you write will fail to cover a lot of different possibilities that PRJ "standard" leaves open for chaos-creators, and there will be no way to differentiate your .prj files sensibly written to the new WKP standard from .prj/shapefiles which do not conform to that standard. There will also be the problem that very few will know what WKP is or care to implement it. But at least you'll be making progress and if you have a hot button about exchanging given files with your clients you can assure that your interests will be represented in WKP and what you do with Manifold in this will work for you and for your clients.

Can't resist a side comment:

I for one, wouldn't know a CUDA if I caught one,

Don't give up so easily. If you can spend $200 to do in seconds what otherwise would take minutes, that's worth learning about.

OK, I guess the well-known prj standard should be one of those created by ESRI that everything from GPS' to coffee pots can read. Choosing which version to suggest to sales may require a bit of research and soliciting input from those who seriously want better projection file creation (not those who go into a snarling rage over any mention of shape or projection files).

I was just kidding about not knowing anything about CUDA. In fact, my brother once owned a '68 CUDA and it hauled ass!

LOL

Perhaps I misread...

OK, I guess the well-known prj standard should be one of those created by ESRI that everything from GPS' to coffee pots can read.

... but if I understood that correctly (with emphasis on should be one of those created by ESRI ) that's wishing away the task with a false assumption, that ESRI has created some "standards" from which you could pick one. If ESRI had bothered to create a real standard there wouldn't be the need for folks who want to use PRJ for interchange to come up with a WKP standard, that is, a real standard.

In point of fact, it's easy to construct a PRJ that adheres precisely to every writing ESRI has ever created on the subject but which cannot be correctly interpreted by any software. People do that all the time, which is why there are so many threads in so many different GIS forums for so many different software packages, including ESRI's, about hassles with PRJ.

Choosing which version to suggest to sales

Not so easy. As noted above, there is no "version" that's suggestable because ESRI didn't bother to create such a thing. There's just whatever set of assumptions that work for you because none of your interchange partners is using anything significantly different than what you assume. Broaden the constituency and all kinds of chaos happens. Ask anyone who has tried to use shapefiles with PRJ for interchange in international settings, for example, where it is frequently the case that the assumptions people make about the names of projections and datums are not the same.

It's not so easy to write a WKP that eliminates such ambiguity in PRJ. As I mentioned earlier...

you'll end up writing your own more precisely defined version of what folks loosely describe as "PRJ." For example, you'll provide a list of acceptable text strings that are allowed in PROJCS and other strings.

My advice would be to not try to solve the entire world's problem with PRJ but to simply focus on what you do all the time with your customers. If other Manifold users do that then it doesn't really matter if WKP doesn't ever become the darling of OGC or the UN or whatever, it will be useful enough.

Perhaps I am missing the point, but everytime this comes up, we seem to end up having this same arguement about PRJ existing in many different flavours due to ESRI failing to create a robust standard. Surely the issue in this case is that noted by tjhb in his initial response to emilio (i.e. anchoring features to image origins)?

I couldn't care less about the religion of standards.

I just want fewer mouse clicks.

Surely the issue in this case is that noted by tjhb in his initial response to emilio

It's an issue for sure as noted in my other posting. But it is also enmeshed in a parallel discussion about PRJ. By the way, the problem with PRJ is not that it exists in many different flavors (that's "flavours" for you Brits...), for PRJ really is only one flavor: the problem is that the one flavor allows for ambiguity.

It's like GML. GML is actually extremely well defined: there is just one version of what GML is and it is precisely defined in BNF (Backus Naur Form). The problem with GML is that people think it is a format when it is not a format, it is a language. You can use GML to make up darned near whatever format for data content you desire, so the result is babel. It's as if someone wanted to have a technical standard for interchange of diesel engine parts, specifying dimensions and such, so that different factories could produce spare parts that could be interchanged for engines, and the committee in charge of specifying the interoperability standard announced that the new format for such interoperability specs would be... English. Well, that's fine as a choice of language I suppose but it doesn't say anything about how the parts should actually be dimensioned. It just chooses a language that will be used for writing such descriptions without actually writing the descriptions in a common, unambiguous way.

PRJ is far, far better than GML in the structure it proposes and the relatively few loose ends it does not tie up, but all you need is one loose end and the result is ambiguity.

Thank you Dimitri, this has been another of those rant threads where I have learned something new from the considered responses of the non ranting posters.

Agreed Dan. My favorite learned nugget is that:

... be able to link a shapefile into Manifold and edit it on the fly. That soon will be available.

This another wonderful new feature for version 9. "Soon" can't be soon enough :-)

Cheeze of Fire!!!

Thanks Mike, I missed that little nugget of information! Now that we've started using PostGIS, and can successfully link to, and edit the data with Manifold, ArcMap, and AutoCad Map 3D, it isn't quite as "important". But, I'm sure we will use this new feature a lot for data we don't need to import into PostGIS!

... be able to link a shapefile into Manifold and edit it on the fly.

Will this feature be available, if possible, for other drawing file formats too?

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

My advice would be to not try to solve the entire world's problem with PRJ but to simply focus on what you do all the time with your customers.

OK, what I do when a client insists on a projected shapefile with a matching projection file, is export the shapefile I created in Manifold in whatever projection they asked for, then I take an ESRI created projection file and rename it to match the Manifold created shapefile. This is a pain in the #$%% but it works like a charm. If there's a better way, other than insisting on shipping it out as lat and long, I'd like to know.

By the way, I accept all of the arguments made here about there being no standards for projection files and that lat/long is the best way to go, but as I and about a zillion others have stated here, some clients, usually in government insist on projected shapefiles. They know of nothing else. In fact, they often put it in the scope of work and if we Manifold users want their juicy contracts, we have to go along with it and say "Thank you Sir, can I have another?" It aint fair and it aint right, but it's the way it is. At least for now while ESRI is still alive.

OK, what I do when a client insists on a projected shapefile with a matching projection file, is export the shapefile I created in Manifold in whatever projection they asked for, then I take an ESRI created projection file and rename it to match the Manifold created shapefile

As noted in my other posting, the above works only to the extent you and your customers share assumptions. If it works for you with the projections you use and the packages employed, you and your clients have the good fortune of falling into the one group of the three I mentioned who are using PRJ successfully for interchange. If you decide to participate in any ad hoc WKP project it would be helpful for you to enumerate the projections you use.

But it is important to note that your experience is not always shared by others. In addition to the two other groups I mentioned that have obvious problems using PRJ, it also has the insidious trait that not everyone who thinks it is working for them is actually being successful with it.

It seems like just about everyone on the planet who has done GIS for a period of years will have a story or two to tell about data that looked very correct but ended up being off just a bit with all sorts of woe encountered trying to figure out just how it ended up being off. PRJ and shapefiles are at times the source of such chaos, and avoiding that chaos is part of the mission in dealing with the ambiguity of PRJ. I'm not in any way saying you've encountered that or have done any disservice to your clients. I am saying that not everyone has had a happy experience using PRJ and that the problems people have encountered using it have to be reckoned within any use of it by Manifold.

Fair enough. I would be happy to participate in any ad hoc WKP project and to enumerate the projections I use and provide any relevant information regarding which flavor (for lack of a better descriptions) I've used. BTW I thought your suggestion regarding a "Shapefile Plus Format" was brilliant. I agree that we're talking about spending a lot of time fixing outdated technology, but the sad fact of the matter is that many people are still using it.

As for the tone of this thread, I see it as mostly positive (people who are trying to learn something and others who are sharing their knowledge and possible solutions) and 100 percent worthwhile. Thanks for the discussion.

I rather thought this would turn into another religious war, which is depressing.

This problem and the recommended solution has nothing to do with zealotry. It is the sensible pragamatic solution to what has become a tangled mess. In the days when ESRI products were the only show in town this problem did not exist. It has come about because ESRI at the get-go created an inadequate open file format for its products users and anyone esle to use. Then did not standardise the shape file definition and the later again- inadequate and open .prj file format to correct the iadequacies of the former. It then allowed both formats to gradually mutate as other software that could read and write shape files and their versions of .prj files became increasingly common. So what we have now is an entire zoo full of different species of shape and .prj file all using different terms for projections, projection parameters and datums etc. Manifold does it best to intepret these different species.

Of course the ideal long term solution is for Manifold in colaboration with other major players such as Oracle or Microsoft, is to create a 21st century geographic drawing file format that is fit for purpose and to standardise it through a body such as the IEEE. ( http://www.ieee.org/web/standards/home/index.html )

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

:) I've just read everything posted since I announced I found my problem was solved. I have to admit, it is hilarious - to me, coming from the outside, the arguments on all sides sound very much like religious cant. Everybody is so sure they are right. Not many people actually listen to each other. I got the sermon on the mount anyway, even after I said I didn't need it.

I was and am grateful to the folks who lent their time and expertise to help me solve this problem.

I am curious how long this discussion could continue past this point, where my question has been answered. I offer as proof for my original assertion that this discussion is essentially religious, the fact that people seem unable to stop themselves from arguing their point long past the time when anyone is listening. If indeed anyone ever listened.

Thanks people, for taking time to add your voice to this discussion.

Russell in Canada

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

I have to admit, it is hilarious...

Oh I wouldn't go so far as claim that just yet, for General Funston has yet to arrive...

"I have to admit, it is hilarious - to me, coming from the outside, the arguments on all sides sound very much like religious cant. Everybody is so sure they are right. Not many people actually listen to each other."

The explanations given for why exporting projected geographic drawings in shape file format causes no end of problems have absolutely nothing to do with dogma or product competition. They are instead ones caused by the chaos of format mutation and ad hoc unsupervised evolution resulting in non-standardisation. If you do not yet appreciate this, then you have read everything and understood nothing. It is you that is being unreasonable and dogmatic in the face of reasoned explanation for why creation of a prj file that is guaranteed to be correctly readable by any other software cannot be acheived and the pragmatic solution recommended to prevent these problems ever arising.

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

The mosquito Emilio is right about two things. About the problem he raises here (and which he, like others, has raised before)—that exported drawings will alternatively have zero or non-zero local offsets, unit or non-unit scales, depending on whether they were created around a raster—and also about the cant.

The second thing is a natural affliction. Why the first thing has not been remedied years ago I don't know—until I ask how much I care about it myself. I hardly care about it at all, certainly not enough to find time to write to Tech. Maybe that's just the reason why it hasn't been fixed.

New Manifold users probably never write in, because they lack the confidence to think they could ever be right.

By the time a user has enough courage to write directly to Manifold about a problem, they will also have become used to certain deficiencies, and made workarounds, and made the workarounds firm friends.

On a sort of related note, Manifold is the only software I've seen that includes the raster offset/scale in the projection metadata. "Usually", these are separated into the raster "transform" - the storage of a corner position and the pixel size, and the "projection" - the coordinate system (cs), cs parameters, datum, false offsets, unit, unit type and scale correction.

Drawings, and also maps, don't really need the offset/scale used by rasters, so I'm interested in learning what the reasoning is there. Tim says it helps speed rendering, but I don't see why - can someone clarify that for me?

(Note that Manifold doesn't support the X/Y shear parameters that are often present in a "raster transform", so it's not clear to me how the current setup would be extended for raster, and not vector if these were supported).

I think partly the issues arising from the "drawing inheriting raster offset/scale" thing is due to the fact that the raster stuff simply isn't usually present in the metadata available for vector data. I'd prefer that drawings always simply defaulted to 0/1.

Does anyone know any examples of the (analogy to the Manifold) raster offset/scale being included in the projection metadata in other software, or metadata systems?

I presume the offsets are something to do with the way Manifold stores and manipulates geographic positions internally. Like you, i cannot explain why.

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

Drawings, and also maps, don't really need the offset/scale used by rasters, so I'm interested in learning what the reasoning is there. Tim says it helps speed rendering, but I don't see why - can someone clarify that for me?

It's not a rendering speed thing as small things like that are irrelevant given what already must go on in the rendering pipeline. It is done to make assumptions explicit, to allow more general usage.

Manifold is the only software I've seen that includes the raster offset/scale in the projection metadata. "Usually", these are separated into the raster "transform" - the storage of a corner position and the pixel size, and the "projection" - the coordinate system (cs), cs parameters, datum, false offsets, unit, unit type and scale correction.

If Cartesian offsets/scales are in play they are indeed part of the assumptions that define the coordinate system being used. Manifold does its best to make those assumptions explicit and to maintain them accurately at all times. It's just like Lat/Lon not being unambiguous if you exclude the assumption of what datum is being used (a whopper of an assumption). For some folks the datum is not part of the Lat/Lon "projection." But it is, and if you don't carry that along as a fundamental property of the data you lose that information, as formats which take latitude and longitudes as some sort of universally precise language will lose. Likewise for offset/scale - it is a property of the projection scheme that makes sense to expose/maintain in the same place as other projection info.

If they are to play nicely with other data, Manifold drawings which have been created near raster data should be checked to see whether they have "rasterish" offsets and scales. If a drawing has, it should be reprojected before being exported.

and

"This projected data may not be positioned correctly by software that assumes an origin at grid location (0, 0)".

Yes. If you create a drawing based on an image and the software guarantees you that the drawing will inherit the coordinate system from the image, well, the software darn well better do that. None of this "I'll say it's the same projection but in fact I'll make it different by altering a key assumption, such as assuming a different origin." Manifold is one of the few software packages that seeks to provided a unified environment for working both with images and drawings so it will indeed end up exposing some "rasterish" ideas within drawings. Some non-GIS packages also will use offset/scale with vector data, where it is useful to expose/manipulate/maintain those parameters to mash the data into the form preferred.

I don't disagree there are simplifications that could be made, assumptions that could be brought into play to make it easier for one constituency or another. But then you have the need to educate folks as to the operation of those simplifications and assumptions that you make. The current Manifold approach is to expose whatever factors are in play as explicitly as possible and let folks make their own decisions how they want to manipulate data to pipe it into various formats.

Keep in mind that all this fuss is talk about how to best lobotomize data to make it fit into a format, shapefiles, that is limited in what it can store. Keep your data in a rich environment like Manifold itself and there is absolutely no issue, because the software maintains all that for you at all time. The question is how to cast that data into a simpler format.

There is a broad range of automation that could certainly be done when exporting to legacy formats like shapefiles that have profound limitations. Manifold already does some of that, like automatically splitting out points, lines and areas from one drawing into a triplet of shapefiles. There is already some column name simplification as well. So sure, you could have simplification and automation of projected data as well.

One end of that could be that Manifold always re-projects shapefile data into lat/lon WGS84 (0,0) origin form, and that's that. No projected data allowed. Another approach could be to offer to write a PRJ using a specified WKP set of allowed projections. If it doesn't fit into that allowed set, no export allowed until you re-project it. A third could be automated re-projection into the "most similar" projection from a WKP set of allowed projections.

It's really no big deal one way or another, but given the very many constituencies Manifold serves it is almost certain that whatever is done to serve some constituencies will raise howls from others. So it makes sense that the company wants to hear from users to see what scheme, if any, users prefer. If people don't care enough about this to ask for one thing or another, well, there are many other things which people care so much about that they send in thousands of requests so there is no lack of things which the user community wants that should be done. A good example of that is that virtually no one, darn near absolutely zero, has lobbied for a change in shape export. In contrast, what is frequently requested is the ability to edit shapefiles "in place." That is, to be able to link a shapefile into Manifold and edit it on the fly. That soon will be available.

My own suggestion internally for some years has been that Manifold should seize the opportunity to throw a wrench into ESRI's works, and to hijack the shapefile format by introducing a Shapefile Plus format, which would be shapefiles extended/modernized in an expert way. It would be fun to publish a "PRJ Format Definition" document that's official-looking and widely distributed that includes an accessory file providing the equivalent of WKP in a handy XML form so that developers all over the world that want to use shapefiles can incorporate it easily (you know how most developers are... rationally choosing the path of least resistance!). You could even introduce a WKS (Well Known Shapefile) OGC-like construct for spatial DBMS storage, a sort of more sensible personal geodatabase or SDE thing. We could then all have a rational shapefile format that actually worked and which had none of the problems endlessly discussed in threads like this. ESRI would hate that, because that would work against their desire to prevent the commoditization of shapefile format, that is, the ability for people to use shapefile format to not have to use ESRI products.

My idea has never gotten traction internally because you can deliver more utility and power to users by working on modern technology instead of old technology. It seems a shame to spend time on fixing a decades-old format, sort of like coming up with a tape cassette cartridge that is more jam resistant in an era of MP3 music.

My request would be to amend the export to SHP, DXF, MID/MID, etc. functions so that the Local Offset/Scale are set to 0,0 for projected data. No need for internal components to mimic this behaviour as Manifold handles this already.

Thanks for the explanation Dimitri. I learnt this stuff from using Manifold - I remember struggling to understand how offsets/scales were stored in other environments because I was looking for it in the projection metadata!

Nick:

The raster offsets and scales are there to transform pixel indices into real world coordinates - there's no mystery there, it's just that other packages will store those values in a manner that is separate to the projection metadata. "Projection metadata" systems (WKT, OGR CRS, EPSG, PROJ.4, and others) simply don't have these local offsets and scales - well not any that I've seen. I think the separation is there as traditionally vector and raster data are handled very differently, and this is one area (component projection) where Manifold has removed that distinction.

"My own suggestion internally for some years has been that Manifold should seize the opportunity to throw a wrench into ESRI's works, and to hijack the shapefile format by introducing a Shapefile Plus format"

I heartily second this suggestion. However, it would better if the shapefile name was dropped (too much legacy baggage) and new format, albeit one based on the shape formats was created. A format that allowed areas (polygons), lines (polylines) and points and their associated field values tobe stored within one file and one wherein the projection parameters were embedded in the file (of course they could also be provided as an xml file too). Oh and one that allowed meaningful extended file names to be used.

Call it the geographic drawing format (.gdf) or geographic drawing export format (may be .gdx). :-)

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

"One end of that could be that Manifold always re-projects shapefile data into lat/lon WGS84 (0,0) origin form, and that's that. "

I like this solution myself. It's clean, it's simple, and it's predictable.

If by "work around" you mean the recommendation that drawings be defined in geographic coordinates when exported as shape files, i would not term this a work around. It is using the one commonality that all geographic software can take advantage of and get the correct result each time. That is being able to import shape files correctly producing a correctly georeferenced image, either by reading a .prj file which states the drawing is unprojected, or if the .prj cannot be read, by assuming the drawing is unprojected.

There is also another major advantage to the end user recieving a geographic drawing in unprojected form, (whatever the export file format). That is it ensures that the end-user does not take the exporters word that the drawing is in the stated projection. By forcing the end-user to reproject the drawing to their desired projection, it forces the user to be responsible for this step and ensures as a far as possible that the drawing is in the correct desired projection. It is thus acting as quality assurance procedure.

Dream no small dreams for they have no power to change the minds of men. - After Johann Wolfgang von Goethe

Nick Verge: Now you've really pissed me off.

You said "It is you that is being unreasonable and dogmatic in the face of reasoned explanation for why creation of a prj file that is guaranteed to be correctly readable by any other software cannot be acheived and the pragmatic solution recommended to prevent these problems ever arising".

Nick, I don't give a rat's ass if it a prj file is readable by any other software except for one - ESRI software. So far as I am concerned, the rest are irelevant. Just one standard, Nick, just one, not every other standard under the sun. All GIS software developers match AutoCAD's releases, and take care to define translations for specific releases (e.g. Release 14, or 12, or whatever). All other word processors take care to define maybe only 1 version of Microsoft Word that they translate to. They pick one standard to translate to and they stick to it.

Manifold and its acolytes bleat on about "too many standards" and do none of them openly.

Go pee up a rope. Your reply was really stupid.

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

1)Make a duplicate of the layer you want to export (right click on the layer and hit duplicate)

2)Right click on the new layer and hit Assign Projection and accept whatever the value is.

3)Then right click on the layer again and hit Change Projection.

4)Replace the values in Local offset X and Y with 0.0

5)Replace the values in Local scale X and Y with 1.0

6)Then hit OK and this new layer can be exported and will carry all the georeferencing information.

You could do all this with the original layer but it is safer to make a duplicate, I usually just as the word ‘Export’ to the end of the name to keep things straight.

I hope it helps.

Cheers my friend

Mohammad

mnourpour, that is very succinct and readable. Thank you for such an enlightening post. This is exactly the kind of help I originally asked for. Please accept my commendations.

Sincerely,

Russell Collier in Canada

Russell Collier Athyrium Services & Consulting 24227 Walcott Road Telkwa, BC Canada V0J 2X2

YOU WELCOME