online map: OpenNauticalChart.org
You are not logged in.
Pages: 1
openlayers 2 is dead, switch to ol3:
Gabi's map: http://openseamap.he1ix.org/openlayers3/map.html
my map: http://maps.grade.de/ol3.html
base raster-layers:
- openriverboatmap: http://fluv.io/#7/49.813/2.889
- INT-1 style
- OSM
...
raster overlays:
- seamark-tiles
- wms e.g.
-- Data-ICT-Dienst, Rijkswaterstaat https://www.watergegevens.rws.nl/
-- Waterwegen en Zeekanaal, vlaanderen.be http://inspire.flaris.be/geoserver/web/
-- NAUTHIS SkinOfTheEarth (BSH) http://gdiwiki.bsh.de/wiki/index.php/NA … _The_Earth
...
vector-layers:
- AIShub
...
functions:
- window.location.hash (rewrite URL)
- clickable objects > overpass.api query
- geolocation with map orientation http://www.camptocamp.com/de/actualite/ … ientation/
Offline
The already existing Map has been developed over a year now and contains a lot of features, which will not be visible at the first view. It is completely rewritten and contains no code from OpenSeaMap. Only the CSS file is not changed until now. That is why it looks similar.
We already have the following features in place:
- Internationalization (English and German are working. Spanish, French, Portuguese, Dutch and Italian are prepared. Language will be selected by the browser settings at the moment)
- clickable objects (I started this feature already. It is only working for harbours at the moment, but can be easily enhanced for all objects. It uses overpass.api.
- Trip planner (completely rewritten)
- Weather pages and harbour meteogramm
- Modular architecture
- Map download page (available maps are read via xml file)
- Some minor features like map key, nominatim search
OpenLayers affects below 30% of the complete code base. New layers can be easily added and the design is quickly changeable via CSS. I see no need to begin more or less once again from scratch. It would be easier to port the existing code to OL3 than beginning once again.
Last edited by Olaf_H (2015-12-14 18:32:01)
Offline
I have made a small utility that may of interest for the online map. It provides the data needed for display of a compass rose with magnetic variation & direction of buoyage pointers. This is what the output looks like:
imac:jseas mherring$ java -jar jseas.jar s23.osm
Enter lat,lon:
53.73,-.33
Upper Humber, North Sea
Buoyage: 260
Magnetic Var: -1.090067
It takes its data from a world map of oceans (the file s23.osm) and also calls a modified version of the NASA WMM program.
Offline
Sounds interesting, but I think first of all we should decide how to proceed with the online map and do the change to OL3. It does not make much sense to implement more features, that need to be ported or rewritten
Last edited by Olaf_H (2015-12-14 18:16:09)
Offline
OK, I will not do any more work in this area until the final scheme is decided.
Offline
- clickable objects (I started this feature already. It is only working for harbours at the moment, but can be easily enhanced for all objects. It uses overpass.api.
Olaf,
Do I take it that you do not need the "harbours.xml" data? If not, I will no longer generate it. I originally did this after a request from somebody as OSeaM, but it was never used.
Offline
I think, that we will not need it. At the moment I select the required nodes via a small bounding box around the mouse position of the click event. That is why it is not possible to change the cursor to a pointer style (I have no object on the map before the click). The benefit is that we have small server load, if no one clicks something.
If we want the cursor to change to the pointer symbol during mouse position is over the symbol, we will need the xml files to set poi's with a transparent icon over the symbols.
Last edited by Olaf_H (2015-12-15 12:34:53)
Offline
As a quick test I ported the weather pages to OL3. It took me about 3 hours including a code clean up and reintroducing the zoom control. This never worked properly with OL2 and a limited number of zoom levels.
I think the port of the existing map should be doable in a feasible amount of time. I will look at the base map after Christmas.
Offline
In principle, I am fine with building on any code base. I had a look at Olaf's repository and think it would be much more work to port this than adding the additional functionality to my code base.
Some advantages of my code base
- integration of weather map into main map
- more modern design
- so far pure JavaScript
- much fewer code for comparable functionality
Disadvantages:
- no internationalization yet (but straightforward to include)
- Chart download not integrated yet (but Olaf's implementation can easily be ported)
Of course my design is also modular (that was the main reason why I did not build on the OpenStreetMap ol2 implementation).
I restarted a repository with my code (previously it was developed in a subfolder of the OSeaMap online map repository). You can find it at https://github.com/roeger/onlineseamap. Please have a look and let me know what you think. Niko made the current state of the map online available at http://openseamap.he1ix.org/map.html
Dirk is your code somewhere available? I would like to see how easily our code could be merged (I assume quite easily).
I have one or two hours time this evening and plan to reintroduce the German water levels and maybe try to integrate the map download.
Regarding map key (legend): I don't think this should be hard coded in the map implementation but rather be requested from the tile server.
Offline
It would be great if we could put builds of the various contenders on one of our servers so that others could look at the end results. Then us non-webbies could view them with our browsers.
Offline
I took a short look at your map. At the moment the weather layers are not working at all (OpenSuse + Firefox). Have you missed a commit? How do you handle the problem of the restricted zoom levels without writing new cookies, which will mess up the view of the real online map?
Back to the main base map. My goal is to create a base map as desktop. All information needed can also be displayed in a div. Hence we do not need any Typo3 or other frame works to display additional information.
I do not have that much time at the moment, but there are some more issues. I will come back to you after Christmas. It would be great, if we can find a way to merge the best of both worlds.
Last edited by Olaf_H (2015-12-19 19:55:23)
Offline
@Olaf_H do you have any JavaScript blocker in your browser? The weather layers are working absolutely fine, for zoom levels 1-7.
Offline
I added a layer with German water levels and a basic implementation of the map download to my implementation.
@Olaf:
- I was so bold to copy the xml file with the download map data from your repository. I hope this is ok.
- What do you mean with "the problem of the restricted zoom levels"?
- Could you elaborate a bit on what you mean with "as desktop"? What additional information do you mean?
Offline
@Dirk: Wide parts of your map should be super-easy to integrate with mine. Would you mind if I just take over the easy parts and see what remains to give us some head ache?
Offline
@Dirk: What does http://tiles1.grade.de/tiles.py do?
Offline
First of all: This is no new project. This is ongoing development for 2 years now and there is a reason why I do not add all layers i can get somewhere in the web on the fast track.
I am writing online maps for more than 7 years now. As already stated above adding layers is easy. Porting to OL3 is also easy. Sadly OL3 was not available when I started this project.
We need to decide what the online map should do. There are a lot of sites only displaying a map everywhere in the web. Do we only want to display another "look at my cool layer collection" solution? I think everyone can do this on his own. We do not need a new project for this. How much more or less usable layers do you want to have? The real goal (rendering our own layers, creating maps for chart plotters and so on) get more and more invisible.
Now to the general questions above:
Restricted zoom levels
The weather is only working from z4 to z7 on other zoom levels you will see nothing. If weather is selected, automatically zoom to a feasible level. Otherwise the user will see nothing and gets confused. Also prevent the possibility to zoom into other levels than the allowed ones. If weather is deselected, zoom back to the last used zoom level and position of the base map.
Weather page in general
On the first selection I will not see any weather layer (z6). Need to zoom in and out to get it loading (Firefox on Linux). Do not display all weather layers on the first load. This is confusing (no usable information)
Map in general
I do not like the layout. The sidebar is not usable to display large content The icons (with no text) are not intuitive. You need to click around to find the needed information.
With "as desktop" I mean, that there is no need to have an additional web site for help, information, news and so on. Everything can be displayed using additional dialogs on top of the map, if selected. I have all this features in place. That is why the code base seems to be large regarding to the displayed layers. I am missing in your map:
- No cookies for position, zoom and selected layers (later on selected language)
- No internationalization
- No overpass.api query to gather additional information
- No coordinate grid
- No help links and about information
- No map key
- No possibility to load additional html content into dialogs
Last edited by Olaf_H (2015-12-20 07:11:22)
Offline
First of all: This is no new project.
I started a discussion on this topic in a separate thread.
We need to decide what the online map should do. There are a lot of sites only displaying a map everywhere in the web. Do we only want to display another "look at my cool layer collection" solution? I think everyone can do this on his own. We do not need a new project for this. How much more or less usable layers do you want to have? The real goal (rendering our own layers, creating maps for chart plotters and so on) get more and more invisible.
I do not want to wildly collect layers, but I thought that this thread was on what is there and how we should integrate it. This does not mean that we need to integrate everything at the end but adding and removing layers is usually pretty easy, so I do not see a problem in collecting what we have first. In contrast to me, Dirk is more interested into rivers than the sea, so it is only natural that we would like to have to different layers included.
Restricted zoom levels
The weather is only working from z4 to z7 on other zoom levels you will see nothing. If weather is selected, automatically zoom to a feasible level. Otherwise the user will see nothing and gets confused. Also prevent the possibility to zoom into other levels than the allowed ones. If weather is deselected, zoom back to the last used zoom level and position of the base map.
This will probably not only affect the weather layer. My idea was to restrict layers to certain zoom levels and make this transparent to the use (e.g. in the layer selection).
Weather page in general
On the first selection I will not see any weather layer (z6). Need to zoom in and out to get it loading (Firefox on Linux). Do not display all weather layers on the first load. This is confusing (no usable information)
See comment above. Default settings for displaying layers can easily be changed. I see my map in a prototypical state and I did not optimize such aspects, yet.
I do not like the layout. The sidebar is not usable to display large content The icons (with no text) are not intuitive. You need to click around to find the needed information.
I don't like the old layout but as you wrote regarding your map, this is mostly css and can be changed. I think layout is something that should be discussed independently (and maybe in a separate thread). The sidebar has been inspired by other modern maps (e.g. openstreetmap). It's existence does not mean that there cannot be larger display areas for some content. And it is only a div...
With "as desktop" I mean, that there is no need to have an additional web site for help, information, news and so on. Everything can be displayed using additional dialogs on top of the map, if selected. I have all this features in place. That is why the code base seems to be large regarding to the displayed layers.
I fully agree with you regarding the role of the map as entry page. I do not agree that this is the solemn reason for the size of your code base.
I am missing in your map:
- No cookies for position, zoom and selected layers (later on selected language)
- No internationalization
- No overpass.api query to gather additional information
- No coordinate grid
- No help links and about information
- No map key
- No possibility to load additional html content into dialogs
- Cookies for zoom and position still need to be implemented (which is easy). I expected cookies for selected layers to work. Can you tell me how I can reproduce the unintended behaviour?
- Internationalization: Agreed, that will definitively be necessary
- Overpass: That's what I wanted to integrate first from Dirk's map
- Coordinate grid: With OL3 this is not as easy as with OL2 because there is no layer that provides it including labels. I have an implementation (cf. http://openseamap.he1ix.org/openlayers3/map.html) that I just need to add.
- Help links and about: I did not want to include these before having internationalization in place
- Map key: I am no convinced that hard-coding them into the map is the right way to go. I would first want to inquire whether it is somehow possible to do this in a spirit as it is for example standard with WMS layers (the layer provider provides the key, so that it is guaranteed that map and key stay in sync).
- No possibility to load additional html content into dialogs: Was not necessary so far but should be straight-forward.
Offline
@Gabi:
- feel free to grab all the code you need
- as said, things I consider useful are (see first post in this thread)
-- rewrite URL
-- overpass.api query
-- geolocation with map orientation
- http://tiles[1-3].grade.de is my tileserver based on http://tilestache.org/
- tiles.py is the api call
- proxy tile providers:
-- openriverboatmap/{z}/{x}/{y}.png
-- NAUTHIS_SkinOfEarth/{z}/{x}/{y}.png
-- ncp_diepte14/{z}/{x}/{y}.png
-- ijg_diep_2013/{z}/{x}/{y}.png
-- seamark/{z}/{x}/{y}.png
- mbtile provider:
-- cemt/{z}/{x}/{y}.png
Offline
It would be great if we could put builds of the various contenders on one of our servers so that others could look at the end results. Then us non-webbies could view them with our browsers.
You can look at Gabi's solution at http://openseamap.he1ix.org/map.html
and Dirks solution at http://maps.grade.de/ol3.html
Last edited by Olaf_H (2015-12-21 22:17:50)
Offline
You can look at Gabi's solution at http://openseamap.he1ix.org/map.html
Nice styling of the control buttons.
and Dirks solution at http://maps.grade.de/ol3.html
Good presentation of background maps - they are not as intrusive as the raw OSM map
Object query gives raw tag values - a non-expert plain language mode would be good.
Neither have a lat/lon grid or an edit button - the most important one for mappers!
Offline
Thanks for the review!
- OSM base maps: I set opacity: 0.5
- rough overpass documentation: http://overpass-api.de/output_formats.html#popup
- raw tag values: I prefer seeing all the data and do not like filtered views (openCPN also shows the -even more cryptic- object attributes)
- edit button: Yes, having a JOSM link would be helpful
- grid display: In my case, map's target audience are inland navigators, no need for this feature here
Offline
Pages: 1