Sharing map parts with OCAD users

[kjetilk]

Hi all!

This may be just a question, or it may be a feature request.

This is my situation: I'm doing just minor modifications on a map, and I'd like to submit those changes to the people who are maintaining the map so that they may include it at their discretion, and they are most likely using OCAD at this point. How would I do that?

It seems to me that I should be making a Map Part in OOMapper and make my changes within that part. So, it seems like a solution is to save those changes into an OCAD file, and possibly the maintainers could open that and see the changes, and merge them. Now, I have no idea how OCAD would behave, and I'm not thoroughly into OOMapper either, since this and a bit of course setting is all that I do, but I figured I'd share the use case. :-)

Cheers,

Kjetil

[lpechacek]

Talking about minor modifications which may or may not be accepted by the main cartographer, I'd recommend exporting a bitmap image from Mapper. The bitmap can later be opened as a template in OCAD or elsewhere. In development version od Mapper the map georeferencing will likely be right and the exported bitmap can be georeferenced by world file.

Below is an example of I map I revised prior to a training and shared with the maintainer earlier this year. By that time I was unsure the file format produced by Mapper is correct and I wanted to avoid damaging one of the club's most valuable maps. My changes were highlighted with purple marking for easier navigation among changes. HTH

[dg0yt]

This is my situation: I'm doing just minor modifications on a map, and I'd like to submit those changes to the people who are maintaining the map so that they may include it at their discretion.

How would you do that when using OCAD?

Map parts are a way to organizes shared work in Mapper files. Of course it helps to split out your work for passing it back to the map maintainers. However I wonder what would be the procedure to actually merge your modifications in OCAD. Even additions (copy & paste?) might be difficult, depending on whether we succeed in preserving relevant symbol properties. (Does the code number suffice?)

[kjetilk]

This is my situation: I'm doing just minor modifications on a map, and I'd like to submit those changes to the people who are maintaining the map so that they may include it at their discretion.

How would you do that when using OCAD?

I have no idea, I have never used OCAD... :-)

Map parts are a way to organizes shared work in Mapper files. Of course it helps to split out your work for passing it back to the map maintainers. However I wonder what would be the procedure to actually merge your modifications in OCAD. Even additions (copy & paste?) might be difficult, depending on whether we succeed in preserving relevant symbol properties. (Does the code number suffice?)

Right, so I would think code number would suffice, but since I don't know how this would be done from the OCAD side, I don't know.

What would be really interesting is a git-like workflow...: You could potentially have layers, and merging down layers is a fairly standard operation, but you could also signal conflict if two modifications touch the same point.

[kjetilk]

Talking about minor modifications which may or may not be accepted by the main cartographer, I'd recommend exporting a bitmap image from Mapper. The bitmap can later be opened as a template in OCAD or elsewhere.

That's interesting, but with a bitmap, it would take substantial effort from the map maintainer's side to merge it, wouldn't it?

[ollesmaps]

In Ocad, the best way would be to cut out the piece of map you are editing. Edit it. Import it back.

[kjetilk]

In Ocad, the best way would be to cut out the piece of map you are editing. Edit it. Import it back.

Hmmm, so, to take two examples: One is a 100 meter new track, and one is a house that burnt down and is now a ruin... Would that be suitable for that kind of edits?

[dg0yt]

What would be really interesting is a git-like workflow...: You could potentially have layers, and merging down layers is a fairly standard operation, but you could also signal conflict if two modifications touch the same point.

Yes, git shoud work well with OMAP files which use map parts ;-) Map parts are not layers (in a z-level sense), but they do indeed group the objects in the files. Maybe we could also use this to compare files.

I would be glad we could identify something similar to map parts in OCD files (object groups, tags etc.).

[lpechacek]

That's interesting, but with a bitmap, it would take substantial effort from the map maintainer's side to merge it, wouldn't it? ... Hmmm, so, to take two examples: One is a 100 meter new track, and one is a house that burnt down and is now a ruin... Would that be suitable for that kind of edits?

Then it is unclear to me what you want to achieve. I don't think modifying two objects in a map requires substantial effort. For that a bitmap/PDF with remarks suffices. For larger changes modifying or adding parts of a map follow Olles' advice.

On the general idea of "patching a map", that occurred to me too some years ago. It would be cool to have a map patch to be applied to mapwork by a contributor. If you have an idea how to implement it, feel free to contribute. A map diff would be great too.

[dg0yt]

On the general idea of "patching a map", that occurred to me too some years ago. It would be cool to have a map patch to be applied to mapwork by a contributor. If you have an idea how to implement it, feel free to contribute. A map diff would be great too.

Our Undo/Redo steps are very much a record of what was changed. It would need some elaboration, but starting from the same map file, it should be possible to "replay" the steps even on the pristine OCD file, leaving everything else untouched.

[kjetilk]

That's interesting, but with a bitmap, it would take substantial effort from the map maintainer's side to merge it, wouldn't it? ... Hmmm, so, to take two examples: One is a 100 meter new track, and one is a house that burnt down and is now a ruin... Would that be suitable for that kind of edits?

Then it is unclear to me what you want to achieve.

OK, those two were only examples, and probably not good examples :-) . These edits originated from when I organized a club race, and found 10-15 changes. They were spread quite evenly out around the courses that I set, thus also quite substantial part of the map was affected. I made those changes in the map before printing the courses, and it took me an hour to draw them all. I'd like to contribute them back to map maintainer. It seems to me that sending bitmap would make the map maintainer do the same work as I did, it takes an hour to draw. Following Olle's advice, I would cut out a large section of the map, which would not be desirable either.

