A lot of devs use Firefox, though – it has really good tools for JS development.
So Firefox should always have good support for most things. Firefox has conveniences for devs that Chrome (which also has good development tools) doesn’t have, for example, it’ll format and syntax highlight JSON out of the box, whereas Chrome might just give you a huge single long line of dense black text. Firefox also doesn’t try to get too clever with networking (e.g. I have some IPv6 routes that are not on the default route, and Chrome will not use them, returning a DNS error if it can’t find an IPv4 address in DNS), Firefox doesn’t do this kind of thing giving the behaviour of the OS’s network stack.
Does anyone have Openlayers debugging experience?
I would like to massively improve the performance of the airports map. Someone did a quick prototype in Leaflet and it is vastly faster but I am not convinced that Openlayers is so crappy. I reckon there is something really basic going on e.g. a resource conflict which is timing out. I say this because even on my new S10e phone the map can be totally frozen and just sit there and never do anything. On a PC/Mac it is almost usable and apparently likewise on a modern Iphone/Ipad. It is worse in Chrome, but most things are.
I am happy to give the relevant sources to someone to examine and suggest changes but don’t want at this stage to be handing out server login credentials.
However I suspect the problem can be established by looking at the traffic to the client. It could be a really simple mod.
Just do server-side or client-side feature clustering.
IMO from a cartography point of view there is no reason to show too many features when you zoom out.
I am not yet convinced the performance issue is caused simply by drawing too many blobs.
On chrome+android, the perf is dreadful and it almost stops working. It doesn’t look like a rendering speed issue to me.
The map is now really well sorted. The perf hit was caused by different types of blobs each having its own style, so thousands of styles. This was spotted by @mateusz. The styles are now cached. This makes one realise just how crappy today’s browsers are in processing HTML. You can have a 20 core 2GHz CPU with 16GB RAM and it is still slower than what could have been achieved on a 4MHz Z80 40 years ago. OTOH one can run DES on such a platform at quite a few mbps, implemented entirely in software, whereas the Z80 would have struggled to do 38.4k.
I have a new challenge: identifying a URL. This is a real bastard. Is there some JS code which really works properly even with the latest “dubious practices” in URL character sets? One can do it with a regular expression but that breaks in simple cases like this.that (which is a legitimate URL unless you build in a table of all known domain tails) IF you want to support the case where the poster didn’t put in http/https/www. And you cannot use https because that will break http-only websites.
It is actually broken in some cases here on EuroGA also if e.g. a URL contains brackets or two or more consecutive dashes (minus signs); the workaround is to use a proper live link format like this where the URL is not showing, and that is much neater anyway than dropping in some massive URL.
Peter wrote:
dubious practices
The allowable characters, and syntax, in a URL is well-defined, in RFC 3986. That people/website were not, or rarely, using the full allowed character set, and started doing so more does not constitute “dubious practice”.
Peter wrote:
this.that (which is a legitimate URL)
No, this is not an URL. It might be a hostname. But a hostname is not a URL. The URL scheme is mandatory. “this.that” might be a hostname, but it might be accessible over http (http://this.that/), FTP (ftp://this.that/), NNTP (nntp://this.that/), SFTP (sftp://this.that/) and many other protocols, each having its own URL scheme. In a local network context, even “this” can be a valid hostname, and http://this/ a completely valid URL.
Peter wrote:
IF you want to support the case where the poster didn’t put in http/https/www
Then, what you want is not URL detection, but “what the writer intended as an URL, but dropped a mandatory part from”. Human intent is harder to guess that a formally defined syntax, obviously.
Another source of problems, is that (I guess) you want to detect URLs embedded in plain text, in a way that breaks what you perceive as corner cases of URLs, but covers common embeddings of URLs in text. Consider that “http://example.com/word.” (without the double quotes around, with last character being a dot) is a perfectly valid URL, but EuroGA will absolutely refuse to recognise it as such, including the final fullstop (dot). That is to cover the more common case of an URL ending a sentence, like the first sentence of this post. I got around this by percent-encoding the last dot in this post.
Interesting debate.
http://example.com/word. does work on the Airports site. Also in round brackets (http://example.com/word)
And both work here too, no?
The training dot is stripped. It is surely crazy to have a real URL ending with a dot (the URL including the dot) because you can’t tell if that’s intended if it’s at the end of a sentence. It may be legit but anybody setting up a server with that should be shot.
And most people would regard euroga.org (or for that matter euroga.here) as a valid URL. Euroga.org leaves that as-is but airports.euroga.org makes it into a live link. See here. The case with the trailing bracket gets a space inserted by the server 
Peter wrote:
Also in round brackets
Like the dot at the end, that’s another example of “guess” that is not formally always correct. Parentheses can be in URLs; e.g. Microsoft is fond of them, as in https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa752574(v=vs.85). Which works. Amazing. The EuroGA parser is smarter than I expected. It looks like it matches opening and closing parentheses within the URL (which is not a requirement for a valid URL… but a reasonable heuristic).
Comma also. Here’s a 100% legit and logical use of a comma (followed by a space) in a URL: “http://java.sun.com/j2se/1.5.0/docs/api/java/util/Arrays.html#binarySearch(int[], int)”; the EuroGA parser cuts the URL at the comma followed by a space, but wouldn’t at a comma not followed by a space. Again, percent-encoding can come to the rescue “obviously”: “http://java.sun.com/j2se/1.5.0/docs/api/java/util/Arrays.html#binarySearch(int[],%20int)”.
I also discover now that, for some weird reason, the link text cannot end with a parenthesised part.
“foo(bar)” will be cut to “foo”(see: foo), but “foo(bar)b” works (foo(bar)b). I don’t see a workaround for this one.
While the previously discussed matters where matters of heuristics, and linked to the very design of the modified-textile markup language this looks like a genuine implementation bug :)
What I mean by “very design of the textile language” is that it does not have begin/end separators for URLs; the syntax could e.g. have been “foo”:<http://example.com> to mark the begin and end of the URL, avoiding all these problems / ambiguities. And now we see the EuroGA parser matches () but not <>. Does it match []? Let’s try: foo] is understood as a relative URL but without the closing bracket, and with parentheses foo the closing parenthesis is part of the relative URL.
I must admit the support for relative URLs doesn’t look that much useful to me.
I think all those URLs work if you turn them into clickable links (not sure of the exactly correct terminology). It is much neater too.
What you do need however, on EuroGA, is the http or https bit. Just www doesn’t produce a working link. On the Airports site anything works but that’s because we don’t have clickable links; the actual URL entered is visible, and clickable.
These are really rare issues (“edge cases” as Steve Jobs used to call this stuff) and it would cost thousands to get a programmer onto it, go up the learning curve, and rewrite the code. It would be a bad use of the donations which so many have very kindly contributed. Similarly for the Airports site; it cost too much to do so I paid for the development of that myself.
One interesting thing which complicates auto detection of candidate URLs is that youtube URLs are case sensitive and use both lower and uppercase – example:
It’s fairly obvious that doing this correctly requires quite a lot of code – even more if you want to do what we do on EuroGA and replace Vimeo and Youtube URLs with the players – and some of that code conflicts with stuff you need to do for XSS protection.
Anyway I am no wiser because I was looking for some code to do this One could even do it server-side i.e. in (on the Airports site) PHP. But we seem to have a good enough solution now.
Peter wrote:
I think all those URLs work if you turn them into clickable links
No, they don’t, not as such. But I’m fairly convinced you can dismiss them as edge cases for EuroGA. Not for a programming forum.
Peter wrote:
One interesting thing which complicates auto detection of candidate URLs is that youtube URLs are case sensitive and use both lower and uppercase
Peter, most URLs are case sensitive. Try https://www.euroga.org/forums/Instructors, it won’t work. It has to be https://www.euroga.org/forums/instructors. Or https://www.bbc.com/news/world-US-Canada-53032664 instead of https://www.bbc.com/news/world-us-canada-53032664.
I don’t even want to imagine what heuristic for URL detection would give complications because of case sensitivity, or using both lower and upper case. <shudder>
