Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.misc > #90485 > unrolled thread

Ancient History

Started byrbowman <bowman@montana.com>
First post2026-08-25 04:41 +0000
Last post2026-08-29 00:19 -0400
Articles 20 on this page of 109 — 18 participants

Back to article view | Back to comp.os.linux.misc


Contents

  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 c186282 <c186282@nnada.net> - 2026-08-31 00:56 -0400
                                        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 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 The Natural Philosopher <tnp@invalid.invalid> - 2026-08-31 12:18 +0100
                            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 →


#90795

Fromc186282 <c186282@nnada.net>
Date2026-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]


#90803

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2026-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]


#90855

Fromrbowman <bowman@montana.com>
Date2026-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]


#90869

Fromnot@telling.you.invalid (Computer Nerd Kev)
Date2026-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]


#90883

Fromrbowman <bowman@montana.com>
Date2026-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]


#90887

FromNuno Silva <nunojsilva@invalid.invalid>
Date2026-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]


#90922

Fromrbowman <bowman@montana.com>
Date2026-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]


#90946

Fromc186282 <c186282@nnada.net>
Date2026-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]


#90935

Fromc186282 <c186282@nnada.net>
Date2026-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]


#90896

From"Carlos E. R." <robin_listas@es.invalid>
Date2026-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]


#90920

Fromrbowman <bowman@montana.com>
Date2026-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]


#90924

From"Carlos E. R." <robin_listas@es.invalid>
Date2026-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]


#90934

Fromrbowman <bowman@montana.com>
Date2026-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]


#90944

FromPhilippe <p.naudin+nntp@free.fr>
Date2026-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]


#90951

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-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]


#90953

From"Carlos E.R." <robin_listas@es.invalid>
Date2026-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]


#90852

Fromrbowman <bowman@montana.com>
Date2026-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]


#90802

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2026-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]


#90872

Fromnot@telling.you.invalid (Computer Nerd Kev)
Date2026-08-30 09:17 +1000
Message-ID<6a936880@news.ausics.net>
In reply to#90802
The Natural Philosopher <tnp@invalid.invalid> wrote:
> 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.

Yes, so I wish people would stop trying to make webpages
interactive when they don't need to be.

> 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.

Yeah, and I hate those because when it fails they usually make it
look like it worked anyway, so you don't know unless you manually
reload the page, which takes an age because it's 3MB of Javascript
and locally-processed data that has to be redownloaded and
inefficiently processed to show what could have been in 20KB of
plain HTML in a simple webpage sent back in the blink of an eye. Or
of course you reload and it resets back to a different view
entirely.

If you're running it on a LAN or localhost, like CUPS (though I
avoid that too), fine, otherwise give me back my submit button!

> 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

No, that's just the start of the problems.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]


#90744

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2026-08-28 12:11 +0100
Message-ID<116rqdo$28guo$7@dont-email.me>
In reply to#90720
On 28/08/2026 04:47, c186282 wrote:
> I just skipped Java and especially JS ... bad
>    to write, slow to run, just not something I
>    would like. Tossed all my Java/JS books when
>    I retired.

Sadly I need JavaScript - I write a lot of web controlled stuff for my 
home systems

It is horrible. But mostly it works

Likewise PHP.

-- 
To ban Christmas, simply give turkeys the vote.

[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