So, yeah, a patch behaviour would be nice. You could potentially hook up the undo/redo steps to git commits, with each commit a step...

[otoomet]

I am often in a similar situation when mapping with a group. Depending on the nature of the edits I have submitted just changes (great if you just add new features), or edited the whole map (if changing many existing objects). I think what is needed is diff-merge type tool (see #741), designed for highlighting the differences visually. Github does a decent job but it only compares the textual representation and that may be hard to understand. True, it would not help with those who are working with ocad.

[kjetilk]

Indeed, github is nice for code, but it can't help us do this right out of the box, but hooking commits into the undo-redo feature could work.

[jmacura]

What would be really interesting is a git-like workflow...: You could potentially have layers, and merging down layers is a fairly standard operation, but you could also signal conflict if two modifications touch the same point.

Something that occupies my mind for some time already. It is quite simple and straight-forward to put your .oom files under version control, but naturally, no VC supports visual diffs for OOM files. Developing stand-alone visualizer for the changes in each commit is not a simple job either, as the .oom file structure is changing with new versions of Mapper and there is no documentation for the temporal file structure anyway... Creating a tool which would allow a maintainer to inspect objects changed in a commit (or a series of commits) created in the file by other mapper(s) and let him graphically choose which changes to perform and which of them deny, it sounds like a sweet, but distant future :-) What I am still not sure, whether it make sense to develop such advanced version-control tool as a part of the Mapper itself or if it should be a stand-alone software.

[ghost]

Some one already proposed add timestamps to map files (for marking revisions). It was not best idea...

But what about adding special tag to each object after it was created or edited, for example:

• timestamp=YYYYMMDD-HH-MM-SS
• revision=XXXXX

Also, such function should be optional (as not all users need it) and could be enabled/dissabled in "Settings".

[otoomet]

@Symbian9 -- I think this is a question about how much revision control job should OOM do, and how much it should leave for a dedicated one (like git). I'd personally prefer the latter option (no undo information in files, keep order of objects as consistent as one can), but I agree there is a strong case for the former too. So maybe an option for (RCS mode / standalone mode) in settings?

[sfroyen]

Slight tangent to the topic...

In the latest version of Terje Mathisen's Lidar tools, there is a small program that converts a bitmap image of a vegetation map to a DXF file. I was able to get Mapper to import this DXF file, which needed a small fix to work with GDAL, after which it converted perfectly to vegetation objects. Since this script was created to work with OCAD, something similar might work here.

Another possibility, have Mapper sprout a DXF export facility?

[dg0yt]

Another possibility, have Mapper sprout a DXF export facility?

Export as geospatial vector data (as supported by GDAL) is available in the unstable builds and will be released with Mapper 0.9.

[dg0yt]

In the latest version of Terje Mathisen's Lidar tools, there is a small program that converts a bitmap image of a vegetation map to a DXF file. I was able to get Mapper to import this DXF file, which needed a small fix to work with GDAL, after which it converted perfectly to vegetation objects. Since this script was created to work with OCAD, something similar might work here.

@TerjeWiigMathisen We discussed an issue with the tools' DXF files in #828. I wonder if this is the same issue now.

[sfroyen]

Mapper's DXF contour import has worked fine since the switch to GDAL.

Terje's vegetation DXF is using hatches. My fix was indeed to add a code 92 2 (boundary path type) record between the code 91 and 73 records (as #828 suggests). The GDAL code expects this -- I have not looked at the DXF specification.

On Oct 6, 2018, at 01:47, Kai Pastor notifications@github.com wrote:

In the latest version of Terje Mathisen's Lidar tools, there is a small program that converts a bitmap image of a vegetation map to a DXF file. I was able to get Mapper to import this DXF file, which needed a small fix to work with GDAL, after which it converted perfectly to vegetation objects. Since this script was created to work with OCAD, something similar might work here.

@TerjeWiigMathisen We discussed an issue with the tools' DXF files in #828. I wonder if this is the same issue now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[TerjeWiigMathisen]

As long as this addition still works with OCAD I'll include it in my "official" distribution. :-)

Terje

sfroyen wrote:

Mapper's DXF contour import has worked fine since the switch to GDAL.

Terje's vegetation DXF is using hatches. My fix was indeed to add a code 92 2 (boundary path type) record between the code 91 and 73 records (as #828 suggests). The GDAL code expects this -- I have not looked at the DXF specification.

On Oct 6, 2018, at 01:47, Kai Pastor notifications@github.com wrote:

In the latest version of Terje Mathisen's Lidar tools, there is a small program that converts a bitmap image of a vegetation map to a DXF file. I was able to get Mapper to import this DXF file, which needed a small fix to work with GDAL, after which it converted perfectly to vegetation objects. Since this script was created to work with OCAD, something similar might work here.

@TerjeWiigMathisen We discussed an issue with the tools' DXF files in #828. I wonder if this is the same issue now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenOrienteering/mapper/issues/1139#issuecomment-427580246, or mute the thread https://github.com/notifications/unsubscribe-auth/AYDgJoHZugvH9qkOA1Wy1eu_ADiuoN8cks5uiMUugaJpZM4W1ejQ.

--

• Terje.Mathisen@tmsw.no "almost all programming can be viewed as an exercise in caching"

[ghost]

Here is a guide by @henrikopersson for organizing collaborative mapping with Mapper app via shared GitHub (git) repo:

• https://github.com/henrikopersson/mapping-example

[henrikopersson]

Hi, The guide is almost complete. Will try to finalize it the next week.