Non-road maps

[chinwy]

A new set of custom polygons need to be set aside or incoprated with the city polygons - if we have not run out of un allocated polygons.

Some typical polygons needed

VEGETATION
1 Primary Forest
2 Secondary Jungel, Belukar, Riung & Jerami
3 Grass

CULTIVATON
1 Rubber
2 Oil Palm
3 Coconut
4 Sundry Tree Cultivation
5 Sundry Non-Tree Cultivation
6 Wet Padi

I will compile a full lits including POI. Would say some would be quite challenging to put into MP format like Cliff/Precipice and Landslide.

[chinwy]

The following are typical items and polygons found in typical topo maps from JUPEM maps that I have compile. Some can be used off existing standard POI and Polygons. Would appreciate some feedback and accepted and assigned codes for them. I have developed some custom POI at hand.

QTN. How do display custom polygons in Mapedit?? Quite a mess if not possilbe. Showing just red hash lines is not too helpful.

----------------------------
FEATURE RELATED TO ROAD AND RAILWAY

1 Footpath
2 Ferry
3 Bridge
4 Masonary
5 Iron
6 Wooden
7 Railway Bridge
8 Tunnel
9 Railway
a. Station
b. Halt

BUILDING

10 Mosque
11 Church
12 Chinese Temple
13 Hindu Temple
14 Buddhist Temple
15 Sikh Temple

OTHER CULTURAL FEATUE & MISC CONSTRUCTIONS

1 Electricity Transmission Line
2 Telephone Line
3 Pipe Line (Other than water)
4 Concrete Wall
5 Fence or Hedge
6 Mining Area
7 Quarry
8 Airfield/Airstrip
9 Rifle Range
10 Cemetery
11 Earht Satellite Station
12 Wireless Mast
13 Archaeological/Historical Festure
14 Oil Derrick
15 Oil Rig
16 Tank (Other than water)

VEGETATION
1 Primary Forest
2 Secondary Forest, Belukar, Riung & Jerami
3 Grass


CULTIVATION
1 Rubber
2 Oil Palm
3 Coconut
4 Sundry Tree Cultivation
5 Sundry Non-tree Cultivation
6 Wet Padi

FEATURE RELATED TO HYDROGRAPHY

1 Rocks
2 Sand
3 Mud
4 Jetty/ Wharf /Breakwater
5 Dam/ Weir
6 Lighthouse/ Lighted Beacon / Lighted Bouy

NATURAL RELIEF
1 Contour
2 Form Line
3 Cliff/ Precipice
4 Landslide
5 Broken Ground
6 Rocky Outcrop

DEVELOPED RELIEF FEATURE

1 Embankment / Cutting

[weiaun]

(sorry have been rather busy to respond)

I guess we could break down the issues with regards to the layering into:

1. The technical limitation that antyong mentioned - can't separate routing and polygons into two layers.

It's quite a sad limitation because it would make things a lot harder to customise for end users. For example, if the layers were separate .img files, then, at least on my Etrex Cx, I could select which .img files to use, even on the go.

But I guess the worst problem on the production side is that once again, a single overworked hard-working mapper has to do the final combining instead of several mappers working fairly independently on their respective layers (albeit agreeing to common standards and conventions). We'd have to synchronise production cycles.

Perhaps I'm being to positive in wondering if this limitation can be overcomed? Is it a transparency issue - that if the polygons in Layer 1 use level 24 and the roads in layer 2 use layer 24 then the roads might be covered? How about this 'polygon draw priority' in the custom type definition file - could it be tweaked? How did "rcmaps" deal with this issue in http://www.asiagps.org/community/showpost.php?p=42&postcount=2?

2. Deciding which elements go into which layer

It seems broadly there there are 3 bits to this issue:

