Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #90485 > unrolled thread
| Started by | rbowman <bowman@montana.com> |
|---|---|
| First post | 2026-08-25 04:41 +0000 |
| Last post | 2026-08-29 00:19 -0400 |
| Articles | 20 on this page of 120 — 18 participants |
Back to article view | Back to comp.os.linux.misc
Ancient History rbowman <bowman@montana.com> - 2026-08-25 04:41 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-25 03:15 -0400
Re: Ancient History John Ames <commodorejohn@gmail.com> - 2026-08-25 08:19 -0700
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 19:57 +0100
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-26 04:25 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 09:33 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-26 18:20 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 21:27 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-27 01:13 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 03:24 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-27 20:03 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 23:47 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 06:54 +0000
Re: Ancient History John Ames <commodorejohn@gmail.com> - 2026-08-28 09:28 -0700
Re: Ancient History Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-28 18:53 +0100
Re: Ancient History Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-30 13:11 +0100
[OT] Re: Ancient History Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-30 13:20 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 20:58 +0000
Re: Ancient History John Ames <commodorejohn@gmail.com> - 2026-08-28 14:49 -0700
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-29 05:41 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-29 02:00 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:00 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-29 21:55 +0000
Re: Ancient History not@telling.you.invalid (Computer Nerd Kev) - 2026-08-30 09:02 +1000
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-30 06:28 +0000
Re: Ancient History Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-30 09:15 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-30 19:28 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-31 03:41 -0400
Re: Ancient History Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-31 15:50 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-31 00:56 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-31 19:09 +0000
Re: Ancient History "Carlos E. R." <robin_listas@es.invalid> - 2026-08-30 13:56 +0200
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-30 19:10 +0000
Re: Ancient History "Carlos E. R." <robin_listas@es.invalid> - 2026-08-30 21:32 +0200
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-31 02:57 +0000
Re: Ancient History Philippe <p.naudin+nntp@free.fr> - 2026-08-31 09:07 +0200
Re: Ancient History Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 08:37 +0000
Re: Ancient History "Carlos E.R." <robin_listas@es.invalid> - 2026-08-31 12:52 +0200
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-29 21:46 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 09:57 +0100
Re: Ancient History not@telling.you.invalid (Computer Nerd Kev) - 2026-08-30 09:17 +1000
Re: Ancient History John Ames <commodorejohn@gmail.com> - 2026-08-31 11:12 -0700
Javascript whitelisting (was Re: Ancient History) John Ames <commodorejohn@gmail.com> - 2026-08-31 11:01 -0700
Re: Javascript whitelisting (was Re: Ancient History) Andy Burns <usenet@andyburns.uk> - 2026-08-31 19:28 +0100
Re: Javascript whitelisting (was Re: Ancient History) John Ames <commodorejohn@gmail.com> - 2026-08-31 11:35 -0700
Re: Javascript whitelisting (was Re: Ancient History) rbowman <bowman@montana.com> - 2026-08-31 20:19 +0000
Re: Javascript whitelisting (was Re: Ancient History) John Ames <commodorejohn@gmail.com> - 2026-08-31 13:52 -0700
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:11 +0100
Re: Ancient History "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:41 +0200
Re: Ancient History Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-25 11:53 +0100
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:54 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-25 19:25 +0000
Re: Ancient History "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 14:23 +0200
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-26 03:28 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 09:12 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-26 18:26 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 03:56 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-27 12:00 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-27 20:25 +0000
Re: Ancient History Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-27 21:48 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-28 00:26 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 06:59 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:05 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 21:02 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:03 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-29 22:33 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-30 17:58 +0100
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:03 +0100
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-28 00:06 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:08 +0100
Re: Ancient History "Carlos E. R." <robin_listas@es.invalid> - 2026-08-29 13:45 +0200
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 22:42 +0100
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-29 21:59 -0400
Re: Ancient History "Carlos E. R." <robin_listas@es.invalid> - 2026-08-30 14:15 +0200
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-31 01:32 -0400
Re: Ancient History "Carlos E.R." <robin_listas@es.invalid> - 2026-08-31 12:54 +0200
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-31 12:19 +0100
Re: Ancient History "Carlos E.R." <robin_listas@es.invalid> - 2026-08-31 13:50 +0200
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-31 13:04 +0100
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-31 12:18 +0100
Re: Ancient History Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-31 15:50 +0000
Metformin (Re: Ancient History) Lars Poulsen <lars@beagle-ears.com> - 2026-08-30 09:37 -0700
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:03 +0100
Re: Ancient History Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-08-28 12:07 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 21:00 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-29 02:22 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:01 +0100
Re: Ancient History Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-08-29 10:01 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-29 22:02 +0000
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-26 18:23 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 21:29 +0100
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:31 +0100
Re: Ancient History Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-08-25 07:53 -0400
Re: Ancient History Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-25 18:26 +0000
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-25 19:37 +0000
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-25 19:16 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 20:21 +0100
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-26 04:40 +0000
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:30 +0100
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-26 02:49 -0400
Re: Ancient History "Mr. Chang Man-wai" <toylet.toylet@gmail.com> - 2026-08-25 20:07 +0800
Re: Ancient History Paul <nospam@needed.invalid> - 2026-08-25 11:20 -0400
Re: Ancient History Robert Riches <spamtrap42@jacob21819.net> - 2026-08-25 17:44 +0000
Re: Ancient History Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-25 21:55 +0000
Re: Ancient History not@telling.you.invalid (Computer Nerd Kev) - 2026-08-27 08:59 +1000
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-27 01:20 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 03:38 -0400
Re: Ancient History vallor <vallor@vallor.earth> - 2026-08-27 08:08 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 22:13 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 04:24 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-27 03:21 -0400
Re: Ancient History not@telling.you.invalid (Computer Nerd Kev) - 2026-08-28 08:58 +1000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-28 00:36 -0400
Re: Ancient History rbowman <bowman@montana.com> - 2026-08-28 04:42 +0000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-28 02:37 -0400
Re: Ancient History not@telling.you.invalid (Computer Nerd Kev) - 2026-08-29 07:40 +1000
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-29 02:03 -0400
Re: Ancient History The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:06 +0100
Re: Ancient History Andy Burns <usenet@andyburns.uk> - 2026-08-28 08:59 +0100
Re: Ancient History c186282 <c186282@nnada.net> - 2026-08-29 00:19 -0400
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-29 02:00 -0400 |
| Message-ID | <xcGcnV-bb91W6A_3nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #90793 |
On 8/29/26 01:41, rbowman wrote: > On Fri, 28 Aug 2026 14:49:26 -0700, John Ames wrote: > >> This is also not really true; it may or may not be harder to do without >> dynamically rendering the whole thing client-side, but it's certainly >> possible. Google Maps functioned that way for years. > https://developers.google.com/maps/documentation/javascript/overview PREF the PHP approach - makes the SERVER do most of the work :-) > Google Maps used a JavaScript API for as long as I can remember. I had the > pleasure of talking to Google to try to determine the pricing for > commercial use. The answer was up the lines of 'how much money you got?'. > We used Esri's JavaScript API. No great solutions any more. Kinda SUCKS.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-29 10:00 +0100 |
| Message-ID | <116u737$3345j$2@dont-email.me> |
| In reply to | #90795 |
On 29/08/2026 07:00, c186282 wrote:
> On 8/29/26 01:41, rbowman wrote:
>> On Fri, 28 Aug 2026 14:49:26 -0700, John Ames wrote:
>>
>>> This is also not really true; it may or may not be harder to do without
>>> dynamically rendering the whole thing client-side, but it's certainly
>>> possible. Google Maps functioned that way for years.
>> https://developers.google.com/maps/documentation/javascript/overview
>
> PREF the PHP approach - makes the SERVER
> do most of the work :-)
>
A PHP page still has to be served.
If you make dynamic changes it has to be reloaded, wasting time and
bandwidth
JavaScript enables far less network activity to be used for far more
functionality.
Like any tool its a time saver or a danger to humanity, depending on how
its used
--
"The most difficult subjects can be explained to the most slow witted
man if he has not formed any idea of them already; but the simplest
thing cannot be made clear to the most intelligent man if he is firmly
persuaded that he knows already, without a shadow of doubt, what is laid
before him."
- Leo Tolstoy
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-29 21:55 +0000 |
| Message-ID | <nfh2r3FprcuU60@mid.individual.net> |
| In reply to | #90803 |
On Sat, 29 Aug 2026 10:00:23 +0100, The Natural Philosopher wrote: > A PHP page still has to be served. > If you make dynamic changes it has to be reloaded, wasting time and > bandwidth I suppose it could be done if you're a masochist. Take a very basic operation, zooming in. You'd have to inform the PHP back end somehow. It would then have to request a new set of tiles from the tile server based on the Z level, render a complete new page, and serve it back to the browser. That would be smoother than a baby's ass. > JavaScript enables far less network activity to be used for far more > functionality. > Like any tool its a time saver or a danger to humanity, depending on how > its used With JavaScript the browser is making the calls for new tiles and rendering them. You can watch the calls in the developer's console of Chrome, Brave, or whatever. The browser also caches tiles to minimize web traffic if you're panning for example.
[toc] | [prev] | [next] | [standalone]
| From | not@telling.you.invalid (Computer Nerd Kev) |
|---|---|
| Date | 2026-08-30 09:02 +1000 |
| Message-ID | <6a9364fc@news.ausics.net> |
| In reply to | #90855 |
rbowman <bowman@montana.com> wrote: > On Sat, 29 Aug 2026 10:00:23 +0100, The Natural Philosopher wrote: >> A PHP page still has to be served. >> If you make dynamic changes it has to be reloaded, wasting time and >> bandwidth > > I suppose it could be done if you're a masochist. Take a very basic > operation, zooming in. You'd have to inform the PHP back end somehow. It > would then have to request a new set of tiles from the tile server based > on the Z level, render a complete new page, and serve it back to the > browser. That would be smoother than a baby's ass. I'd use it. >> JavaScript enables far less network activity to be used for far more >> functionality. >> Like any tool its a time saver or a danger to humanity, depending on how >> its used > > With JavaScript the browser is making the calls for new tiles and > rendering them. You can watch the calls in the developer's console of > Chrome, Brave, or whatever. The browser also caches tiles to minimize web > traffic if you're panning for example. Browsers cache things sent to them without Javascript too, and in fact that works a lot better than JS-based map sites where you usually find they do stop scrolling back to parts you've already viewed when the internet connection drops out. I get to see a lot of Javascript going wrong on my dodgy internet connection, and it's a joke compared to how some browsers handle caching of plain HTML content. Anyway for maps I'd ideally have a separate program running locally and loading map data from an updatable local file, but last time I looked into that (a long time ago, I'll admit) the free options weren't very capable. I mainly still use paper maps. -- __ __ #_ < |\| |< _#
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-30 06:28 +0000 |
| Message-ID | <nfi0riFprcuU69@mid.individual.net> |
| In reply to | #90869 |
On 30 Aug 2026 09:02:20 +1000, Computer Nerd Kev wrote: > Anyway for maps I'd ideally have a separate program running locally and > loading map data from an updatable local file, but last time I looked > into that (a long time ago, I'll admit) the free options weren't very > capable. I mainly still use paper maps. Paper maps are fine as far as they go. We used the map to show the location of ongoing incidents and the location of fire, ems, and law enforcement resources. You could get more information by clicking on the icon. Multiple layers allowed turning on various classes of landmarks, showing jurisdictional boundaries, and so forth. Entering a street address would zoom to the location. You're not going to do that with paper or PHP serving up static pages. Another use for crime analysis. What crimes occurred in a given time period? What were the patterns for specific crimes? How about a heat map or other graphic representation?
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-08-30 09:15 +0100 |
| Message-ID | <1170oqd$3ssek$1@dont-email.me> |
| In reply to | #90883 |
On 2026-08-30, rbowman wrote: > On 30 Aug 2026 09:02:20 +1000, Computer Nerd Kev wrote: > >> Anyway for maps I'd ideally have a separate program running locally and >> loading map data from an updatable local file, but last time I looked >> into that (a long time ago, I'll admit) the free options weren't very >> capable. I mainly still use paper maps. > > Paper maps are fine as far as they go. We used the map to show the > location of ongoing incidents and the location of fire, ems, and law > enforcement resources. You could get more information by clicking on the > icon. Multiple layers allowed turning on various classes of landmarks, > showing jurisdictional boundaries, and so forth. Entering a street address > would zoom to the location. You're not going to do that with paper or PHP > serving up static pages. There's a trade-off but it's definitely not impossible, it can be done. Another concern here could be a light enough version so that it would work well even with degraded network conditions or on less performant hardware (the kind of stuff you need to take into accout for bigger emergencies?). > Another use for crime analysis. What crimes occurred in a given time > period? What were the patterns for specific crimes? How about a heat map > or other graphic representation? Idem, some of this could be offered statically. But you're possibly nearing a good example of something that needs an interactive interface, because you easily end up with a large amount of variables you can't cover at the server side, or if you can it significantly increases processing and reduces the amount that can be cached? Not because of a map/visualization, but because of trying several representations (which I'm assuming will also involve mixing parameters and representations?). I'm reminded of HSL's old journey planner. I may be misremembering, but I think it was static or at least offered a static or light enough interface, yet it worked quite well as a journey planner. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-30 19:28 +0000 |
| Message-ID | <nfjeikFprcuU77@mid.individual.net> |
| In reply to | #90887 |
On Sun, 30 Aug 2026 09:15:09 +0100, Nuno Silva wrote: > Idem, some of this could be offered statically. But you're possibly > nearing a good example of something that needs an interactive interface, > because you easily end up with a large amount of variables you can't > cover at the server side, or if you can it significantly increases > processing and reduces the amount that can be cached? Not because of a > map/visualization, but because of trying several representations (which > I'm assuming will also involve mixing parameters and representations?). Eye candy, aka visualization, is a selling point. Oooh pretty! How useful it really is is another question. I had access to the St. Louis Country data that I used for demos. 'Look! Ferguson is red on the heat map. That must be a high crime area.' No shit. 'Business intelligence' is the buzzword. Dry old text reports are out. To give them their due, Microsoft's Power BI is the only one that you might be able to hand to a middle manager and they could achieve some level of competency. https://en.wikipedia.org/wiki/Microsoft_Power_BI I used Charts.js to enhance our text based reports with some success. https://en.wikipedia.org/wiki/Chart.js That's definitely not something a manger is going to pull off on his own, which is the holy grail of BI. Maybe Claude could help.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-31 03:41 -0400 |
| Message-ID | <Q_SdnfQtHplisgj3nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #90922 |
On 8/30/26 15:28, rbowman wrote: > On Sun, 30 Aug 2026 09:15:09 +0100, Nuno Silva wrote: > >> Idem, some of this could be offered statically. But you're possibly >> nearing a good example of something that needs an interactive interface, >> because you easily end up with a large amount of variables you can't >> cover at the server side, or if you can it significantly increases >> processing and reduces the amount that can be cached? Not because of a >> map/visualization, but because of trying several representations (which >> I'm assuming will also involve mixing parameters and representations?). > > Eye candy, aka visualization, is a selling point. Oooh pretty! Oh YES ! And TURN IT OFF as much as possible Gigantic, useless, CPU/GPU drain ! LXDE and XFCE ... you can be pretty successful in killing the Eye Candy. But the Others ,,,,,,,, Gee, DO hate it ! My fave was Win-2k ... ultra-basic. Then moved totally to Linux and have TRIED to preserve "ultra-basic".
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-08-31 15:50 +0000 |
| Message-ID | <pphlS.21798$I1t6.4860@fx43.iad> |
| In reply to | #90946 |
On 2026-08-31, c186282 <c186282@nnada.net> wrote: > On 8/30/26 15:28, rbowman wrote: > >> On Sun, 30 Aug 2026 09:15:09 +0100, Nuno Silva wrote: >> >>> Idem, some of this could be offered statically. But you're possibly >>> nearing a good example of something that needs an interactive interface, >>> because you easily end up with a large amount of variables you can't >>> cover at the server side, or if you can it significantly increases >>> processing and reduces the amount that can be cached? Not because of a >>> map/visualization, but because of trying several representations (which >>> I'm assuming will also involve mixing parameters and representations?). >> >> Eye candy, aka visualization, is a selling point. Oooh pretty! > > Oh YES ! > > And TURN IT OFF as much as possible > > Gigantic, useless, CPU/GPU drain ! > > LXDE and XFCE ... you can be pretty > successful in killing the Eye Candy. > But the Others ,,,,,,,, > > Gee, DO hate it ! > > My fave was Win-2k ... ultra-basic. > > Then moved totally to Linux and have TRIED > to preserve "ultra-basic". I've said it before and I'll say it again: computer systems should be ugly and boring. Ugly as in lacking eye candy that just gets in the way, and boring as in it Just Works without surprises. (See "principle of least astonishment".) Of course, that assumes that a computer is a tool, not a toy. Windows is video games for managers. -- /~\ Charlie Gibbs | In this world there are \ / <cgibbs@kltpzyxm.invalid> | two kinds of people: X I'm really at ac.dekanfrus | 1. Those who can extrapolate / \ if you read it the right way. | from incomplete data.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-31 00:56 -0400 |
| Message-ID | <Q_SdnfgtHpnUlAj3nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #90883 |
On 8/30/26 02:28, rbowman wrote: > On 30 Aug 2026 09:02:20 +1000, Computer Nerd Kev wrote: > >> Anyway for maps I'd ideally have a separate program running locally and >> loading map data from an updatable local file, but last time I looked >> into that (a long time ago, I'll admit) the free options weren't very >> capable. I mainly still use paper maps. > > Paper maps are fine as far as they go. We used the map to show the > location of ongoing incidents and the location of fire, ems, and law > enforcement resources. You could get more information by clicking on the > icon. Multiple layers allowed turning on various classes of landmarks, > showing jurisdictional boundaries, and so forth. Entering a street address > would zoom to the location. You're not going to do that with paper or PHP > serving up static pages. > > Another use for crime analysis. What crimes occurred in a given time > period? What were the patterns for specific crimes? How about a heat map > or other graphic representation? Um, nothing wrong with "paper maps" at all, so long as the stuff presented is kinda STABLE. Like 'em, always keep some. SOME stuff is NOT "stable" - and thus other kinds of 'maps' are needed.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-31 19:09 +0000 |
| Message-ID | <nfm1rrFtomiU6@mid.individual.net> |
| In reply to | #90935 |
On Mon, 31 Aug 2026 00:56:12 -0400, c186282 wrote: > Um, nothing wrong with "paper maps" at all, so long as the stuff > presented is kinda STABLE. Like 'em, always keep some. When I was driving OTR I had a collection of city maps to supplement the Truckers' Atlas, a well packed shoe box full. I also had the Thomas Guide to LA and Orange Country which is a whole spiral bound book. I also have a collection of Forest Service maps. I liked then since they showed the roads and trails but no topographic information. You could find your way around but didn't know what you were getting into. Unless the trail had a section that looked like a fine zigzag. Expect a ballbuster.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-30 13:56 +0200 |
| Message-ID | <nfik2mF3glU4@mid.individual.net> |
| In reply to | #90855 |
On 2026-08-29 23:55, rbowman wrote:
> On Sat, 29 Aug 2026 10:00:23 +0100, The Natural Philosopher wrote:
>
>> A PHP page still has to be served.
>> If you make dynamic changes it has to be reloaded, wasting time and
>> bandwidth
>
> I suppose it could be done if you're a masochist. Take a very basic
> operation, zooming in. You'd have to inform the PHP back end somehow. It
> would then have to request a new set of tiles from the tile server based
> on the Z level, render a complete new page, and serve it back to the
> browser. That would be smoother than a baby's ass.
>
>> JavaScript enables far less network activity to be used for far more
>> functionality.
>> Like any tool its a time saver or a danger to humanity, depending on how
>> its used
>
> With JavaScript the browser is making the calls for new tiles and
> rendering them. You can watch the calls in the developer's console of
> Chrome, Brave, or whatever. The browser also caches tiles to minimize web
> traffic if you're panning for example.
Years ago, I figured the naming of the tiles, so that I scripted
downloading them for my area, and then stitching them together in a huge
graphic or map. Gimp had trouble loading it, not enough ram.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-30 19:10 +0000 |
| Message-ID | <nfjdgrFprcuU76@mid.individual.net> |
| In reply to | #90896 |
On Sun, 30 Aug 2026 13:56:05 +0200, Carlos E. R. wrote: > Years ago, I figured the naming of the tiles, so that I scripted > downloading them for my area, and then stitching them together in a huge > graphic or map. Gimp had trouble loading it, not enough ram. It gets intense. I've set up a tile server for a specific county and it took quite a bit of storage. Raster tiles are typically 256x256 pixel pngs. The problem is each zoom level requires a set. When you're building the server you select how many zoom levels you want to support. Vector tiles are lighter but all rendering is done client side, usually a browser. The advantage is you can do the styling on the fly rather than using pre-rendered tiles. Also vector tiles contain the geometries; raster tiles are only pretty pictures.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-30 21:32 +0200 |
| Message-ID | <nfjeqoF3giU11@mid.individual.net> |
| In reply to | #90920 |
On 2026-08-30 21:10, rbowman wrote:
> On Sun, 30 Aug 2026 13:56:05 +0200, Carlos E. R. wrote:
>
>> Years ago, I figured the naming of the tiles, so that I scripted
>> downloading them for my area, and then stitching them together in a huge
>> graphic or map. Gimp had trouble loading it, not enough ram.
(I should have said those were google maps tiles)
> It gets intense. I've set up a tile server for a specific county and it
> took quite a bit of storage. Raster tiles are typically 256x256 pixel
> pngs. The problem is each zoom level requires a set. When you're building
> the server you select how many zoom levels you want to support.
>
> Vector tiles are lighter but all rendering is done client side, usually a
> browser. The advantage is you can do the styling on the fly rather than
> using pre-rendered tiles. Also vector tiles contain the geometries; raster
> tiles are only pretty pictures.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-31 02:57 +0000 |
| Message-ID | <nfk8tiFprcuU84@mid.individual.net> |
| In reply to | #90924 |
On Sun, 30 Aug 2026 21:32:40 +0200, Carlos E. R. wrote: > On 2026-08-30 21:10, rbowman wrote: >> On Sun, 30 Aug 2026 13:56:05 +0200, Carlos E. R. wrote: >> >>> Years ago, I figured the naming of the tiles, so that I scripted >>> downloading them for my area, and then stitching them together in a >>> huge graphic or map. Gimp had trouble loading it, not enough ram. > > (I should have said those were google maps tiles) With a slow connection you had the pleasure of watching the google map fill in tile by tile. I haven't seen that in a long time. In the early 2000s non-commercial web sites like geocaching.com could use the Google API for free. That didn't last long until Google decided they had to monetize the substantial money they were pouring into the mapping project. As I mentioned getting a price was like dealing with a used camel salesman. I wasn't the right person to contact them since I abhor haggling. While we chose not to use the Google API I did develop code that would create a URL with the coordinates of interest and direct the browser to go there. Maybe not 100% kosher but in business terms our client base was small potatoes.
[toc] | [prev] | [next] | [standalone]
| From | Philippe <p.naudin+nntp@free.fr> |
|---|---|
| Date | 2026-08-31 09:07 +0200 |
| Message-ID | <20260831090714.42261160@peinard.chezmoi> |
| In reply to | #90896 |
On 2026-08-30 23:55, Carlos E. R. wrote: > Years ago, I figured the naming of the tiles, so that I scripted > downloading them for my area, and then stitching them together in a huge > graphic or map. Gimp had trouble loading it, not enough ram. Mobac (Mobile Atlas Creator, https://mobac.sourceforge.io/) do this job very well since 2008. There are some source files (including for Spain's IGN) at http://randochartreuse.free.fr/mobac2.x/mapsources/index.php (in french, but you dont't have to read anything, simply download the file you want). -- Philippe
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-31 08:37 +0000 |
| Message-ID | <1173efn$oovf$1@dont-email.me> |
| In reply to | #90944 |
On Mon, 31 Aug 2026 09:07:14 +0200, Philippe wrote: > There are some source files (including for Spain's IGN) at > http://randochartreuse.free.fr/mobac2.x/mapsources/index.php (in > french, but you dont't have to read anything, simply download the > file you want). Don’t forget OpenStreetMap <https://www.openstreetmap.org/>.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-31 12:52 +0200 |
| Message-ID | <h03gmmx832.ln2@Telcontar.valinor> |
| In reply to | #90944 |
On 2026-08-31 09:07, Philippe wrote: > On 2026-08-30 23:55, Carlos E. R. wrote: > >> Years ago, I figured the naming of the tiles, so that I scripted >> downloading them for my area, and then stitching them together in a huge >> graphic or map. Gimp had trouble loading it, not enough ram. > > Mobac (Mobile Atlas Creator, https://mobac.sourceforge.io/) do this job very > well since 2008. > > There are some source files (including for Spain's IGN) at > http://randochartreuse.free.fr/mobac2.x/mapsources/index.php (in french, but > you dont't have to read anything, simply download the file you want). > Noted, thanks :-) -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-29 21:46 +0000 |
| Message-ID | <nfh2a5FprcuU59@mid.individual.net> |
| In reply to | #90795 |
On Sat, 29 Aug 2026 02:00:31 -0400, c186282 wrote:
> PREF the PHP approach - makes the SERVER do most of the work
I don't know PHP but what I find are sites like
https://www.sourcecodester.com/php/17354/interactive-map-markers-using-
php-and-mysql-source-code.html
https://nomadphp.com/video/232/building-interactive-maps-with-php-and-
javascript
https://www.phpclasses.org/blog/post/284-Create-a-Google-Maps-alternative-
with-PHP-and-MySQL-using-the-Leaflet-library.html
https://developers.google.com/gdata/articles/php_maps_spreadsheets
Once you say 'leaflet' you're into JavaScript.
https://leafletjs.com/
Sure, you can use PHP to serve up a HTML page, extract data from a SQL
database, and so forth. I prefer Node.js for the back end since I'd rather
work with JS on both ends.
If you like Python you can use Folium to create a web page and serve it
however you want. The HTML document will start with
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<script src="https://cdn.jsdelivr.net/npm/leaflet@1.9.3/dist/
leaflet.js"></script>
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-29 09:57 +0100 |
| Message-ID | <116u6ud$3345j$1@dont-email.me> |
| In reply to | #90793 |
On 29/08/2026 06:41, rbowman wrote: > JavaScript is used by 98.7% of all websites as of 2023" > > I see that 98.x % on so many sites I'm a little suspicious. Some sites may > use the <noscript/> tag to provide alternate functionality but speaking as > someone who has done so web development, ain't gonna happen. HTML was never designed for an interactive experience. E.g. Reloading a whole page explicitly after making a single change to an option is massively slow and clunky. Using AJAX is seamless and invisible. Example. I have a web page where configurations are updated. You select the values and... ...that's it. There is no update or submit button at all. If you selected it, it's updated. And that is the point. Properly used JavaScript or equivalent is a huge improvement. The problem is its misuse to obfuscate or to insert content you did not request or want -- "The great thing about Glasgow is that if there's a nuclear attack it'll look exactly the same afterwards." Billy Connolly
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web