There are element types which by their own nature will always fit into one layer only - e.g. all road types would always go into the road layer. Sorting out which goes where would take a bit of thinking but once that is done, it would be unambiguous. (Let's call these Type A elements)

Then there are element types which could fit into different layers, depending on it's context - e.g. rivers (if it's big, I guess it would fit in layer 1 (physical), if it's within an urban area it would make sense to put in in the road layer, but if it's in the middle of a jungle then it would surely belong to layer 3 (trail). We need to sort out which element types fit in this category, and what principles we could give mappers such that they would not need to check with each other again and again regarding whose layer an element belongs to. (Let's call these Type B elements)

There are also new elements which, as chinwy has researched, would be needed in a Malaysian/ASEAN map.

If somebody has a list of elements on an excel file, that would be a good start - we can divide up the elements.

[antyong (retired)]

From my own experiments, multiple polygon maps don't work well. A polygon map with a higher draw priority will cover the entire area of the main road map in your GPS device. Making the map transparent creates other complexities.

We lessen the workload of the main mappers by each drawing our own polygons and non-routable polylines. I will combine these objects programatically into the main map before compilation. This method works smoothly for our street and city polygons so far.

The best way to get things working is to draw your own physical map objects in a mp file and submit to me. If these objects can be inserted to the main map then it will be smooth sailing. If not, we will find a way to overcome the limitation.

[rcmaps]

[quote=\"weiaun\"]

Perhaps I\'m being to positive in wondering if this limitation can be overcomed? Is it a transparency issue - that if the polygons in Layer 1 use level 24 and the roads in layer 2 use layer 24 then the roads might be covered? How about this \'polygon draw priority\' in the custom type definition file - could it be tweaked? How did \"rcmaps\" deal with this issue in http://www.asiagps.org/community/showpost.php?p=42&postcount=2?
[/quote]

Sorry haven\\\'t replied earlier - I have problems browsing this site.

I have never had auto routing problems with street maps on one map and polygons on another set of maps. Have done this on Laos_Vietnam maps for some time. However, admittedly, I have only used a limited set of polygon types on that map. All my map elements are drawn on Level24 and extended up to different levels as required for map display purposes depending on the importance of the type.

I am not sure why Antyong thinks that there is a problem with this though unless he means that one polygon type covers up another polygon type.

I did encounter this when creating NZ topo maps as I exhausted the full set of polyline and polygon types available. To overcome overlapping polygons hiding streets and trails, I used custom typ and designed a sort of \\\"semi transparent type of polygon\\\".

If you see the example below of topo map on the outskirts of Hamilton, you will see.

Light purple (urban type),
Light green solid (cemetery)
Dark Green specks with \"F\" (Forest)
Bright green specks with \"S\" (Scrub) - near river
Tree POIs are believe it or not actual big trees/clumps of large trees available in govt dataset - amazingly, they are somewhat accurate unless of course if it has been removed by weather or man!

Hope this helps.

[weiaun]

Perhaps I\'m being to positive in wondering if this limitation can be overcomed? Is it a transparency issue - that if the polygons in Layer 1 use level 24 and the roads in layer 2 use layer 24 then the roads might be covered? How about this \'polygon draw priority\' in the custom type definition file - could it be tweaked? How did \"rcmaps\" deal with this issue in http://www.asiagps.org/community/showpost.php?p=42&postcount=2?

Sorry haven\\\'t replied earlier - I have problems browsing this site.

I have never had auto routing problems with street maps on one map and polygons on another set of maps. Have done this on Laos_Vietnam maps for some time. However, admittedly, I have only used a limited set of polygon types on that map. All my map elements are drawn on Level24 and extended up to different levels as required for map display purposes depending on the importance of the type.

I am not sure why Antyong thinks that there is a problem with this though unless he means that one polygon type covers up another polygon type.

I did encounter this when creating NZ topo maps as I exhausted the full set of polyline and polygon types available. To overcome overlapping polygons hiding streets and trails, I used custom typ and designed a sort of \\\"semi transparent type of polygon\\\".

If you see the example below of topo map on the outskirts of Hamilton, you will see.

Light purple (urban type),
Light green solid (cemetery)
Dark Green specks with \"F\" (Forest)
Bright green specks with \"S\" (Scrub) - near river
Tree POIs are believe it or not actual big trees/clumps of large trees available in govt dataset - amazingly, they are somewhat accurate unless of course if it has been removed by weather or man!

Hope this helps.

Thanks for the explanation. Perhaps you could share with the forum just snippets of your .mp files of the above - I imagine that it is a collection of super-imposed mp files? You could crop it to just a small representative area to preserve your rights over the whole map. It would be helpful to know how you layered it and what settings you used in GPSMapEdit.

Thanks in advance,

Wei Aun

[rcmaps]

Sorry Wei Aun, hadn't seen this till now - mostly due to problems encountered last month logging on etc.

Anyway, I'm really not sure how to share snippet of mp file as I have a total of over 300 mp files I think from memory that makes up the whole of NZ Topo maps.

I have not used "DrawPriority" value at all as at the time (2006/07) I did not know about it then.

As mentioned, the roads on the topo maps is non auto routing (as I use the NZOGPS Project roads), I usually don't even bother uploading the road file (separate img files) onto the GPS anymore but relying on the more accurate and up to date NZOGPS auto routing road maps.

Since this post, I have updated the Laos, Vietnam auto routing maps and strangely enough some users reported that where there is an urban polygon drawn on the maps, it covers the street maps if TYP customisation wasn't used. So, Antyong is correct in this respect as the road and POI was on one mp file and polygons and other features were on another.

So, I believe the solution is to use a "semi transparent" TYP customisation.

Here is an example of a Scrub TYP customisation

Code: Select all

;Scrub
[_polygon]
Type=0x4f
string1=4,Scrub
Xpm="32 32 2 1"
"! c None"
"# c #41FF00"
"!!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!"
"!!!#!!!!!!!!!!!!!!!!!!!!###!!!!!"
"!!!##!!!!!!!!!!!!!!!!!!!!!#!!!!!"
"!!!!!##!!!!!!!!!!!!!!!!!!!!##!!"
"!!!!!!###!!!!!!!!!!!!!!!!!!!!!#!"
"!!!!!!!##!!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!##!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!####!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!##!!##!!!!!!"
"!!!!!!!!!!!!!!!!!!!!##!!!#!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!##!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!###!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!!!##!!!!!!"
"!!!!!!!!!!!!!!!!!!!!#!!!!##!!!!!"
"!!##!!!!!!!!!!!!!!!!##!!##!!!!!!"
"!!!##!!!!!!!!!!!!!!!!###!!!!!!!!"
"!!!!!#!!!!!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!##!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!##!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!##!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!##!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!#!!!!!!!!!!!"
"!!!!##!!!!!!!!!!!!!!!!##!!!!!!!!"
"!!!!!##!!!!!!!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!!!!!!!!!!!!!!!#!!!"
"!!!!!!!!##!!!!!!!!!!!!!!!!!!!##!"
"!!!!!!!!!!!##!!!!!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!####!!!!!!!!!!!!!!!"
"!!!!!!!!!!!!!!##!!!!!!!!!!!!!!!!"};
;12345678901234567890123456789012
[end]

[LLCC]

NATURAL RELIEF
1 Contour
2 Form Line
3 Cliff/ Precipice
4 Landslide
5 Broken Ground
6 Rocky Outcrop

How about adding Trigonometrical stations, Bench marks and spot heights?
I find them useful for recalibrating the altimeter's sensor.

LL